【ITニュース解説】Release workflow for sole developer

一人でアプリ開発を進めるシステムエンジニア志望の皆さん、お疲れ様です。皆さんが作ったアプリを世に出すまでには、開発だけでなく、テストやリリースといった様々な工程が待っています。特に、一人で開発している場合、いかに効率的かつ安定的にアプリをリリースできるかが重要になる。この記事では、友人や家族にテストしてもらいながら、最終的にApp Storeでの公開を目指すための、シンプルかつ堅実なアプリリリースワークフローを紹介する。この方法を使えば、日々の素早い修正と、安定した新しいアプリバージョンの提供という、二つの目標を両立できる。

このワークフローの核心は、主に二つの異なるアプリ配布方法を使い分けることだ。一つは「TestFlightストアプレビュービルド」、もう一つは「EAS内部配布ビルド」である。

まず、TestFlightストアプレビュービルドは、友人や家族にアプリをテストしてもらうための主要な手段として推奨される。この方法の大きな利点は、テスターにとっての使いやすさだ。アプリのインストールは、特定のリンクをクリックするだけで済み、テスターのデバイス情報（UDIDと呼ばれる識別子）を事前に登録する必要がない。最大1万人の外部テスターが参加でき、Appleの提供するツールを使ってクラッシュレポートや利用状況の分析データも自動的に収集できる。これにより、どのような状況でアプリが停止したか、どの機能がよく使われているかといった貴重なフィードバックを効率的に得られる。また、ビルドの有効期限管理もAppleが行ってくれるため、古いテストビルドがいつまでも残り続ける心配もない。ただし、このTestFlightビルドを配布するには、AppleのApp Store Connectというプラットフォームでの審査が必要になる場合がある。特に、社外のテスター（外部テスター）に配布する場合は、ベータアプリレビューと呼ばれる審査を通過しなければならない。この審査には時間がかかることがある。

このTestFlightストアプレビュービルドと組み合わせることで、開発効率を大幅に向上させるのが「EAS Update」という機能である。これは、JavaScriptのコードや画像などのアセットファイルのみの変更であれば、新しいアプリのバイナリ（アプリ本体のファイル）を再構築して審査に出すことなく、既存のアプリユーザーに直接修正を配信できる仕組みだ。例えば、ユーザーインターフェースの小さな修正やテキストの変更といった、ネイティブコードに影響しない修正であれば、eas update --channel preview --message "マイナーな修正"という簡単なコマンドを実行するだけで、TestFlightで配布されているアプリに修正を適用できる。これにより、Appleの審査を待つことなく、迅速に改善を繰り返せるのだ。

次に、EAS内部配布ビルドは、主に開発者自身が自分のデバイスで素早く動作確認を行う「スモークテスト」のために使うことを推奨する。このビルドは、Appleの審査プロセスを経由しないため、作成からインストールまでが非常に速いという特徴がある。しかし、この方法で他の人にアプリを配布する場合、テスター一人ひとりのUDIDを事前に取得し、開発者が自身のApple Developerアカウントにデバイスを登録する必要がある。この作業は手間がかかる上に、一年に登録できるデバイス数にも上限がある。また、TestFlightのようにAppleからの分析データやクラッシュレポートは提供されないため、広範囲なテストには向かない。あくまで、開発者が自分の環境で、コード変更が意図通りに動作するかを瞬時に確認するためのツールと考えるべきだ。

これらの配布方法を踏まえた上で、推奨されるシンプルなワークフローは以下のようになる。

まず、一つ主要なTestFlightプレビュービルドトラックを用意する。これは、eas build --platform ios --profile previewというコマンドでApp Store Connectに提出するバイナリを構築し、eas submit --platform ios --latestで提出することで作成する。Appleでの処理が完了したら、このビルドを内部テスターグループに追加すれば、すぐに彼らはテストを開始できる。外部テスター向けに公開する場合は、「テスト内容」を記述し、ベータアプリレビューに提出する。

このTestFlightビルドをベースに、日々の開発ではEAS Updateを使って迅速にイテレーションを行う。例えば、eas update --channel preview --message "UIの微調整"といったコマンドで、JavaScriptやアセットのみの変更を既存のTestFlightビルドに適用する。これにより、小さな修正のたびに新しいバイナリをビルドし、Appleの審査を待つといった時間のかかるプロセスを避けることができる。

新しいバイナリを再構築する必要があるのは、特定の状況に限られる。具体的には、ネイティブモジュールをアップグレードした場合や、アプリの設定にネイティブコードレベルでの変更が必要になった場合である。また、アプリのビルド番号を更新したい場合や、大きなマイルストーンとしてマーケティングバージョン自体を変更したい場合も、新しいバイナリの作成が必要だ。

自分のデバイスで緊急に動作確認をしたい場合は、EAS内部配布ビルドを利用する。eas build --platform ios --profile internalというコマンドでビルドを作成し、Expoのビルドページから自分のデバイスにインストールする。必要であれば、一度だけデバイス登録を行う。

このようなワークフローを支える設定ファイルとして、eas.jsonがある。このファイルには、さまざまなビルドプロファイルが定義される。例えば、「preview」プロファイルはTestFlight向けのストアビルドと、それに紐付くOTAアップデートのチャンネルを定義する。「internal」プロファイルは、開発者自身のデバイス向けに高速なアドホックビルドを作成するための設定である。「production」プロファイルは、最終的なApp Storeリリース向けのビルドと、それに紐付くOTAアップデートのチャンネルを定義する。

アプリのバージョン管理も重要である。iOSアプリでは、「バージョン番号」（例: 1.0.3）と「ビルド番号」（例: 26）という二つの数字が使われる。小さなJavaScriptのみの修正の場合、バージョンもビルド番号も変更せず、OTAアップデートで対応する。新しいバイナリを作成するが、アプリの機能としては大きな変更がない場合（同じマーケティングバージョン）は、ios.buildNumberのみをインクリメントする（例: 25から26へ）。大きなリリースでアプリのバージョン自体を変更する場合（例: 1.0.3から1.0.4へ）は、同時にios.buildNumberを「1」などにリセットするのが一般的である。Appleのルールでは、特定のバージョンに対してはビルド番号が常に厳密に増加しなければならないことに注意が必要だ。バージョンを変更すると、ビルド番号をリセットできる。

また、OTAアップデートを正しく機能させるためには「チャンネル」の概念を理解しておく必要がある。アプリのバイナリは、特定のチャンネル（例えば「preview」チャンネル）をターゲットとしてビルドされる。そのバイナリを使用しているユーザーにOTAアップデートを届けたい場合、すべてのOTAアップデートはそのバイナリがターゲットとしているのと同じチャンネルに公開されなければならない。例えば、eas update --channel preview --message "UIの修正"のように、正確なチャンネルを指定する必要がある。もし、バイナリがターゲットとしているチャンネルを変更したい場合は、新しいバイナリを作成し、App Store Connectに提出するプロセスが必要になる。

最後に、どのような状況でどの方法を選ぶべきか、簡単な意思決定ガイドを提示する。「単なるテキスト修正やJavaScriptの軽微な調整か？」という場合は、OTAアップデート（eas update）を選択する。「ネイティブパッケージをアップグレードしたか、設定ファイルを変更したか？」という場合は、新しいバイナリをビルドしてApp Store Connectに提出する。「5分以内に自分の携帯で動作確認が必要か？」という場合は、自分専用のEAS内部配布ビルドを作成する。「友人や家族にテストしてもらいたいか？」という場合は、TestFlightストアプレビュービルドを作成し、その後の修正はプレビューチャンネルへのOTAアップデートで対応する。

このアプローチを採用することで、不必要なバイナリの再構築に時間を費やすことなく、テストを迅速に進め、クリーンなリリースプロセスを維持できる。システムエンジニアとしての皆さんのアプリ開発ライフをよりスムーズにするための、効果的なワークフローと言えるだろう。