Kotlin vs SwiftUI：iOSとAndroidで一つのプロダクトの一貫性を保つ

なぜ2つのスタックで一つのプロダクトを揃えるのが難しいのか

機能リストが同じでも、iOSとAndroidで体験が違って感じられることはよくあります。各プラットフォームにはデフォルトの慣習があり、iOSはタブバー、スワイプ操作、モーダルシートに傾き、Androidは目に見える戻るボタンやシステムの戻る挙動、異なるメニューやダイアログパターンを期待します。同じプロダクトを二度作ると、こうした小さな差が積み重なります。

KotlinとSwiftUIの選択は単なる言語やフレームワークの違いではなく、画面の見え方、データ更新の考え方、ユーザー入力の扱いに関する二つの前提の違いでもあります。要件が「iOSのように」や「Androidをコピー」といった書き方だと、一方は必ず妥協したものになってしまいます。

チームが一貫性を失うのは、大抵ハッピーパスの画面間の隙間で起きます。デザインレビューではフローが揃って見えても、読み込み状態、権限プロンプト、ネットワークエラー、ユーザーが離れて戻ってきた場合の扱いといったケースを追加するとずれていきます。

パリティは予測しやすい箇所で最初に壊れます：画面の順序が各チームの「簡略化」により変わる、BackとCancelの挙動が違う、空状態/読み込み/エラーの文言が違う、フォーム入力が受け付ける文字が違う、バリデーションが走るタイミングが（入力中／フォーカスアウト／送信時）変わる、などです。

実用的な目標は「UIを完全に一致させること」ではありません。両方のスタックが同じ場所に到達するよう、挙動を十分に明確に記述した一連の要件を持つことです：同じ手順、同じ意思決定、同じエッジケース、同じ結果が得られることを目指します。

共有要件に対する実践的アプローチ

難しいのはウィジェットではなく、一つのプロダクト定義を保つことです。UIが少し違って見えても、両方のアプリが同じように振る舞うようにします。

まず要件を二つのバケットに分けます：

• 必ず一致させるもの： フローの順序、主要な状態（読み込み/空/エラー）、フィールドルール、ユーザー向けの文言。
• プラットフォーム固有でよいもの： トランジション、コントロールのスタイリング、小さなレイアウトの違い。

誰もコードを書き始める前に共通の概念を平易な言葉で定義してください。"画面"とは何か、"ルート"とは何か（userId のようなパラメータを含む）、"フォームフィールド"とは何か（型、プレースホルダ、必須、キーボード）、"エラー状態"に何が含まれるか（メッセージ、ハイライト、いつクリアされるか）を合意します。こうした定義があれば後で議論になる箇所を減らせます。

実装方法を指定するのではなく、成果を示す受け入れ基準を書きます。例：「ユーザーがContinueをタップしたら、ボタンを無効化しスピナーを表示し、リクエスト完了まで二重送信を防ぐ」。これはどちらのスタックでも明確で、実装方法を限定しません。

ユーザーが気づく細かい点（タイトル、ボタン文言、ヘルパーテキスト、エラーメッセージ）、状態挙動（読み込み/成功/空/オフライン/権限拒否）、フィールドルール（必須、最小長、許可文字、フォーマット）、主要イベント（送信/キャンセル/戻る/リトライ/タイムアウト）、および解析名（使うなら）は単一のソースにまとめておきます。

シンプルな例：サインアップフォームでは「パスワードは8文字以上、最初のフォーカスアウト後にルールヒントを表示し、ユーザーが入力するとエラーをクリアする」と決めます。見た目は異なってよいが、挙動は同じにします。

ナビゲーション：同じフローを強制せずに合わせる

ユーザージャーニーをマップし、画面を写すのではなくタスク完了までのステップを書きます。例えば「閲覧 - 詳細を開く - 編集 - 確認 - 完了」。経路が明確になれば、各プラットフォームの最適なナビゲーションスタイルを選んでもプロダクトの挙動は変わりません。

iOSは短いタスクにモーダルシートを好み、明確に閉じられることが多い一方、Androidはバックスタック履歴とシステムの戻るボタンに頼ります。どちらでもルールを先に定義すれば同じフローを支えられます。

トップレベルにはタブ、深掘りにはスタック、限定的タスクにはモーダル/シート、ディープリンクや重要操作には確認ステップ、などの標準的な要素を混ぜても、フローと結果が変わらなければ問題ありません。

