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重複時の挙動

LinuxのSwift 5.1で、NSNumberなどがComparableになってDarwinとソース互換がなくなる事例

というバグレポートを起票しました。

原因となったswift-corelibs-foundationのPRがこちらです。

例として、現在のDarwinmacOSiOSなど)でのNSNumberのProtocol準拠は次のとおりです。

NSNumber - Relationships
NSNumber - Relationships

どちらかと言うと、NSNumberNSStringなどがComparableになるのはポジティブなので、DarwinのFoundationでもComparable準拠になると嬉しいですね。

Java Cryptography Extension(JCE)と、AndroidのBouncy Castleと、Spongy Castle

社内のSlackでSpongy Castleという名前を聞いて、知らなかったので少し調べてみました。

  • AndroidJavaJava Cryptography Extension(JCE)の仕組みに則っている
  • AndroidではJCEのプロバイダーとしてBouncy Castleが提供されている
  • Androidに乗っているBouncy Castleは、スリムダウン・カスタムしたバージョンが乗っていて名前空間はそのまま
  • なので本来のBouncy Castleの新バージョンなどを入れようとすると衝突してしまって問題になる
  • なので中身はBouncy Castleだけど、名前空間を分けたのがSpongy Castle

この辺を見ました: