はじめに
こんにちは。MAMADAYS開発部でiOSエンジニアをやってる國吉です。
この度、MAMADAYSから姉妹アプリ第一弾となる”陣痛カウンター”をリリースしました。
MAMADAYSアプリはスーパーアプリになっていて機能数も多く長く利用して頂くユーザさんも多いアプリです。一方で、陣痛時の利用という利用期間が短い用途のものは小さいアプリに切り出して機能特化することでシンプルで使いやすい戦略を取っています。
そしてタイトルにも書いてある通り、陣痛カウンターはSwift Package Managerを採用しています。採用理由は下記で、お試しで導入するには最適だと考え、導入に至りました。
- アプリ自体の規模が小さい - 前からSwift Package Managerを使ってみたかった - 使用するライブラリ数が少ない
今回はそんなSwift Package Managerについてお話ししていきます。
陣痛カウンター
本題に入る前に少し陣痛カウンターアプリについて宣伝をさせてください。
陣痛カウンターは機能・デザイン共にシンプルですごく使いやすい！また、オフライン状態でも動作します！
陣痛がきたかなと感じたら”きたかも”ボタンをタップし、時間計測を始めます。陣痛が治まったら”おさまったかも”ボタンをタップして計測を終了します。
それらデータを履歴として表示して、陣痛間隔が一定の間隔より下回ったらお知らせする。といったアプリです！
実際の使い勝手などは実際にインストールして使ってみてください！是非周りに出産を控える妊婦さんがいたら紹介して頂けると嬉しいです。
Swift Package Manager
さて、本題のSwift Package Manager(以下”SPM”と略)のお話をしていきます。 SPMはApple公式から提供されているパッケージマネージャーになっており、Xcode9以降から使うことができます。
SPMに対応しているか調査
まず、アプリに入れようとしているライブラリがSPMに対応しているのか調べる必要があります。
ライブラリ側がSPMに対応していなかった場合は、SPMは使えません。
調べ方はすごく簡単で、ライブラリのディレクトリ内に「Package.swift」というファイルがあるかどうかを見るだけです。
例:nuke https://github.com/kean/Nuke 1. ライブラリのディレクトリが確認できるページを開きます。 2. ディレクトリ内を確認するとPackage.swiftがあるのが確認できます。 3. これでnukeはSPM対応されていることがわかります。
次にアプリ側でライブラリ使えるようにしていきます。
[File] -> [Add Packages ...]
Search or Enter Package URL のサーチエリアでライブラリのリポジトリURLを入力し検索をかけます。
すると、このようにnukeがサジェストされます。
Dependency Ruleで導入したいバージョン指定を行い、[Add Package]をクリックすると、ダウンロードが開始されます。
複数パッケージが存在する場合は、どのパッケージを導入するか選択する画面がでるので、任意のパッケージを選択しダウンロードしましょう。
ダウンロードが完了すればライブラリが使えるようになります。CocoaPodsと同様にimportして使ってください。
実態はどこに
ここまででSPMを用いてライブラリを追加してきましたが、設定ファイルや実態はどこにいるんだ？チーム開発をしているからメンバーにはどうやって共有されるんだ？
という疑問が生じました。調べた結果下記の場所に設定ファイルや実態がありました。
依存関係を解決した結果や各ライブラリのバージョンが”Package.resolved”というファイルに書き出されるので、これを他メンバーに共有されることでライブラリのバージョンを揃えることができます。
# ライブラリ群
> /Library/Developer/Xcode/DerivedData/{projectID}/SourcePackages/checkouts/
# Package.resolved（設定ファイル）
> /{project}.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved
CocoaPodsとの比較
Xcodeのみでライブラリの追加/削除が簡単にでき、バージョン確認等々も完結できます。 "pod init"や"pod install"とかしなくていいので、結果的に操作する箇所が減って楽になりました。
SPMはApple公式が出しているパッケージマネージャーなので、安心感はあります。Xcode13以降ようやく動作も安定してきたようです。
SPM導入で苦労したこと
陣痛カウンターはFirebaseのCrashlyticsを使用しています。
fastlaneでFirebaseにdSYMを上げているんですが、実行しても「upload-symbolsが存在しません」とエラーが吐かれました。
CocoaPodsでライブラリ管理をしているとPodsフォルダ配下にupload-symbolsというスクリプトファイルが存在しますが、 SPMはライブラリの実態がプロジェクトのディレクトリ配下にはいないので、参照できないということでした。
回避策として、Firebase公式のページからupload-symbolsをダウンロードし、fastlaneではそのスクリプトファイルを動かすように対応しました。
導入してみた感想
結論、この規模感のアプリにはSPMは適していると思いました。 まず、CocoaPodsとの比較セクションでも触れましたがライブラリの追加/削除がXcode内で簡単にできるのが一番大きいメリットです。
Pod関連のファイルも無くなるので、ディレクトリの見通しも良くなります。
Crashlyticsとか独自の対応を行いましたが、一度対応しておけば使い回すことができるので、最初だけ我慢しましょう。
ただ、陣痛カウンターのような小規模なアプリに適していると感じているだけで、中規模以上のアプリには不適切かもしれません。 あと、既にCocoaPodsで実装を進めてしまっている場合も、CocoaPodsのままでいいと思います。現状、移行するコストを払うほどのメリットは無いと感じています。
また古いライブラリはSPMに対応していないケースも多々あるので、導入前に追加予定のライブラリがSPMに対応しているかの調査はすごく大事です。その中で1つでもSPM対応されていないライブラリがあるのであれば、手間が増えるだけなのでCocoaPodsにした方がいいです。
最後に
ここまで読んでくださりありがとうございました。
SPMについて触りぐらいは伝わったでしょうか？この記事がSPM導入の手助けになることがあれば嬉しいと思います！