要件を一貫させるため、ルート名を両プラットフォームで同じにして入力（パラメータ）も揃えてください。orderDetails(orderId) はどこでも同じ意味で、IDがない・無効な場合どうなるかも共通にします。

戻る挙動と破棄ルールは明確に書いておきます。ここがずれやすい箇所です：

• 各画面でBackが何をするか（保存、破棄、確認）
• モーダルが閉じられるかどうか（閉じる意味は何か）
• 二重に到達すべきでない画面（重複プッシュを避ける）
• 未ログイン時のディープリンクの振る舞い

例：サインアップフローで、iOSは「利用規約」をシートで表示し、Androidはスタックにプッシュすることがある。それで構わないのは、どちらも同じ結果（同意／不同意）を返し、サインアップを同じステップから再開する場合だけです。

状態：挙動を一貫させる

画面が似ているのに「違う」と感じる場合、原因は大抵状態です。実装の詳細を比べる前に、画面が取りうる状態と各状態でユーザーが何をできるかを合意してください。

まず平易な言葉で状態計画を書き、繰り返し使えるようにします：

• Loading（読み込み）: スピナーを表示し主要アクションを無効化する
• Empty（空）: 何が足りないか説明し次に取るべきアクションを示す
• Error（エラー）: 明確なメッセージとリトライオプションを表示する
• Success（成功）: データを表示しアクションを有効にする
• Updating（更新中）: リフレッシュ中も古いデータを見せる

次に状態がどこに保持されるか決めます。画面レベルの状態はタブ選択やフォーカスなどのローカルUIに適していますが、サインイン状態や機能フラグ、キャッシュ済みプロフィールのようなアプリ全体で参照されるものはアプリレベルにする方が良いです。例えばAndroidで「ログアウト」がアプリレベル、iOSで画面レベルに扱われると古いデータが表示されるなどの齟齬が生まれます。

副作用（リフレッシュ、リトライ、送信、削除、楽観更新）は明示的に定義してください。成功時と失敗時に何が起きるか、処理中にユーザーが何を見るかを決めます。

例："Orders"リスト。

プル・トゥ・リフレッシュで古いリストを残しておく（Updating）か、全画面のLoadingに切り替えるか。失敗した時に最後の良いリストを表示して小さなエラーを出すか、完全なError状態に切り替えるか。両チームで答えが違えば、すぐに体験がずれてしまいます。

最後にキャッシュとリセットルールを合意します。再利用して良いデータ（最後に取得したリスト）と必ず最新にすべきデータ（支払いステータスなど）を決め、いつ状態をリセットするか（画面離脱、アカウント切替、送信成功時など）も明確にします。

フォーム：ずれてはいけないフィールド挙動

フォームは小さな差がサポートチケットに繋がる場所です。見た目が「近い」サインアップ画面でも、挙動が違えばユーザーはすぐに気づきます。

まずどちらのUIフレームワークにも依存しない一つの正規のフォーム仕様を作ります。契約のように書いてください：フィールド名、型、デフォルト、各フィールドが見える条件。例：「Company nameはAccount typeがBusinessの時のみ表示。デフォルトのAccount typeはPersonal。Countryは端末ロケールでデフォルト。Promo codeは任意。」

次に両プラットフォームで同じように感じてもらいたいインタラクションを定義します。"標準動作"に任せるのは避けてください。標準がプラットフォームで違うためです。

• フィールドごとのキーボードタイプ
• オートフィルと保存された資格情報の扱い
• フォーカス順とNext/Returnラベル
• 送信ルール（有効になってから送信可能か、エラーを表示しながら送信を許すか）
• 読み込み時の振る舞い（何をロックし何を編集可能にするか）

エラーの表示方法（インライン、サマリー、または両方）と表示タイミング（フォーカスアウト時、送信時、最初の編集後など）を決めます。よく使えるルールは「送信を試みるまではエラーを表示せず、送信後は入力中にインラインエラーを更新する」です。

非同期バリデーションは事前に計画してください。例えば"usernameの空き確認"がネットワーク呼び出しを必要とするなら、遅い/失敗したリクエストをどう扱うかを定義します："Checking..."を表示するか、タイピングをデバウンスするか、古い応答を無視するか、"使用不可"と"ネットワークエラー"を区別するか。これを決めておかないと実装が簡単にずれます。

バリデーション：1つのルールセット、2つの実装

バリデーションは目に見えないうちにパリティが壊れる場所です。片方のアプリで入力を弾き、もう片方で受け付けるとサポートが増えます。解決策は賢いライブラリではなく、分かりやすい言葉での1つのルールセットに合意し、それを両方で実装することです。

各ルールを非開発者でもテストできる文章で書いてください。例：「パスワードは最低12文字で数字を含むこと」「電話番号は国番号を含むこと」「生年月日は実在する日付で18歳以上であること」など。これらの文が真の基準になります。

端末側とサーバー側で実行するものを分ける

クライアント側のチェックは素早いフィードバックと明らかな誤りに集中させ、サーバー側のチェックはデータとセキュリティを守るためにより厳格にします。クライアントが許容してサーバーが拒否するなら、同じメッセージを返し同じフィールドをハイライトしてユーザーを混乱させないでください。

エラーテキストとトーンは一か所で定め、両プラットフォームで再利用します。"Enter"と"Please enter"のような言い回し、センテンスケースを使うかどうか、どの程度具体的にするかなど細かい点も一致させると、わずかな文言の違いが生む「別物感」を避けられます。

ロケールとフォーマットのルールは推測に任せず文書化します。特に電話番号、日付（タイムゾーンの前提を含む）、通貨、氏名/住所の扱いは明確に決めておきます。

簡単なシナリオ：サインアップフォームがAndroidで"+44 7700 900123"を受け付けるがiOSがスペースを拒否する場合、ルールを"スペースは許可し、保存時には数字のみを保持する"とすれば、両方のアプリは同じ誘導をし同じきれいな値を保存できます。

ステップ・バイ・ステップ：ビルド中にパリティを保つ方法

コードから始めないでください。中立的な仕様書から始め、両チームが真の情報源として扱うようにします。

1) まず中立的な仕様を書く

フローごとに1ページ、具体的にまとめます：ユーザーストーリー、小さな状態表、フィールドルール。"Sign up"ならIdle、Editing、Submitting、Success、Errorといった状態を定義し、各状態でユーザーが見るものとアプリがすることを書きます。スペースを削る、エラー表示のタイミング、サーバーがメールを拒否したときの挙動などの詳細も入れます。

2) パリティチェックリストで作る

誰もUIを実装する前に、iOSとAndroidが必ず通す画面別のチェックリストを作ります：ルートと戻る挙動、主要イベントと結果、状態遷移と読み込み挙動、フィールド挙動、エラー処理など。

3) 同じシナリオを両方でテストする

毎回同じセットを実行します：ハッピーパス、エッジケース（低速ネット、サーバーエラー、無効入力、バックグラウンドからの復帰）を含めて。

4) 毎週差分をレビューする

短いパリティログをつけて差分が恒久化する前に捕まえます：何が変わったか、なぜ変わったか、それが要件なのかプラットフォームの慣習なのかバグなのか、どこ（仕様、iOS、Android、またはその全部）を更新すべきかを記録します。早めに見つければ修正は小さく済みます。

チームがよく犯すミス

iOSとAndroidのパリティを失う最も簡単な方法は「同じ見た目にする作業だ」と扱うことです。挙動を揃えることの方がピクセルを揃えるより重要です。

よくある罠は、あるプラットフォームのUIディテールをもう一方にコピーすることです。代わりに共有の意図（状態、遷移、空/エラー処理）を書きましょう。見た目が違っても、読み込み、失敗、復旧が同じであれば「同じ」プロダクトに見えます。

別の罠はプラットフォームの期待を無視することです。Androidユーザーはシステムの戻るボタンが信頼できることを期待します。iOSユーザーは多くのスタックでスワイプ戻りやシステムシート、ダイアログのネイティブ感を期待します。これらの期待と戦うとユーザーはアプリを責めます。

繰り返し出るミス：

• 挙動（状態、遷移、空/エラー処理）を定義せずUIをコピーする
• 画面を"同一"にするためにネイティブのナビゲーション習慣を壊す
• エラー処理がずれる（片方はモーダルで止めるが、もう片方は静かにリトライする）
• クライアントとサーバーのバリデーションが異なり矛盾したメッセージが出る
• デフォルト挙動（自動大文字化、キーボードタイプ、フォーカス順）が違いフォームが不一致に感じられる

短い例：iOSが入力中に"パスワードが弱すぎる"と即座に表示し、Androidが送信時まで待つと、ユーザーは一方が厳しいと感じます。ルールとタイミングを一度決めて両方実装してください。

出荷前の簡単チェックリスト

公開前にパリティだけに集中した一回のチェックを行ってください："見た目が同じか"ではなく"意味が同じか"を確認します。

• フローと入力が同じ意図を満たすか： 両プラットフォームに同じパラメータを持つルートが存在するか。
• 各画面が主要な状態を扱うか： 読み込み、空、エラー、同じリクエストを繰り返すリトライで同じ場所に戻るか。
• フォームがエッジで同じ挙動か： 必須/任意、スペースのトリミング、キーボードタイプ、オートコレクト、Next/Doneの挙動。
• 同じ入力に対するバリデーションが一致するか： 拒否される入力は両方で同じ理由とトーンで拒否されるか。
• 解析が使われているなら同じ瞬間に発火するか： UIアクションではなく、その瞬間を定義する。

ドリフトを早く見つけるには1つの重要なフロー（例えばサインアップ）を選び、意図的にミスを入れて10回試します：フィールドを空のままにする、無効コードを入れる、オフラインにする、端末回転、処理中にアプリをバックグラウンドにする。結果が違えば、要件が十分に共有されていません。

例：両スタックで作ったサインアップフロー

同じサインアップフローをKotlin（Android）とSwiftUI（iOS）で別々に作ることを考えます。要件は単純：EmailとPassword、次にVerification Code画面、そしてSuccess。

ナビゲーションは見た目が違ってもユーザーが達成すべきことを変えてはいけません。Androidでは画面をプッシュして戻って編集するかもしれません。iOSではNavigationStackを使いコードステップをデスティネーションとして表示するかもしれません。ルールは同じ：同じステップ、同じ終了ポイント（Back、Resend code、Change email）、同じエラー処理。

挙動を揃えるため、誰もUIコードを書き始める前に平易な言葉で共有状態を定義します：

• Idle: ユーザーはまだ送信していない
• Editing: ユーザーがフィールドを変更している
• Submitting: リクエスト中、入力は無効化
• NeedsVerification: アカウント作成済み、コード待ち
• Verified: コード受理、先へ進む
• Error: メッセージを表示し入力済みデータは保持

その後、コントロールが異なっても一致するようにバリデーションルールを固定します：

• Email: 必須、トリム、メール形式に一致
• Password: 必須、8-64文字、少なくとも1数字、少なくとも1文字
• Verification code: 必須、6桁ちょうど、数字のみ
• エラーのタイミング: 送信時かフォーカスアウトかのどちらかを選び一貫させる

プラットフォーム固有の調整はプレゼンテーションを変えてよいですが意味を変えてはいけません。例えばiOSはワンタイムコードの自動入力を利用し、AndroidはSMSコードキャプチャを提供するかもしれません。これを次のように文書化します：変わるもの（入力方法）、変わらないもの（6桁必須、同じエラーテキスト）、両方でテストする項目（リトライ、リセンド、戻るナビゲーション、オフラインエラー）。

次のステップ：アプリが成長しても要件を一致させ続ける

最初のリリース後、ドリフトは静かに始まります：Androidで小さな修正、iOSで早急な修正、そして気づいたら挙動がずれている。最も簡単な予防法は一貫性を毎週のワークフローの一部にすることであって、後から整えるプロジェクトにしないことです。

要件を再利用可能な機能仕様にする

新しい機能ごとに短いテンプレートを作り再利用してください。UIの細部ではなく挙動に焦点を当てることで両スタックが同じ方法で実装できます。

含める内容：ユーザー目標と成功基準、画面とナビゲーションイベント（戻る挙動を含む）、状態ルール（読み込み/空/エラー/リトライ/オフライン）、フォームルール（フィールド型、マスク、キーボードタイプ、ヘルパーテキスト）、バリデーションルール（いつ実行するか、メッセージ、ブロッキングか警告か）。

良い仕様はテストノートのように読めます。詳細が変わればまず仕様を更新してください。

ParityレビューをDefinition of Doneに加える

パリティを小さく繰り返し可能なステップにします。機能が完了とマークされたら、マージや出荷前に両側を並べて同じフローを実行し差分を記録します。短いチェックリストでサインオフを得ます。

もしネイティブアプリを生成するためにデータモデルやビジネスルールを一箇所で定義したければ、AppMaster (appmaster.io) はバックエンド、Web、ネイティブ出力を含む完全なアプリを作るために設計されています。それでも、挙動、状態、文言はプロダクトの決定なので、パリティチェックは欠かせません。

長期目標は単純です：要件が進化したら両方のアプリが同じ週に同じように進化し、驚きが起きないようにすることです。