はじめに

• iOS および iPadOS や Android 用のアプリを App Store や Google Play でリリースするというプロジェクトをスタートしたい場合、開発に必要となる作業や要件がよくわかってないと、それらにかかる工数をうまく見積ることができない。
• 本ナレッジでは、App Store と Google Play にアプリをリリースする開発プロジェクトをスタートすることになったという前提で、必要となる作業や要件について思いつく限りまとめてある。

① 開発方針

• ネイティブ開発なのかマルチプラットフォーム (クロスプラットフォーム) 開発なのかを最初に決めること。
  1. ネイティブ開発
     • そのプラットフォームの全ての機能を利用でき、最高のパフォーマンスを引き出せる。
     • 様々なツールが標準で用意されているので、デバッグやパフォーマンスチューニング (速度性能やバッテリー消費の改善等) も楽である。
     • 反面、そのプラットフォームのアプリ開発に要求される言語やフレームワークの習得が必要になる。
  2. マルチプラットフォーム開発
     • MVC (Model-View-Controller) 構造を持つアプリのモデル (Model) やビジネスロジックのコードを複数のプラットフォームで共通化できる。
     • UI の共通化もある程度は可能だが、ネイティブで実現できることの全ての UX の実現は無理で、かなりの制限が入る。
     • ネイティブ開発よりはデバッグやメンテナンスが困難になるので、そこで予想以上に工数が膨らんでしまい、工数削減に失敗してしまう可能性がある。
     • 採用したマルチプラットフォーム開発環境が提供するフレームワークを学習するだけで iOS と Android 両方で動作するアプリを開発できるが、Apple (iOS および iPadOS) や Google (Android) という必須のベンダーロックに加えて、そのマルチプラットフォーム開発環境へのベンダーロックが更に一つ増えてしまう。

開発方式を選択する時の判断基準

1. ネイティブ開発
   • ストアにリリースするような UX が重視されるコンシューマ向けのアプリは、ネイティブ開発が向いている。
   • 頻繁にアップデートを行うようなアプリは、ネイティブ開発が向いている。
   • 長期にわたってエンハンスされるアプリは、ネイティブ開発が向いている。
2. マルチプラットフォーム開発
   • iOS と Android で全く同じアプリをリリースする計画がある場合に、プロジェクトの方針としてある程度のコードの共通化を図りたい時には、マルチプラットフォーム開発が有効である。
   • ネイティブ開発に必要となる言語やフレームワークについて熟知しているエンジニアをどうしても確保できない時に、代替案として考えられる。
   • UX が重視されないアプリ (組織内利用を前提とした業務アプリなど) の開発に向いている。

開発方式の違いによるトータル工数は？

• トータル工数を見た場合、初期リリースにかかる工数についてはネイティブ開発とマルチプラットフォーム開発はどちらもほぼ同じであり、エンハンスを続けていくとマルチプラットフォーム開発の方がコスト増になるというのが個人的な見解になる。
  1. ネイティブ開発
     • ネイティブ開発の場合はどうしても立ち上げ時の学習コストがかかるが、一度理解してしまうと最高の生産性を発揮する。
     • Apple や Google の開発者へのサポートはネイティブ開発に対してのみ行われる。
     • 開発環境も、デバッガやパフォーマンス計測ツール、コードカバレージ計測ツール、メモリリーク解析ツール、自動テストツールなどのツールが多数揃っている。
     • 最新の iOS や Android への追従も、もちろん最速である。
  2. マルチプラットフォーム開発
     • マルチプラットフォーム開発は、採用している開発環境ではどうしても簡単には実現できない外部仕様への対応、実装が完了した後のデバッグやメンテナンスなど、開発工程の中盤以降に様々なトラブルが発生し、そのあたりの工数が予想以上に増大してしまう傾向がよく見られる。
     • マルチプラットフォーム開発環境が採用している開発言語 (JavaScript や C#) やフレームワーク (HTML5 / CSS3 や JavaScript や .NET) を見ると iOS や Android の開発言語を使うよりも簡単に作れそうな気になるが、それは幻想である。「誰でも簡単に始められる」ことと「誰でも簡単に作れる」ことの間には、大きな溝が存在する。
     • マルチプラットフォーム開発環境にはネイティブ開発環境ほどの便利なツールは揃っていない。
     • 最新の iOS や Android への追従が遅れがちになる。
     • 何か一つのプラットフォームへの対応のためだけにエンハンスを実施した場合に、全プラットフォームでのテスト、及びデグレードしていないことの確認作業が発生する。(これを怠ったために、新型コロナウイルス接触確認アプリ COCOA の Android 版は4ヵ月もまともに動作してなかったという事故を起こした。)
• 長期にエンハンスされることが予想できるアプリは、ネイティブ開発の方が、マルチプラットフォーム開発よりもエンハンス時の工数が圧倒的に少なく済む。
• 工数見積りにネイティブ開発の学習コストを積みにくいのでマルチプラットフォーム開発を選択してしまうプロジェクトも多いようだが、たとえマルチプラットフォーム開発を選択したとしても、見えないところでネイティブ開発と同等かそれ以上の学習コストがかかっていることを十分認識して開発方式を選択して欲しい。
  • マルチプラットフォーム開発環境に関する学習は必ず必要になるし、それに加えてネイティブ実装に関する学習も更に必要になってしまうことが多い。

ネイティブ開発のポイント

• ネイティブ開発の場合は、以下の言語とフレームワーク、そして開発環境について習得しなければならない。

※1 Android の第1言語は、いまや Java ではなくて Kotlin である。

• Swift と Kotlin は言語仕様がほとんど同じである。よって、片方の言語で実装できた内容は、(iOS SDK や Android SDK で提供されているクラスを利用していないならば) 簡単にもう一方の言語に移植できるし、たとえ SDK で提供されているクラスが違っても詳細設計についてはある程度共通化できる。

マルチプラットフォーム開発のポイント

• マルチプラットフォーム開発の場合は、採用する開発環境をどれにするかを慎重に決めること。
• 現在良く使われている開発環境は以下になる。
  1. Apache Cordova、Vue Native、React Native、Capacitor
     • モデルやビジネスロジックのコードを JavaScript で実装し、UI を HTML5 と CSS3 と JavaScript のフレームワークで実装する。
     • インタプリタ言語の JavaScript のコードが動くので、ネイティブほど処理は速くない。また、ネイティブと比較するとメモリ管理の面でも不利である。
     • Web エンジンの中で処理が走るのだが、Web エンジンは脆弱性がよく見つかるコンポーネントとして有名である。
     • Apache Cordova の場合、JavaScript や HTML だけでは実現できない機能はプラグイン等でカバーすることになるが、要求仕様を実現する高品質のプラグインが存在しないと開発が破綻する。Cordova の標準機能だけでは実現が難しい外部仕様は、基本的に諦めなければならない。
     • Vue Native の場合は、Vue.js に精通しているエンジニアを開発に流用できる。
     • React Native の場合は、React に精通しているエンジニアを開発に流用できる。
     • Capacitor は、ionic フレームワークを前提として Web アプリをネイティブアプリに変換する。
  2. Xamarin
     • モデルやビジネスロジックのコードを C# と .NET で実装し、UI を共通の Xamarin.Forms、もしくはネイティブな UI クラスに1対1でマッピングされているクラスで実装する。
     • UI を共通の Xamarin.Forms で実装する場合は、ネイティブと比べると表現力が落ちる。
     • ネイティブな UI クラスに1対1でマッピングされているクラスで UI を実装する場合は、ネイティブ UI 部品に関する知識が必要になる。つまり、Xamarin に加えてネイティブ 2種と、計3種の学習コストが発生してしまう。
     • ご参考：Xamarin.Forms のこれまでとこれから
  3. .NET MAUI
     • フルスペルは .NET Multi-Platform App UI となり、Microsoft が提供する Xamarin の後継になるマルチプラットフォーム環境である。
     • UI は C# と XAML で実装する。
  4. Flutter
     • Google が提供する iOS や Android などのアプリのマルチプラットフォーム開発環境である。Dart 言語で実装する。
     • 描画は独自レンダラで対応している。(つまり、UI は基本的に Flutter 独自のものになる。)

マルチプラットフォーム開発のリスク

• Apache Codrova は実装内容が古く、Vue Native はもはやメンテナンスされなくなってしまっており、Xamarin は2024年5月1日でサポートが終了することがアナウンスされたので、いずれも現時点では採用してはいけない。これがマルチプラットフォーム開発のリスクである。(苦労して開発したものがメンテナンスできないゴミになってしまう可能性がある。)
• もちろん、ネイティブ開発の場合も言語仕様が変わってしまうリスクが存在するのだが、こちらについては、例えば iOS の場合はマイグレーションのための手段が Apple からきちんと提供される。

メンテナンスと自動テスト

• スマートデバイス用の OS は強制的にバージョンアップされる。よって、新しいバージョンの OS への対応が早急に必要になる。
• 一般的に、ストアにリリースしたアプリには軽微なバグ修正や機能変更が度々入る。また、そのようなアップデートを定期的に行わないと利用者に飽きられて (見捨てられて) しまうことも多い。
• つまり、メンテナンスのためのプロセスを定義し、これらのメンテナンスとテストを行うための工数を見積もらなければならない。
• メンテナンスを行うたびに手作業でのテストを実行しているとトータル工数が膨大なものになる。スマートデバイス用のアプリ開発では、自動テストの導入が推奨される。
• マルチプラットフォーム開発を採用すると、たとえ特定のプラットフォームだけの変更が入ったとしても、全てのプラットフォームのテストとデグレードの確認が必要になる。このコストは無視できない。

② 開発全般

エンジニア問題

• 開発対象となる言語やフレームワークに精通しているエンジニアを自部署で育成、もしくは調達しなければならない。

※2 マルチプラットフォーム開発環境では実現できない外部仕様を実装する場合はネイティブ開発の知見が必要になる。

ソースコード管理 (構成管理)

• 例えば iOS および iPadOS アプリのネイティブ開発では Xcode がローカルな SCM (Source Control Management) 環境を作ってくれるが、その場合、ローカルな開発環境が壊れてしまったらそれでおしまいである。ソースコードを安全に保管したり、複数の人でコードレビューできるようにするためにも、リモートで利用できる構成管理システムを採用すべきである。

• iOS および iPadOS ネイティブ開発の場合、Xcode と連携可能な構成管理システムとしては以下が存在する。

  1. GitHub
     • クラウド環境でソースコードを構成管理してくれるサービスである。
     • GitHub Enterprise を契約すると、企業向けにセキュリティを強化されたサービスを利用できる。
  2. GitLab
     • GitHub と同様の思想を持つ、オープンソースのソースコード構成管理サービスである。
     • オープンソースなので、自社内に GitLab のサーバを立ち上げて運用することが可能である。

輸管問題

• App Store、Google Play 共に海外のサーバになるので、輸管問題 (輸出管理問題) が発生する。関連部署への連絡と調整を忘れないようにすること。

③ iOS および iPadOS 特有の作業・要件

Mac の調達

• iOS および iPadOS アプリは Mac がないと開発できない。ということで、開発用の Mac をレンタルするか購入すること。
• Mac がないと App Store のライセンスを管理したりアプリを提出したりすることができない。つまり、請負でアプリ開発する場合は、請負元の顧客も Mac の調達が必要になる。

サポート対象の決定

1. どのバージョンの iOS および iPadOS をサポートするのかを決めること。これがテスト工程の工数に影響する。
   • 一般的に、アプリをリリースする時期のメジャーバージョンとその一つ前のメジャーバージョンをサポートすれば十分だと言われている。
     ⇒ 例えば、2023年3月リリースであればiOS および iPadOS 15 と 16 をサポートするのが妥当である。
     • 参考資料：App Store - Support (iOS and iPadOS usage)
   • テストが大変になるが、可能であれば、まだセキュリティアップデートが配信されているバージョンをサポートすべきである。ちなみに、2023年2月の時点で2023年1月23日にセキュリティアップデートが配信されたバージョンは iOS 12.5.7 と iOS 15.7.3、そして iOS 16.3 になる。
     • ただ、iOS 12 をサポートすると必然的に iOS 13 と 14 もサポート対象になってしまうので、2023年2月の時点では iOS 15 と 16 をサポートすれば十分だろう。
2. どのデバイスをサポートするのかを決めること。
   • 最近の iPhone や iPad は画面サイズが様々だが、基本的に全てのデバイスをサポートすることになる。
     • iPhone の場合は Touch ID 搭載モデルと Face ID 搭載モデルの2種類を調達し、両方のデバイスで画面表示まわりの確認を行うことをお勧めする。
     • Face ID 搭載モデルには Safe Area という概念が導入されており、UI 部品はこの Safe Area に隣接するように画面配置しなければならない。UI 部品を画面の端にくっつくように配置してしまうと、Touch ID 搭載モデルでは問題なく表示されいていても、Face ID 搭載モデルではコンテンツの一部がノッチで隠れてしまったりソフトウェアキーボードの一部が隠れて文字入力しにくくなったりする。
   • iPhone アプリは iPad の上でも問題なく動かないと App Store の審査でリジェクトされるので注意すること。

iPhone や iPad の調達

• 開発、デバッグ、テスト (評価) 用の実機が必要になる。

開発ライセンス

• iOS および iPadOS のアプリをApp Store にリリースするためには Apple Developer Program のライセンスが必要になる。このライセンスをアプリをリリースする組織に取得してもらわなければならない (既に取得済みであれば問題ない)。
  ⇒ ライセンスの取得には (手戻りやトラブルが発生しなければ) 2週間程度を見ておくといいだろう。

Apple の審査ガイドラインの熟読

• App Store からリリースされるアプリには Apple の審査が入る。この審査でリジェクトされたアプリはリリースできない。
• App Store Review ガイドラインが公開されているので、そのガイドラインに違反しないように外部仕様を決めたり実装を進めたりすること。
• よくある却下理由を Apple が公開しているので、あらかじめ確認しておくことをお勧めする。
  • App Review
    ⇒ 「一般的な問題を回避するために」の項目を参照のこと。

開発中のアプリの評価

• 開発中のアプリを関係者に評価してもらう手順をあらかじめ考えておくこと (関係者に見てもらう直前になって検討しても計画したスケジュールに間に合わないことが多い)。

App Store へのリリース

• App Store へのリリースは、Android アプリの Google Play へのリリースと比較すると多少面倒になる。いくつかの手段を考えられるので、もしも請負開発の場合は請負元と協議して決めること。
  1. ソースコードを含むプロジェクト一式までを納入する成果物とし、そこからリリース用アプリをビルドして App Store に提出するタスク以降を請負元責任とする。
  2. 請負元のライセンスでデジタル署名したアーカイブを納入する成果物とし、そのアーカイブを App Store に提出するタスク以降を請負元責任とする。
• App Store にアプリを提出する際に、いくつかのメタデータ (スクリーンショットやアプリの説明、公式リンク、検索キーワード、年齢制限やプライバシーの説明等) が必要になる。これらを準備したり作成したりする工数もそれなりに馬鹿にできないので注意すること。
  • 要求される最新のメタデータの全ては実際に提出してみないとわからないので、請負開発の場合は請負元責任としてしまうのが理想である。
  • 中身が適当なアプリを使っていいので、リリース直前までを一度予行演習して、必要になるメタデータの詳細や正式なアプリ提出にかかる工数を調査しておくことをお勧めする。
• いずれにしても、App Store へのリリース手順の具体的な解説を要求された場合は、説明工数もそれなりにかかると思った方がよい。

App Store へのアプリ提出からリリースまでの期間

• 一般化はできないが、App Store へのアプリ提出からリリースまでの期間は、初期リリースの場合は約2週間、アップデートの場合は約5日間だと言われている。

リジェクトへの対応

• リリース対象のアプリが審査された結果リジェクトされた場合のことを想定し、その対応を行うための工数とスケジュールを計画しておくこと。
  • 審査ガイドラインに沿って開発を進めたのなら、ほとんどの場合小さな指摘の対応だけで済むはずである。その場合は1週間程度を見込んでおくと大丈夫だろう。

Apple のアナウンスのチェック

• Apple は、開発者に対してニュースとアップデートというページを公開しており、ここに、今後のとても重要な変更点を逐次アナウンスしている。
• iOS および iPadOS アプリをリリースしたプロジェクトは、少なくとも週～月に一回はこのページをチェックし、今後必ず発生するであろうエンハンスの概要を把握してメンテナンス計画を立てなければならない。
  • ニュースとアップデートのページの右上に RSS (feed://developer.apple.com/jp/news/rss/news.rss) が公開されているので、RSS を使った通知を受け取りたい人はこれを使うとよい。
• ちなみに、過去には以下のような重要なアナウンスが流れている。

④ Android 特有の作業・要件

サポート対象の決定

• どのバージョンの SDK か、そしてどの Android デバイスをサポートするのかを慎重に決めること。これがテスト工程の工数に影響する。

Android デバイスの調達

• 開発、デバッグ、テスト (評価) 用の実機が必要になる。

Google ディベロッパーアカウント

• アプリをリリースする組織に Google Play のリリース用アカウント (Google ディベロッパーアカウント) を取得してもらっておくこと。

Google Play へのリリース

• 請負開発の場合、Android に関しては、開発側は正しくデジタル署名した .apk ファイルを作って請負元に渡しさえすれば、あとは請負元のタスクになる。

APPENDIX：開発に関する公式情報

• 以下のページを見ると開発に必要な情報はほぼ全て手に入る。知りたいことがあれば、まずはここを参照すること。

Apple

• Apple Developer
• Apple Developer Program
• Human Interface Guidelines
• Xcode
• Swift
  • Swift - リソース
• Documentation Archive
  ⇒ Sample Code
• App Store
  • App Review
  • App StoreにAppを提出する
  • App Store Connect ヘルプ
• ニュースとアップデート

Google

• Android デベロッパー
• デベロッパー ガイド
• Android 向けのデザイン
• Android Studio
• Kotlin プログラミング言語を学ぶ
• サンプルコード
• アプリをテストする
• Google Play で配布する