CA.swift#14

Transcript

1. isowords の構成で 3週間 開発して得た知見 2021/05/19 CA.swift #14 1
2. • iOS エンジニア として 21新卒入社 • 出身地：北海道恵庭市 • 出身校：会津大学 • 配属：メディア（ABEMA） @ry_itto
 ry-itto
 伊藤凌也
 （いとうりょうや）
 2
3. 話すこと • isowords とは • 従来のプロジェクト管理について • SPM+xcworkspace プロジェクト管理 ◦ メリット ◦ デメリット ◦ パッケージ管理について ▪ CocoaPods ▪ Carthage ◦ ツール周り • まとめ 3
4. isowords とは • Point-Free の作った SwiftUI, SceneKit を使ったゲームアプリ • SPM を使用したプロジェクト・パッケージ管理 をしている • アセットの管理に git-lfs を使用している • アーキテクチャは Composable Architecture 4
5. 従来のプロジェクト管理 5
6. 従来の プロジェクト管理 種類 大きく分けて二つ • Pure な XcodeProject で構成 • XcodeGen, Tuist 等で Project ファイルを生成せず構成 6 OR
7. 従来の プロジェクト管理 課題 大きく分けて二つ • Pure な XcodeProject で構成 project.pbxproj でのコンフリクト 多発 • XcodeGen, Tuist 等で Project ファイルを生成せず構成 → ツールメンテナーが対応しないと 新規機能など使用できない → 外部ツール依存が増える 7
8. SPM + xcworkspace プロジェクト管理 8
9. SPM + xcworkspace プロジェクト管理 概要 • アプリのソースを Swift Package として切り出した上で吐き出し、アプ リケーションターゲットで使用する方 法 • ターゲットごとにリソースを持たせた りできる 9
10. 10 ライブラリを吐き出す Framework に追加する
11. メリット その１ • ソースファイルを project.pbxproj で認識する必要がない • Pacakge.swift を使用して自由に ターゲットを作成できる • 外部のツールが必要ない • Xcode で使える新機能が導入タイ ミングから使える 11
12. メリット その２ • プロジェクトごとアプリを分けること が懸念なくできる 12
13. メリット つまり • ソースファイルを project.pbxproj で認識する必要がない → コンフリクトが（ほぼ）しない • Pacakge.swift を使用して自由に ターゲットを作成できる → マルチモジュール化が容易 → 差分ビルドを用いたビルド速度改 善が図れる 13
14. メリット つまり • ソースファイルを project.pbxproj で認識する必要がない → コンフリクトが（ほぼ）しない • Pacakge.swift を使用して自由に ターゲットを作成できる → マルチモジュール化が容易 → 差分ビルドを用いたビルド速度改 善が図れる 14 XcodeGen や Tuist を使用するこ とによる美味しさも持っている
15. メリット つまり • 外部のツールが必要ない • Xcode で使える新機能が導入タイ ミングから使える • プロジェクトごとアプリを分けること が懸念なくできる 15 他にないメリットも兼ね備えている
16. デメリット • Swift Package Sources 配下に ファイルを追加すると一定時間ビル ドができなくなる • SwiftUI Previews が使えなくなる 場合がある • Package.swift を更新してもたまに “Resolving Package Graph” が 行われない 16
17. デメリット • Swift Package Sources 配下に ファイルを追加すると一定時間ビル ドができなくなる • SwiftUI Previews が使えなくなる 場合がある • Package.swift を更新してもたまに “Resolving Package Graph” が 行われない 17 「できるはずのこと」ができない状態となっ てしまう（たまに）
18. パッケージ管理 • 基本的には SwiftPM経由でパッ ケージを入れるのが一番楽 • CocoaPods, Carthage 経由で入 れたものも導入は可能 • *.framework のみが公開されてい るものはそのままでは導入できない 18
19. パッケージ管理 Carthage • carthage での Pre-build 時に XCFramework を生成すればOK • 使い方 19
20. パッケージ管理 CocoaPods • Pods のプロジェクトをそのまま依存 に入れるのは難しかった → Pre-build する • そもそもどうしてこれがしたい？ → Podfile しかないライブラリがた まにある。。 サンプル https://github.com/ry-itto-playground/SPM-coc oapods 20
21. パッケージ管理 CocoaPods 21
22. パッケージ管理 CocoaPods • なぜ自前でビルドのスクリプトを書い たのか？ → cocoapods-binary では xcframework で吐き出せなかった ため。 22
23. ツール周り 配置 Mint 等を使用しない Swift 製ツールの 導入 ※ SPM + xcworkspace プロジェクト管 理 じゃなくても使用可能。 23
24. ツール周り 追加方法 普通に dependencies に .package で Swift製ツールを追加するだけ 24
25. ツール周り 使い方 プロジェクトルートで --pacakge-path Tools を指定してツールを実行するだけ （swift run だと実行に若干のタイムラグ があるので、事前にビルドして使うのが良 いかもしれない） 25
26. ツール周り ありそうな質問 アプリ自体の Package.swift と同じとこ ろに依存を追加して使ってはダメなんで すか？ 26 ダメです。追加したパッケージのどれか一 つでも iOS/macOS に対応していない場 合アプリもビルドすることができなくなりま す
27. ツール周り つまりどころ 追加したパッケージが依存しているパッ ケージのバージョンが全く違うとエラーと なる 27 追加したパッケージの依存しているパッ ケージのバージョンを上げる or 追加したいパッケージ用に Package.swift を作る
28. まとめ 28
29. まとめ • メリットを享受したければ XcodeGen を使うだけでも良さそう • XcodeGenを使用して開発する際に比べてストレスは多そう • XcodeGen 等が持っていないメリットを考えても絶対的な選定理由には ならなさそう （”プロジェクトごとアプリを分けることが懸念なくできる” 次第） • まずは個人開発から導入して試してみると良さそう • 構成自体は非常に面白い • 固まるとかそれ以外の懸念がない 29
30. まとめ 30 プロダクションに導入しても良さそうか？ 導入自体難しくない。 でもどちらのストレスの方が耐えられるのか十分に検証した方が良い
31. References • A Tour of isowords: Part 1 • A Tour of isowords: Part 2 • Swift PMとマルチプロジェクトでBuild Configurationをクリーンに保つ • https://github.com/pointfreeco/isowords 31