Android Dev Summit 2019の文脈でAndroid公式のDaggerに関するドキュメントやCodelabが出てきて取っ付きやすくなった感じがします。いいですね。
- Dagger basics | Android Developers
- Using Dagger in Android apps | Android Developers
- Using Dagger in multi-module apps | Android Developers
Android Dev Summit 2019の文脈でAndroid公式のDaggerに関するドキュメントやCodelabが出てきて取っ付きやすくなった感じがします。いいですね。
こんにちは。iOSDC Japan 2019の0日目参加のため東京に上陸しております id:ikesyo です。明日1日目の16:15からTrack Bで『5分でわかる!Xcode 11から使えるXCFrameworks』というタイトルでLTをします。
どういう内容かは紹介文を読んでいただきつつ、先月行われたスピーカーディナーでの1分間ピッチの動画も上がっているので、タイトルや紹介文でLTの内容にちょっと興味が出てきたら、ぜひ動画も見てみて、当日LTを聴きに行くかどうかの参考にしてもらえればと思います。
ちなみに私はiOSDC Japanで4年連続4回目のLT登壇(自分調べではただ一人!)となります。今年もこの場で発表できて嬉しい・楽しい気持ちも持ちつつ、少しでも有益な情報を持ち帰ってもらえればと思います。それでは会場でお会いしましょう!🤗
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 さんのツイート:
Travis CIは「1Jobあたり」50分の制限があるけど1ビルドあたりの制限はなく、Build Matrixでテストケースをいくらでも分割できるので事実上無限にビルド時間を使える。時間を早くするのはお金を払えばいいので、OSSでCIをとりあえず動かすのには一番いいと思う。
— kishikawa katsumi (@k_katsumi) 2017年5月15日
一方でAzure PipelinesのOSS向けプランでの、macOSサポートも含めた10並列無料もかなり魅力的に映る(Travis CIのOSS向け無料プランでは、macOSの同時実行は2並列まで・分割はいくらでも)ので、そちらも試していきたい今日この頃です。小ネタですが、YAMLのアンカーとエイリアスで重複を整理するのは、他のCIサービスの設定ファイルでも活用できると思うので、どうぞお試しください。
またXcode 11でSwiftPMがXcodeに統合され、iOSアプリ開発にも使えるようになることから、今後SwiftPMのパッケージが増えていくと思います。UIと関係しない(UIKitを使わない)ようなライブラリであればLinuxへのポートも現実的だと思っているので、どんどんLinuxをサポートするパッケージが増えて、サーバーサイドSwiftもそうですし、Swift全体のエコシステムが活発になると嬉しいですね!
その他の発表者の方の発表資料はこちらからどうぞ。
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でのサポートに期待したいですね。
DiffUtil
が重複IDのものは無視するが、その時の動作は未定義、という感じの模様EpoxyController.setFilterDuplicates(true)
EpoxyController.onExceptionSwallowed
で処理されて、デフォルトでは無視されてクラッシュしたりはしない
というバグレポートを起票しました。
原因となったswift-corelibs-foundationのPRがこちらです。
例として、現在のDarwin(macOSやiOSなど)でのNSNumber
のProtocol準拠は次のとおりです。
どちらかと言うと、NSNumber
やNSString
などがComparable
になるのはポジティブなので、DarwinのFoundationでもComparable
準拠になると嬉しいですね。
社内のSlackでSpongy Castleという名前を聞いて、知らなかったので少し調べてみました。
この辺を見ました: