5.7 モバイルアプリケーション開発

概要と動機

モバイルアプリケーション開発とは、スマートフォンとタブレットのためのソフトウェアを築く規律です。多くの人にとって、スマートフォンは今や、主要な、あるいは唯一の所有するコンピューターです。それは、モバイルアプリをサービスの玄関口にし、ユーザーが組織全体を判断する面になることもよくあります。

モバイルは、ウェブやデスクトップの小さな版ではなく、独自のエンジニアリング環境です。デバイスはポケットの中で、バッテリーで、出たり消えたりする接続で動きます。画面は小さい。オペレーティングシステムが、アプリに許されることを制御します。二つの支配的なプラットフォーム(AppleのiOSとGoogleのAndroid)があり、それぞれ独自の言語、デザインのルール、ストアを持ちます。好きなときにアップデートを出荷することはできません。ストアが先にレビューし、ユーザーがインストールするタイミングを選ぶからです。本章は、フロントエンドエンジニアリング(5.6章)、UXの基礎(5.1章)、アクセシビリティ(5.3章)の上に築かれ、アプリケーションセキュリティ(4.2章)とCI/CDとデリバリー(8.1章)に依拠します。

企業と政府にとっての関連性は高い。企業は顧客向けのアプリと、自社の従業員向けの社内アプリを出荷し、しばしばモバイルデバイス管理(MDM:会社のデバイスを設定し保護する中央のソフトウェア)を通じて管理されます。政府は、給付、医療、本人確認、決済のための市民向けのアプリを築き、古いデバイスと遅い接続の人々を含む全員に、アクセシビリティの法律のもとで仕えなければなりません。どちらの設定でも、モバイルは重大で長寿命のコミットメントなので、他の本番システムに与えるのと同じ厳密さで扱ってください。

主要原則

デバイスのために設計します。小さな画面、バッテリー、出たり消えたりするネットワーク。
断続的な接続を想定します。オフラインファーストで動き、できるときに同期します。
各プラットフォームのデザインと操作の慣習を尊重します。
リリースのタイミングは制御できません。ストアとユーザーが握っています。
断片化は普通です。実際の範囲のデバイスとOSバージョンをサポートします。
デバイスは紛失し盗まれるので、デバイス上のデータは安全に保存します。
アクセシビリティは要件であり、仕上げではありません。
立ち上げの日だけでなく、アプリの全生涯にわたってビルドのアプローチを選びます。

推奨事項

ビルドのアプローチを意図して選ぶ

大きく三つのアプローチがあり、それぞれ異なるニーズに合います。

ネイティブ開発とは、プラットフォームごとに、そのプラットフォーム独自のツールで別々に書くことです。iOSにはSwift、AndroidにはKotlin。最高のパフォーマンス、デバイス機能への最も完全なアクセス、最も忠実なプラットフォームの感触が得られますが、二つのコードベースを築き保守するコストがかかります。

クロスプラットフォームのフレームワークは、一つのコードベースで両方のプラットフォームを対象にできます。React NativeはJavaScriptを使い、本物のネイティブコンポーネントを描画します。FlutterはDart言語を使い、独自のウィジェットを描画します。これらは重複した労力を減らし、デリバリーを速められますが、フレームワークの健全性への依存を加え、最新のプラットフォーム機能に遅れることがあります。

プログレッシブウェブアプリ(PWA:インストールでき、オフラインで動けるウェブサイト)は、ストアを必要とせず、即座に更新されますが、一部のデバイス機能へのアクセスが限られ、ホーム画面での存在感が弱くなります。

必要なデバイス機能、パフォーマンスの特性、保守の期間、採用できる技能、必要な到達範囲に基づいて選びます。高パフォーマンスの消費者向けアプリはネイティブを正当化するかもしれません。小さなチームによるコンテンツとフォームのアプリには、クロスプラットフォームやPWAがよく合うかもしれません。

プラットフォームのデザインガイドラインに従う

各プラットフォームには、公開された詳細な慣習があります。Appleはヒューマンインターフェースガイドラインを、Googleはマテリアルデザインを提供しています。これらはナビゲーション、ジェスチャー、タイポグラフィ、余白、システムの振る舞いを扱います。それに従うことで、アプリは馴染み深く感じられ、ユーザーが学ぶ労力が下がります。それに逆らうと、アプリは異質でぎこちなく感じられます。クロスプラットフォームのコードベースでも、一方のプラットフォームの見た目をもう一方に強いるのではなく、異なる所ではプラットフォームごとの慣習を尊重する必要があります。

モバイルの制約のために設計する

オフラインファーストで築きます。中核のタスクが接続なしに動き、変更をローカルに保存し、ネットワークが戻ったときに同期するようにします。同じデータが二か所で変わったときの競合を慎重に扱います。バッテリーとデータを節約します。ネットワーク呼び出しをまとめ、絶え間ない位置情報やバックグラウンドの作業を避け、ペイロードを圧縮し、ユーザーのデータ節約の設定を尊重します。断片化、つまり画面サイズ、デバイスの性能、OSバージョンの幅広い広がりに備えます。実際の使用データに基づいてサポートの範囲を選び、最上位機種だけでなく、控えめなハードウェアでテストします。明確な階層、大きなタッチターゲット、異なるサイズと向きに適応するコンテンツで、小さな画面のために設計します。

配布、バージョニング、更新を計画する

公開はApple App StoreとGoogle Playを通じて行われ、それぞれがリリースを遅らせたり拒否したりしうるレビューのプロセスと方針を持ちます。レビューの時間をスケジュールに組み込み、方針を早期に読んでください。ユーザーが更新するタイミングを選ぶので、常に多くのバージョンが同時に現場にあります。古いクライアントとの後方互換性を保ち、古いアプリが動き続けるようにAPIのバージョンを管理します(2.3章)。必要なときに更新を要求する方法を用意し、たとえばバージョンが安全でない、あるいはサポート外のときに強制更新の確認を出し、それは控えめに使います。企業は、公開のストアではなく、MDMや非公開のチャネルを通じて社内アプリを配布することもできます。

プッシュ通知とディープリンクを慎重に使う

プッシュ通知は、アプリが閉じているときにユーザーに届けます。本物の価値のために使い、ユーザーの同意とプラットフォームの権限を尊重し、ノイズを避けてください。踏み込みすぎるアプリの通知を、人々は無効にするからです。ディープリンクは、リンクや通知からユーザーを特定の画面に直接送ります。リンクがアプリ内の正しい場所を開き、アプリがインストールされていないときにはウェブに穏やかにフォールバックするよう設定します。

アプリとそのデータを守る

デバイスを信頼できず、紛失するかもしれないものとして扱います。機微なデータは、プレーンなファイルではなく、プラットフォームの安全なストレージ(iOSキーチェーンあるいはAndroid Keystore)に保存します。機微な操作のロック解除には、パスコードに裏打ちされた生体認証(指紋あるいは顔)を提供します。価値の高い接続には証明書ピンニング(サーバーが期待される証明書を提示することの確認)を検討し、それらの証明書のローテーションを計画します。デバイスに保存するものを最小化し、シークレットを守り、アプリケーションセキュリティ(4.2章)のより広いガイダンスに従います。

本物のテストとデリバリーのパイプラインを築く

エミュレーターやシミュレーターだけでなく、本物のデバイスでテストします。ハードウェア、センサー、パフォーマンスが異なるからです。デバイスラボやクラウドのデバイスファームを使い、代表的なモデルとOSバージョンの広がりをカバーします。公開リリースの前のテスターへのベータ配布を含め、継続的インテグレーションとデリバリー(8.1章)を通じて、ビルド、テスト、署名、ストアへの提出を自動化します。署名の鍵とストアの資格情報を安全に管理することは、このパイプラインの一部です。

アクセシビリティを要件にする

各プラットフォームのアクセシビリティ機能をサポートします。スクリーンリーダー(iOSのVoiceOver、AndroidのTalkBack)、動的なテキストサイズ、十分な色のコントラスト、大きなタッチターゲット。支援技術が説明できるよう、コントロールにラベルを付けます。自動チェックだけでなく、実際の支援ツールでテストします。特に政府にとって、アクセシビリティは法的義務であり、詳細はアクセシビリティ(5.3章)にあります。

トレードオフ: 長所と短所

アプローチ	長所	短所
ネイティブ(Swift、Kotlin)	最高のパフォーマンス、完全なデバイスアクセス、本物のプラットフォームの感触	二つのコードベース、高いコスト、より多くの人員
React Native	一つのJavaScriptコードベース、本物のネイティブコンポーネント、速い反復	フレームワークへの依存、ブリッジの複雑さ、機能の遅れ
Flutter	一つのコードベース、一貫したUI、強いパフォーマンス	Dartの技能が少ない、アプリサイズが大きい、独自のウィジェットモデル
プログレッシブウェブアプリ	ストア不要、即座の更新、一つのウェブのコードベース	限られたデバイス機能、弱い存在感、プラットフォームの制限
強制更新	安全でない古いバージョンを素早く取り除く	使いすぎるとユーザーを苛立たせる。アクセスをブロックしうる
証明書ピンニング	傍受に対する強い保護	アプリの更新なしに証明書がローテーションされると壊れる

繰り返されるトレードオフは、到達範囲とデリバリーの速度対、深さと忠実度です。ネイティブは最も豊かで忠実な体験を与えますが、築き保守するのに最もコストがかかります。クロスプラットフォームとPWAのアプローチは、プラットフォームの感触やデバイスへのアクセスをいくらか犠牲に、労力を節約し到達範囲を広げます。フォームとコンテンツを出荷する小さなチームにとって、コードベースを共有することはしばしば賢明です。要求の厳しい消費者向けアプリでは、ネイティブの深さが価格に見合うかもしれません。立ち上げだけでなく、アプリの全生涯を視野に入れて決めてください。

チームで議論すべき問い

古いクライアントを現場でどれだけの期間サポートし、APIは動き続けるようにバージョン管理されていますか。 ユーザーが更新するタイミングを選ぶので、常にアプリの多くのバージョンが同時にインストールされており、全員が最新だと想定するバックエンドの変更は、古いクライアントの長い尾を壊します。後方互換性の期間を決め、古いアプリが動き続けるようAPIにバージョンを付け、本当に安全でないバージョンのために、まれにしか使わない強制更新の経路を保ってください。これは政府の市民向けアプリにも企業の従業員向けアプリにも重要で、古いデバイスの人々は、あなたの予定でアップグレードできない、あるいはしません。現在のバージョン分布のデータを持ち込み、実際に使われている最古のクライアントで何が壊れるかを問ってください。その分布を知らないなら、次の破壊的変更を出荷する前に計装してください。
プッシュ通知を送る基準は何で、ユーザーを中断する価値があるものを誰が決めますか。 プッシュ通知はアプリが閉じているときに人々に届くので、強力で乱用しやすく、ユーザーは踏み込みすぎるプロダクトの通知を(あるいはアプリごと)無効にします。何が本物の価値に当たるか、ユーザーが頻度とチャネルをどう制御するか、許可を催促し続けるのではなく、プラットフォームの同意をどう尊重するかに合意してください。共有の基準がなければ、達成すべき指標を持つすべてのチームがプッシュに手を伸ばし、チャネル全体がノイズに劣化します。先月に送った通知を持ち込み、どれをユーザーが感謝したかを問ってください。ほとんどが販促なら、オプトアウト率があなたに代わってそうする前に、方針を引き締めてください。
モバイルのデリバリーのパイプラインは本物で、署名、デバイスファーム、ベータ配布をカバーしていますか。それとも、リリースはストレスの多い手作業の大慌てですか。モバイルは、ウェブにはない危険を加えます。ストアのレビューがリリースを遅らせたり拒否したりしえ、署名の鍵とストアの資格情報を安全に扱う必要があり、ハードウェアとセンサーは、エミュレーターが本物の問題を隠すほど異なります。ビルド、テスト、署名、ストアへの提出をCI/CDで自動化し、テスターへのベータ配布と、ユーザーが実際に持つモデルをカバーするクラウドのデバイスファームを備えることが、リリースを英雄的な努力から日常に変えます。誰がパイプラインと署名の鍵を所有するか、ストアのレビューの時間をすべてのリリース計画にどう組み込むかを決めてください。前回のリリースの話を持ち込み、手作業のステップを数えてください。一つ一つが、期限のもとでストレスの多いリリースが間違いうる場所です。
ネイティブ、クロスプラットフォーム、プログレッシブウェブアプリを、立ち上げの日だけでなく、このプロダクトの全生涯のために選びましたか。ビルドのアプローチは、何年にもわたるモバイルアプリのコストと能力に対する単一で最大のてこであり、速く出荷するために下された選択は罠になりえます。ネイティブは、二つのコードベースと二組の技能の対価に、最も豊かなデバイスアクセスとプラットフォームの感触を買い、クロスプラットフォームとPWAはコードを共有しますが、フレームワークへの依存を加えたり、一部のデバイス機能へのアクセスを失ったりします。大きなチームにとって、この決定は採用、保守の予算、毎年のOSリリースをどれだけ速く採用できるかを駆動するので、最初のプロトタイプを書いた誰かが設定した既定ではなく、明示的な所有者に値します。必要なデバイス機能、パフォーマンスの特性、保守の期間、実際に採用できる技能を持ち込み、各選択肢のもとでどのプラットフォームの機能を手放すかを誠実に述べてください。企業と政府の設定では、アプリが、人員の入れ替わりと十年のプラットフォームの変化を生き延びなければならない長寿命のコミットメントかを量り、将来のチームが、なぜコードベースがこうなっているのか推測せずに済むよう、決定とその根拠を記録してください。
実際のユーザーにはどのデバイスとOSバージョンのサポート範囲が必要で、机の上の携帯電話ではなく、彼らが実際に持つハードウェアでテストしていますか。断片化はモバイルの普通の状態です。ユーザーは画面サイズ、デバイスの性能、OSバージョンの幅広い広がりにわたり、チームの最上位機種で調整されたアプリは、オーディエンスの多くが持つ控えめなハードウェアでは、もたついたり壊れたりして出荷されます。サポートの範囲を設定することは、到達範囲と労力のトレードオフです。サポートを約束する古いモデルとOSバージョンの一つ一つが、テストのマトリックスと保守の負担を広げるので、範囲は想定ではなく実際の使用データから来なければなりません。デバイスとOSバージョンの分布、クラウドのデバイスファームやラボが現在カバーするモデル、シミュレーターだけでなく低価格のハードウェアで測定したパフォーマンスを持ち込んでください。政府の市民向けアプリでは、これはほぼ交渉の余地がありません。アクセシビリティの義務のもとで、古いデバイスや遅い接続の人々を含む全員に仕えなければならないからで、企業の端末群では、一般的なサンプルではなく、従業員が持つ頑丈なハンドセットそのものをテストすべきです。
デバイスにはどんな機微なデータが存在し、それぞれは、紛失、盗難、他人の手に渡った電話から守られていますか。 モバイルデバイスはポケットの中を移動し、紛失や盗難に遭うので、プレーンなファイルに保存されたデータやシークレットは、置き忘れた電話一台で露出し、影響範囲はユーザーごとに増えます。考慮は互いに引き合います。デバイスにデータをキャッシュすることが、オフラインファーストを機能させアプリを速く保つものですが、キャッシュされた各項目は、プラットフォームの安全なストレージ(iOSキーチェーンあるいはAndroid Keystore)に置かれ、最小化され、理想的には生体認証やパスコードの背後に置かれなければならない負債です。アプリがローカルに永続化するものの正確な目録、各項目がどこに保存されるか、何がそれを開くか、価値の高い接続が実行可能なローテーション計画を伴う証明書ピンニングを使うかを持ち込んでください。企業の設定では、これをモバイルデバイス管理の方針とリモートワイプに結びつけ、政府の設定では、デバイス上の個人データを、正当化され、文書化され、監査のもとで擁護できなければならない、プライバシーと法的な露出として扱ってください。

セクター別の視点

スタートアップ。 小さなチームと乏しい猶予では、二つのネイティブのコードベースや二組の技能を持つ余裕はまずないので、一つのコードベースから両方のストアに届くクロスプラットフォームのフレームワークや、PWAさえもが、通常勝ちます。重要な一つの中核のタスクをオフラインファーストで出荷し、トークンはプレーンなファイルではなく安全なストレージに保ち、拒否がローンチの日付を吹き飛ばさないよう、ストアのレビューの時間をすべてのリリースに組み込みます。強制更新、証明書ピンニング、デバイスファームは、実際の使用が正当化するまで飛ばしてください。

小規模事業者。 モバイルの専門家がおらず予算も厳しいので、築くより買うに強く傾いてください。ノーコードのアプリビルダー、販売時点管理や予約のベンダーからのホワイトラベルのアプリ、既存のウェブサイトから作るよくできたPWAは、保守できないオーダーメイドのアプリにしばしば勝ります。アプリを委託するなら、請負業者があなたの存在を人質に取れないよう、署名の鍵とストアのアカウントを自分で所有し、契約でアクセシビリティと安全なデバイス上のストレージを主張してください。範囲は、顧客が電話で実際に行う一つか二つのタスクに保ちます。

大企業。 規模では、アプリは多くのチームにわたる長寿命のコミットメントなので、各プロダクトが再発明するに任せず、ビルドのアプローチ、安全なストレージのパターン、CI/CDのパイプライン、APIのバージョニングの方針を標準化してください。社内の従業員向けのアプリは、通常、インストール、設定、リモートワイプ、方針のためにモバイルデバイス管理を通り、顧客向けのアプリは、実際の使用をカバーするデバイスファームと、監査されたアクセシビリティとセキュリティを必要とします。破壊的なバックエンドの変更が古いクライアントの長い尾を取り残さないよう、署名の鍵、ストアの資格情報、リリースのタイミングを中央で統治します。

政府。 調達規則、透明性、公的な説明責任があらゆる選択を形づくります。古いデバイスや遅い接続の人々を含む全員に仕えなければならないので、アクセシビリティは本物の支援ツールで検証される法的義務であり、幅広いデバイスのサポート範囲はほぼ交渉の余地がありません。ベンダーロックインを避け、データを可搬に保ち、アプリが彼らのデータで何をするかを公衆が検査できるアプローチと契約を好み、デバイス上の個人データを、監査のもとで正当化し文書化しなければならない露出として扱ってください。

事例

スタートアップ。 習慣トラッキングのアプリを築く3人のスタートアップは、iOSとAndroidの両方に届く必要がありましたが、二つのネイティブのコードベースや二組の技能を持つ余裕はありませんでした。一つの小さなチームが両方のストアに出荷できるようクロスプラットフォームのフレームワークを選び、最初からオフラインファーストで設計して、ユーザーが電波のない地下鉄で習慣を記録し、後で同期できるようにしました。ログインのトークンはプレーンなファイルではなくプラットフォームの安全なストレージに保ち、ストアのレビューの時間をすべてのリリース計画に組み込み、自分たちの端末と並べて、安価な古い電話を数台でテストしました。それが、そうでなければ出荷していたもたつくパフォーマンスを捉えました。

大企業。 物流会社は、ドライバーと倉庫のスタッフのための社内アプリを築きました。倉庫と配送ルートは電波がまだらなので、チームはオフラインファーストの設計を選びました。スキャンとステータスの更新はローカルに保存され、接続が戻ったときに同期します。小さなチームで両方のプラットフォームに一つのコードベースを提供するため、クロスプラットフォームのフレームワークを使いました。アプリは公開のストアではなくモバイルデバイス管理を通じて配布されるので、ITが会社のデバイスのインストール、設定、セキュリティの方針を制御します。機微な資格情報はプラットフォームの安全なストレージにあり、生体認証がアプリのロックを解除します。クラウドのデバイスファームが、スタッフが実際に持つ頑丈なハンドセットの代表的な広がりをテストします。

政府。 国の機関は、本人確認と給付のための市民向けのアプリを出荷しました。アクセシビリティは初日から固い要件でした。完全なスクリーンリーダーのサポート、動的なテキストサイズ、強いコントラストを、法律を満たすために本物の支援ツールでテストしました。市民が非常に幅広いデバイスを使うので、チームは古いモデルと遅い接続の幅広い帯域をサポートし、中核のタスクをオフラインで動かし続けました。機微なデータは安全なデバイスのストレージにあり、生体認証がアクセスを守り、価値の高い接続は計画されたローテーションのプロセスを伴う証明書ピンニングを使います。APIのバージョニングが古いインストール済みのアプリを動かし続け、セキュリティ修正のために、まれにしか使わない強制更新の経路があります。ストアのレビューのスケジュールは、すべてのリリース計画に組み込まれています。

ビジネスケース: 動機、ROI、TCO

モバイルは多くのユーザーがサービスに出会う場所なので、アプリは、組織にとって重要なタスクの採用、満足度、完了に影響します。速く、信頼でき、よくデザインされたアプリは、利用を増やし、サポートの負荷を減らします。企業にとって、社内のモバイルアプリは、モバイルの従業員を測定可能に生産的にし、書類仕事を削れます。政府にとって、使いやすい市民向けアプリはアクセスを広げ、コールセンターと対面の需要を減らします。

総所有コスト(TCO)では、アプローチの選択が最大のてこです。ネイティブは、アプリの全生涯にわたって、二つのコードベースと二組の技能に払うことを意味します。クロスプラットフォームは、そのいくらかを、最新に保たなければならない依存関係と交換します。コードを超えて、ストアの手数料とレビューのサイクル、デバイスのテストラボやクラウドのファーム、プラットフォームが毎年リリースされるにつれた継続的なOSバージョンのサポート、モバイルが求めるセキュリティの仕事に予算を付けてください。投資不足のコストは、サポート外のデバイスでのクラッシュ、保護されていないデバイス上のデータによるセキュリティインシデント、拒否あるいは遅延したリリース、遅くぎこちないアプリを放棄するユーザーとして現れます。

リーダーシップに論拠を示すには、アプリを具体的な成果に結びつけます。タスクの完了、定着、従業員の生産性、あるいは削減されたサポートコスト。最初のリリースだけでなく、アプリの生涯にわたるアプローチの決定を値付けし、本格的なモバイルの実践が減らすリスク(セキュリティ、アクセシビリティの法律、ストアの拒否)を名指ししてください。

アンチパターンと落とし穴

モバイルを縮めたウェブサイトとして扱う: タッチ、ジェスチャー、プラットフォームの慣習を無視すること。
完全なネットワークの想定: オフラインの処理がなく、電波が落ちた瞬間にアプリが壊れること。
最新の最上位機種だけでのテスト: 実際のユーザーが持つデバイスでの貧しいパフォーマンスを隠すこと。
シークレットをプレーンなファイルに保存する: デバイスが紛失あるいは盗難に遭ったときに機微なデータが露出すること。
通知の過負荷: プッシュが多すぎて、ユーザーがアプリをミュートしたり削除したりすること。
ストアのレビュー時間の無視: 即時の公開を想定し、その後遅れるリリース計画。
強制更新の経路がない: 安全でない古いバージョンが、廃止する手段なしに生き続けること。
バッテリーとデータの消耗: ユーザーが気づく、絶え間ないバックグラウンドの作業とおしゃべりなネットワーキング。
後回しのアクセシビリティ: ユーザーを排除し、政府では法律を破ること。
どこでも同一に見えるよう強いられた一つのコードベース: 両方のプラットフォームで異質に感じられるアプリ。

成熟度モデル

レベル1: 開始。 モバイルはその場しのぎで反応的です。アプリはウェブサイトのように築かれ、チーム自身の電話でテストされ、しばしばオフラインで壊れます。安全なストレージ、アクセシビリティ、ストアのレビューのスケジュールへの配慮はほとんどありません。リリースはストレスの多い手作業の大慌てで、誰もビルドのアプローチや署名の鍵を所有しません。

レベル2: 発展。 基本的な実践が現れますが、チームとプロダクトの間で一貫しません。あるアプリにビルドのアプローチが選ばれ、プラットフォームの基本に従い、少数の本物のデバイスでテストされ、いくらかのオフラインの処理と安全なストレージがあります。ビルドは部分的に自動化され、誰かがストアの提出を所有しますが、別のチームのアプリは、これらすべてを異なって行うか、まったく行わないかもしれません。

レベル3: 標準化。 良い実践が文書化され、組織全体で徹底されています。オフラインファーストが既定で、文書化されたデバイスのサポート範囲がデバイスラボあるいはクラウドのファームでテストされ、プラットフォームのデザインガイドラインとアクセシビリティが、本物の支援ツールで従われ検証されています。安全なストレージ、生体認証、APIのバージョニングが標準で、CI/CDがビルド、テスト、署名、ベータ配布を自動化し、ストアのレビューの時間がすべてのリリースに計画されています。

レベル4: 管理。 モバイルの品質が、ベースラインに対して測定され、制御されています。クラッシュ、コールドスタートと画面描画のパフォーマンス、バッテリーとデータの使用、タスクの完了率が、実際のデバイスから継続的に取得されて目標に対して追跡され、モデルごととOSバージョンごとの内訳によって、低価格のハードウェアでの回帰が、出荷されるのではなく捉えられます。アクセシビリティとセキュリティは想定ではなく監査され、通知のオプトアウト率と更新の採用率が監視され、サポート範囲とビルドのアプローチは、この証拠でレビューされます。リリースの廃棄あるいは修正の決定は、リーダーの電話でアプリがどう感じられたかではなく、指標に基づきます。

レベル5: オーケストレーション。 モバイルは、継続的に改善され、組織全体に統合され、デバイスの状況が変わるにつれて適応します。証明書のローテーション、強制更新の経路、ロールバックは日常的で、サポート範囲とビルドのアプローチは、プラットフォームが毎年リリースされるにつれて、証拠に基づいて再スコープされ、ユーザーとデバイスの全範囲が第一級として扱われます。モバイルの計画はセキュリティ、アクセシビリティ、API、デリバリーの実践と結びついているので、OSの変更、新しいデバイスの階層、方針の変化は、緊急事態ではなく日常の仕事として吸収されます。

議論のためのアイデア

あるプロダクトについて、ネイティブ、クロスプラットフォーム、プログレッシブウェブアプリの間をどう決めますか。
実際のユーザーデータに合うデバイスとOSバージョンのサポート範囲は何で、それをどう最新に保ちますか。
アプリのどこでオフラインファーストが不可欠で、同期の競合をどう扱いますか。
強制更新はいつ正当化され、ユーザーを不当にブロックするのをどう避けますか。
ユーザーを反映する規模で、本物のデバイスでどうテストしますか。
デバイスにはどんな機微なデータが存在し、それぞれはどう守られていますか。
共有のコードベースから、各プラットフォームの慣習をどう尊重しますか。

要点

ビルドのアプローチ(ネイティブ、クロスプラットフォーム、PWA)を、アプリの全生涯のために選びます。
アプリが馴染み深く感じられ、ユーザーの労力が下がるよう、プラットフォームのデザインガイドラインに従います。
モバイルの制約のために設計します。オフラインファースト、バッテリーとデータの節約、断片化、小さな画面。
リリースのタイミングは制御できません。ストアのレビュー、バージョニング、強制更新に備えます。
プッシュ通知とディープリンクは、抑制と同意をもって使います。
安全なストレージ、生体認証、必要な所では証明書ピンニングで、デバイス上のデータを守ります。
本物のデバイスでテストし、CI/CDでモバイルのパイプラインを自動化します。
アクセシビリティを要件にします。政府にとっては法的義務です。

参考文献とさらなる読み物

Apple, Human Interface Guidelines
Google, Material Design guidelines
Apple, App Store Review Guidelines
Google, Google Play developer policies and Android developer documentation
OWASP, Mobile Application Security Verification Standard (MASVS) and Mobile Security Testing Guide
React Native project documentation
Flutter project documentation
Google, web.dev guidance on progressive web apps
U.S. Section 508 and WCAG (Web Content Accessibility Guidelines) references for mobile accessibility
NIST, Guidelines on mobile device security and management