和暦と改元とうるう年が組み合わさったバグの思い出

あけましておめでとうございます。新年一発目の投稿は2019年の思い出です。

ということで本年もよろしくお願いします 🙏

2019年のSwiftモック事情

こんにちは、id:ikesyoです。これは はてなエンジニア Advent Calendar 2019 17日目のエントリーです。


昨日12月16日(月)に行われた 年末だよ Android/iOS Test Night - 2019 にて、『2019年のSwiftモック事情』という発表をしました。

Swiftでテストのためのモックを用意するとなると、リフレクションでめちゃくちゃするということができないので、素朴に手で書くか、コード生成をすることになります。今回の発表ではコード生成に主眼を置き、以下の4つの選択肢を紹介しました。

それぞれの機能や違いなど詳しい内容は、ぜひ発表のスライドを見てみてください。

Swiftでのモック事情については、今年4月の Mobile Act KYOTO #1 でも発表をしていました。

しかしこの後の8ヶ月で意外と状況が変わっており、その差分を今回の発表に入れ込んでいます。

  • SwiftyMockyの設定ファイルとコマンドが変わった
    • Before: 設定ファイルはmocky.yml、コマンドはsourceryを直接利用
    • After: 設定ファイルはMockfile、コマンドはswiftymockyという専用のものが用意された(Sourceryの存在をラップ・隠蔽)
  • Cuckooの機能追加
  • Mockoloの発表とリリース
    • Uber製のモックジェネレーターで、コード生成が高速であるのが売り
    • 5月に開催されたUIKonf 2019での発表で公表され、OSSとしてリリース予定とされていた
    • 9月に1.0.0がリリースされた

Mockoloについては、UIKonfのセッション動画が公開されており、開発者自ら独自のジェネレーターを作るに至った背景や、高速化のためにやったことを丁寧に説明してくれています。こちらもぜひ見ましょう!

ということで、2019年末時点でのSwiftのモック事情をご紹介しました。どのツールを使うかは、

  • 機能
  • APIの好み
  • チームメンバーの規模や習熟度
  • プロジェクト(コードベース)の規模

など複数の要素に影響されると思います。ぜひ自分たちに適した選択肢を導入してみて、Swiftのテストライフを豊かなものにしていきましょう! 🤖


あわせて読みたい

Android公式のDagger導入ドキュメント

Android Dev Summit 2019の文脈でAndroid公式のDaggerに関するドキュメントやCodelabが出てきて取っ付きやすくなった感じがします。いいですね。

Codelab

Dev Summitの動画

iOSDC Japan 2019でXCFrameworksのLTをします

こんにちは。iOSDC Japan 2019の0日目参加のため東京に上陸しております id:ikesyo です。明日1日目の16:15からTrack Bで『5分でわかる!Xcode 11から使えるXCFrameworks』というタイトルでLTをします。

どういう内容かは紹介文を読んでいただきつつ、先月行われたスピーカーディナーでの1分間ピッチの動画も上がっているので、タイトルや紹介文でLTの内容にちょっと興味が出てきたら、ぜひ動画も見てみて、当日LTを聴きに行くかどうかの参考にしてもらえればと思います。

ちなみに私はiOSDC Japanで4年連続4回目のLT登壇(自分調べではただ一人!)となります。今年もこの場で発表できて嬉しい・楽しい気持ちも持ちつつ、少しでも有益な情報を持ち帰ってもらえればと思います。それでは会場でお会いしましょう!🤗

CI/CD Test Night #4で、Swift製ライブラリのLinux対応 with Travis CIについて発表しました

Test Nightに初めて参加してきました(iOSやCI/CDも含めて)。普段は概ねiOSやSwift関係の勉強会・カンファレンスへの参加がメインなので、異なる軸での勉強会の参加するのは新鮮で楽しかったです(けど結構スマホアプリ絡みやBitriseの話も出ていた)。

👇発表資料はこちらです。

最近はBitriseやCircleCI、Azure PipelinesなどのCIサービスの方が耳目を集めており、Travis CIに関する話をあまり見ない気がします。しかしTravis CIのBuild MatrixとOSS向け無料プランは、OSSのライブラリで簡単に複数OS・複数言語バージョン対応をやるのにかなり便利だと思っているので、使ってみる方が増えるといいなと思います。

ここで2年前の id:KishikawaKatsumi さんのツイート:

一方でAzure PipelinesのOSS向けプランでの、macOSサポートも含めた10並列無料もかなり魅力的に映る(Travis CIのOSS向け無料プランでは、macOSの同時実行は2並列まで・分割はいくらでも)ので、そちらも試していきたい今日この頃です。小ネタですが、YAMLのアンカーとエイリアスで重複を整理するのは、他のCIサービスの設定ファイルでも活用できると思うので、どうぞお試しください。

またXcode 11でSwiftPMがXcodeに統合され、iOSアプリ開発にも使えるようになることから、今後SwiftPMのパッケージが増えていくと思います。UIと関係しない(UIKitを使わない)ようなライブラリであればLinuxへのポートも現実的だと思っているので、どんどんLinuxをサポートするパッケージが増えて、サーバーサイドSwiftもそうですし、Swift全体のエコシステムが活発になると嬉しいですね!

その他の発表者の方の発表資料はこちらからどうぞ。

Xcode 11で導入されるxcframeworkのディレクトリ構造

WWDC19でお目見えしたXcode 11ですが、ライブラリ・フレームワークの配布形態として .xcframework という新しいフォーマットが導入されています。

https://developer.apple.com/documentation/xcode_release_notes/xcode_11_beta_release_notes/#3318305

XCFrameworks make it possible to bundle a binary framework or library for multiple platforms —including iOS devices, iOS simulators, and UIKit for Mac — into a single distributable .xcframework bundle that your developers can use within their own applications. An .xcframework bundle can be added to an Xcode target’s Link Libraries phase and Xcode uses the right platform’s version of the included framework or library at build time. Creation of XCFrameworks is supported from the command line using xcodebuild -create-xcframework. Frameworks or libraries bundled in an XCFramework should be built with the Build Libraries for Distribution build setting set to YES. (49948269)

このフォーマットの導入は、リリースノートにも書かれているようにUIKit for Mac(Project Catalyst)と関係していそうです。それだけではなく、Swift 5.1でのModule Stability*1サポートによる、Swiftで書かれたフレームワークのバイナリ配布とも関連した動きに見えます。

これまでは、各種SDKなどでiOS用のフレームワーク.framework形式)を配布する場合、iOSシミュレーター用のframeworkと、iOSバイス用のframeworkをそれぞれビルドしてから、frameworkのバンドル内に含まれるバイナリをlipoコマンドで結合して1つのframeworkにする、という手段が取られていました。Carthageでframeworkをビルドする時もこうした処理が行われています。

ただしこの方法には少し問題があり、iOSアプリをApp Storeに提出する際のバリデーションで、アプリに含まれるframeworkのバイナリにシミュレーター用のCPUアーキテクチャーのスライスが含まれているとバリデーションで蹴られてしまいます。そのためストア提出用のリリースビルドを行う際には、lipoコマンドでシミュレーター用のスライスを取り除く必要があります。Carthageではこの問題の対処として、アプリにframeworkを組み込む際にcarthage copy-frameworksコマンドを使うようになっています。

一方、新しい.xcframework形式では、複数の.frameworkを1つのバンドル(ディレクトリ)にまとめる構造となっています。この構造では、アプリをデバイス向けにビルドする時にはxcframework内のデバイス用のframework、シミュレーター向けにビルドする時にはシミュレーター用のframeworkを使うことができるので、ストア提出用のアプリにシミュレーター用のスライスが含まれてしまうということが起きなくなります。Carthageでもxcframeworkがサポートされると、copy-frameworksコマンドを使用する必要がなくなることが期待できます*2

実際に.xcframeworkを生成してディレクトリ構造を確認してみました。シミュレーター用・デバイス用・UIKit for Mac用のframeworkは先にビルドした上で、xcframeworkの生成は次のコマンドで行えます:

$ xcodebuild -create-framework \
    -framework iphonesimulator/Himotoki.framework \
    -framework iphoneos/Himotoki.framework \
    -framework uikitformac/Himotoki.framework \
    -output Himotoki.xcframework

ディレクトリ構造は次のようになっていました。

$ tree Himotoki.xcframework
Himotoki.xcframework
├── Info.plist
├── ios-armv7_arm64
│   └── Himotoki.framework
│       ├── Headers
│       │   ├── Himotoki-Swift.h
│       │   └── Himotoki.h
│       ├── Himotoki
│       ├── Info.plist
│       └── Modules
│           ├── Himotoki.swiftmodule
│           │   ├── arm.swiftdoc
│           │   ├── arm.swiftinterface
│           │   ├── arm.swiftmodule
│           │   ├── arm64-apple-ios.swiftdoc
│           │   ├── arm64-apple-ios.swiftinterface
│           │   ├── arm64-apple-ios.swiftmodule
│           │   ├── arm64.swiftdoc
│           │   ├── arm64.swiftinterface
│           │   ├── arm64.swiftmodule
│           │   ├── armv7-apple-ios.swiftdoc
│           │   ├── armv7-apple-ios.swiftinterface
│           │   ├── armv7-apple-ios.swiftmodule
│           │   ├── armv7.swiftdoc
│           │   ├── armv7.swiftinterface
│           │   └── armv7.swiftmodule
│           └── module.modulemap
├── ios-i386_x86_64-simulator
│   └── Himotoki.framework
│       ├── Headers
│       │   ├── Himotoki-Swift.h
│       │   └── Himotoki.h
│       ├── Himotoki
│       ├── Info.plist
│       ├── Modules
│       │   ├── Himotoki.swiftmodule
│       │   │   ├── i386-apple-ios-simulator.swiftdoc
│       │   │   ├── i386-apple-ios-simulator.swiftinterface
│       │   │   ├── i386-apple-ios-simulator.swiftmodule
│       │   │   ├── i386.swiftdoc
│       │   │   ├── i386.swiftinterface
│       │   │   ├── i386.swiftmodule
│       │   │   ├── x86_64-apple-ios-simulator.swiftdoc
│       │   │   ├── x86_64-apple-ios-simulator.swiftinterface
│       │   │   ├── x86_64-apple-ios-simulator.swiftmodule
│       │   │   ├── x86_64.swiftdoc
│       │   │   ├── x86_64.swiftinterface
│       │   │   └── x86_64.swiftmodule
│       │   └── module.modulemap
│       └── _CodeSignature
│           └── CodeResources
└── ios-x86_64-uikitformac
    └── Himotoki.framework
        ├── Headers -> Versions/Current/Headers
        ├── Himotoki -> Versions/Current/Himotoki
        ├── Modules -> Versions/Current/Modules
        ├── Resources -> Versions/Current/Resources
        └── Versions
            ├── A
            │   ├── Headers
            │   │   ├── Himotoki-Swift.h
            │   │   └── Himotoki.h
            │   ├── Himotoki
            │   ├── Modules
            │   │   ├── Himotoki.swiftmodule
            │   │   │   ├── x86_64-apple-ios-macabi.swiftdoc
            │   │   │   ├── x86_64-apple-ios-macabi.swiftinterface
            │   │   │   ├── x86_64-apple-ios-macabi.swiftmodule
            │   │   │   ├── x86_64.swiftdoc
            │   │   │   ├── x86_64.swiftinterface
            │   │   │   └── x86_64.swiftmodule
            │   │   └── module.modulemap
            │   └── Resources
            │       └── Info.plist
            └── Current -> A

ios-armv7_arm64にデバイス用のframeworkが、ios-x86_64-simulatorにシミュレーター用のframeworkが、そしてios-x86_64-uikitformacにUIKit for Mac用のframeworkが含まれていることが分かります。

またトップレベルのInfo.plistの内容は次のようになっていました。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>AvailableLibraries</key>
    <array>
        <dict>
            <key>LibraryIdentifier</key>
            <string>ios-x86_64-uikitformac</string>
            <key>LibraryPath</key>
            <string>Himotoki.framework</string>
            <key>SupportedArchitectures</key>
            <array>
                <string>x86_64</string>
            </array>
            <key>SupportedPlatform</key>
            <string>ios</string>
            <key>SupportedPlatformVariant</key>
            <string>uikitformac</string>
        </dict>
        <dict>
            <key>LibraryIdentifier</key>
            <string>ios-armv7_arm64</string>
            <key>LibraryPath</key>
            <string>Himotoki.framework</string>
            <key>SupportedArchitectures</key>
            <array>
                <string>armv7</string>
                <string>arm64</string>
            </array>
            <key>SupportedPlatform</key>
            <string>ios</string>
        </dict>
        <dict>
            <key>LibraryIdentifier</key>
            <string>ios-i386_x86_64-simulator</string>
            <key>LibraryPath</key>
            <string>Himotoki.framework</string>
            <key>SupportedArchitectures</key>
            <array>
                <string>i386</string>
                <string>x86_64</string>
            </array>
            <key>SupportedPlatform</key>
            <string>ios</string>
            <key>SupportedPlatformVariant</key>
            <string>simulator</string>
        </dict>
    </array>
    <key>CFBundlePackageType</key>
    <string>XFWK</string>
    <key>XCFrameworkFormatVersion</key>
    <string>1.0</string>
</dict>
</plist>

xcodebuild -create-xcframeworkコマンドの-frameworkオプションの数を増やすことで、ここにmacOS、tvOS、watchOS用のビルドも追加することができるはずです。

また.frameworkだけでなく、.aのstatic libraryや.dylibのdynamic libraryとそれ用のヘッダーをバンドルすることもできるようになっています。コマンドのヘルプの出力も載せておきます。

$ xcodebuild -create-xcframework -help
OVERVIEW: Utility for packaging multiple build configurations of a given library or framework into a single xcframework.

USAGE:
xcodebuild -create-xcframework -framework <path> [-framework <path>...] -output <path>
xcodebuild -create-xcframework -library <path> [-headers <path>] [-library <path> [-headers <path>]...] -output <path>

OPTIONS:
-framework <path>         Adds a framework from the given <path>.
-library <path>           Adds a static or dynamic library from the given <path>.
-headers <path>           Adds the headers from the given <path>. Only applicable with -library.
-output <path>            The <path> to write the xcframework to.
-help                     Show this help content.

今後の各種ツールやSDKでのサポートに期待したいですね。

EpoxyでのモデルのID重複時の挙動