iOSプロジェクトを立ち上げた際にやっておきたいこと
Code Signing
まず最初に必要なことはCode Signingです。
Appleは開発元を明らかにすることを要求しているので、コードに署名する必要があります。
署名に必要になるものは、Provisioning Profileというものです。
Provisioning Profileは、以下3つの情報を一つにまとめたものです。
- Certificate(証明書)
- AppID
- DeviceID
手作業でこれらを作成していくことも可能なのですが、
またチームメンバーが増えるたびに手作業で作成していては非常に時間がもったいないです。
そこでXcodeにAutomatically manage signing という機能があるのでこれを使いましょう。
これを有効にしXcodeでサインインしているアカウントがチームに参加されていれば、
XcodeがProvisioning Profile / AppID / Certificateの作成/更新を自動で行ってくれます。
ただしこの機能は開発環境のみで使う方が良いでしょう。なぜなら開発者が配布用証明書の作成・削除ができてしまうので、他の開発者がreleaseビルドできなくなってしまう可能性があるためです。(配布用証明書の最大数は3つまでなので。)
リリース環境はfastlane matchを使うと良いかもしれません。
fastlaneのユーティリティの一つであるmatchは証明書や秘密鍵、Provisioning Profileをgit管理し、
複数の環境で共有できるようにするツールです。
これを使うことでfastlaneコマンド一発でProvisioning Profileを取得でき、意図しない変更を防ぐことができます。またCIからProvisioning Profileを取得したい場合もコマンド一発で対応できるので、CIのワークフローでtestflightにipaをアップロードするようなことも簡単に対応できるようになります。
match
前述の通り、fastlaneのユーティリティの一つであるmatchは証明書や秘密鍵、Provisioning Profileを、git管理し、複数の環境で共有できるよにするツールです。
事前準備
まずは以下3つの事前準備をしてください。
- gem経由でfastlaneをインストール(fastlaneはruby製のタスクランナーなので)
gem install fastlane
- 証明書と秘密鍵、Provisioning Profileを置くためのgitのプライベートリポジトリーの作成
- Apple Develper Programへの参加とApp Manager以上の権限を持ったアカウントを用意
アプリの作成
Apple Developer PortalとApp Store Connectにアプリを作成するためにproduceアクションを使用します。
produce
はAppDeveloperPortalとAppStoreConnectの両方に、新しいiOSアプリを作成するアクションです。
fastlane produce -a <bundle_identifier>
-a
オプションを使用し、BundleIDを指定することができます。ここで指定したBundleIDは変更することができないので注意してください。
AppleIDとPassword、2FAを入力し最後にアプリ名を指定するとAppStoreConnectにアプリが作成されます。
アプリの作成が完了すると、App IDが自動で割り当てられます。
証明書・秘密鍵・Provisioning Profileの作成
まずfastlane用のディレクトリを作成しておきます。
mkdir fastlane
fastlane init
で作成しても問題ありません。
その後以下コマンドでMatchfileを作成します。
fastlane match init
次にprovisioning profilesを作成していきます。
直接fastlane match
コマンドを使って作成してもよいのですが、
Certificateの更新(有効期限は1年)をするたびにAppIdentifierを入力する手間を省きたいので、今回はFastfileにレーンを作ってそれを実行するようにします。
default_platform :ios
platform :ios do
desc "Create certificate and provisioning profile."
lane :create_certs do
match(app_identifier: "com.hogehoge.foo", type: "appstore")
end
end
そして以下コマンドを叩き、
fastlane create_certs
対話形式で進めていくとgitリポジトリにcertificateとprovisioning profileが生成されていると思います。
ライセンス情報を表示する
オープンソースなライブラリを使用している場合、それらはなんらからソフトウェアライセンスを表記していると思います。
オープンソースのライブラリの多くはMITライセンスであり、著作権表示および本許諾表示を表示しなければなりません。
iOSアプリの場合、設定アプリ内に表示することが多いと思います。
設定アプリ内に使用しているOSSライブラリのライセンスを手動で明記していくのはとてもてまなのLicensePlistというライセンスを自動で作成してくれるSwift製のCLIツールを使うことが多いように思います。
CI環境を準備する
CI環境の整備は事業内容に直接関わることが無いので後回しにしても良いように思いますが、個人的には最初にやっておいたほうが良いと思います。
経験上開発が進めば進むほど忙しくなり、CI環境を整備するどころではなくなったり、CIマシン上でのビルドに失敗した場合の解決が難しくなると思います。
CIマシン上でのビルドに失敗した場合の解決が難しくなる
この理由としては、まっさらな状態からCIビルドを通るようにしておき、機能実装ごとにCIビルドを実行するようにしておけば、失敗したタイミングで原因が究明しやすくなります。もしある程度実装が進んだ状態CI環境を整備し始め、CIビルドに失敗した場合、原因が複数あればその解決に時間がかかってしまいます。
プラスアルファでCIのワークフローに組み込んでおきたいのは、
- 未使用コードの検知
- Lint
- Format
- チャットツールにバイナリダウンロード用QRを送信する
- Test
- AppStoreConnectへのipa送信
Push通知
サービスを大きくするためやユーザビリティを高めるためにPush通知は、モバイルアプリにとって欠かせない機能の一つだと思います。
前述したようにプロジェクトが進めば進むほど忙しくなるので、プロジェクト立ち上げの段階でPush通知の機能は入れておいて損はないでしょう。
またPush通知の実装に必ずと言って関連してくるのがDeep Linkingです。画面遷移系の処理の実装はアーキテクチャによって実装方法が異なるかもしれませんが、こちらについても早めに検討しておくほうが良いでしょう。
Firebase Crashlytics
100%クラッシュしないアプリを作るのは相当難しいことであり、
私は基本的にクラッシュをゼロにすることは無理だと考えています。
そしてクラッシュしたとき、原因を究明し迅速に対応できることが重要だと思います。
Firebase Crashlyticsはどのファイルのどの行のコードでクラッシュしたかを検知してくれるので、こちらもモバイルアプリ開発をする上で必須のサービスです。
Firebase Crashlyticsを導入する際、dSYMファイルをFirebaseコンソールにアップロードするのを忘れないようにしないといけません。
文字列リソースの管理
iOS開発では、Androidのように文字列リソースを管理する機構は提供されていません。
そこでR.swiftやSwiftGenのようなツールを用いて文字列リソースを管理するプロジェクトもあります。
ただ個人的にはこのようなツールを使う必要は無いのかなと思います。
ツールを使わない場合でもstringsファイルにKey-Value形式で文字列を定義して、enumでKeyを管理すれば良いだけです。逆にツールの扱いやセットアップに時間がかかったり、予期しない問題に遭遇した場合の解決に時間がかかったりする場合があると本末転倒です。
なのでできるだけサードパーティーのツールには依存しないほうが良いと考えています。
CLIツールの管理
iOS開発をする際にLintやコード整形など、コードの品質を保つために便利ツールを用いることがあります。
これらのツールを管理するためにパッケージマネージャーを使用し、
Swift製のCLIツールを管理するパッケージマネージャーとして使われているものにMintが多いと思います。もしくはHomebrew経由でインストールすることも有ると思います。
ただMintをインストールするにも別のパッケージマネージャで管理したりするなどセットアップが必要になります。
Swift Package Managerの場合、つまりXcode(正確にはXcodeのツールチェーン)があればSwift Package Managerで管理している実行可能なパッケージをビルド&実行できるので、セットアップの必要がありません。これはCIマシン上でCLIツールを動かす際にも余計なセットアップのタスクを省略できるため便利です。
プロジェクト構成
アプリリリース時は、プロジェクトの大きさが小さくても、サービスの規模が大きくなるにつれてプロジェクトの規模も大きくなって行く可能性があるので、最初からマルチモジュール構成を取るのがおすすめです。
マルチモジュール構成は、
- ビルド時間の削減
- 依存関係が把握しやすい
などのメリットがあります。
これまではEmbedded framework(Dynamic Framework)を用いてマルチモジュール構成を実現しようとしてきましたが、
Embedded frameworkの数が多くなるとかえってビルド時間が遅くなっていたようです。(Embedded frameworkについては詳しくないので誤りがある可能性があります。)
なので機能単位ごとのモジュール化は難しくレイヤー単位でのモジュール化くらいしかできなかったのかもしれません。
しかし現在はSwift Package Managerがあります。Swift Pakage Managerを用いてマルチモジュール化することができます。