SwiftUIとJetpack Composeで考える、使いやすい業務アプリの設計
- 未分類
- 2026.10.13
業務アプリでは、入力しやすいことに加え、「処理が進んでいるのか」「失敗したらどうすればよいのか」が伝わることも大切です。今回は、iOSのSwiftUIとAndroidのJetpack Composeに共通する考え方をもとに、使いやすい画面を設計するポイントを紹介します。
1. 画面の見た目より先に「状態」を整理する
例えば、作業報告を送信する画面を考えてみます。入力前、入力中、送信中、送信完了、送信失敗では、表示する情報や押せるボタンが異なります。画面デザインだけを決めると、通信が遅い場合やエラー時の振る舞いが後回しになりがちです。
設計時には、次のような状態と操作をセットで整理します。
- 入力中：必須項目と入力エラーを分かる形で示す。
- 送信中：進捗を表示し、重複送信につながる操作を制御する。
- 送信完了：受付結果を表示し、次の作業へ進める。
- 送信失敗：入力内容を残し、修正や再試行の方法を示す。
2. データの持ち主を決める
SwiftUIでは、モデルデータを画面につなぎ、データの変化に応じて表示を更新します。Jetpack Composeでも、状態と表示を結び付けて画面を構成します。どちらも、同じ情報を複数の場所で別々に管理すると、不整合の原因になります。
一時的なメニューの開閉と、送信対象の作業報告では、必要な寿命や共有範囲が違います。「このデータは誰が更新するのか」「どの画面で共有するのか」「画面を離れても残すのか」を決めてから、管理する場所を選びます。
3. 画面表示と業務ルールを分ける
入力値の確認、通信、保存処理をすべて画面に詰め込むと、変更の影響を追いにくくなります。画面は表示と操作の受付を担当し、業務上の判断やデータ取得は別の役割に分けると、確認すべき範囲を整理できます。
MVVMやClean Architectureは、この役割分担を考えるための選択肢です。最初から層を増やすことを目的にせず、アプリの規模、変更頻度、チーム体制に応じて採用範囲を決めることが大切です。
4. 通信失敗と再操作まで設計する
モバイル端末では、移動中に接続が切れることもあります。「送信に失敗した」と表示されても、サーバー側では受付が完了している場合があります。そのまま再送すると、二重登録につながる可能性があります。
送信ボタンの制御だけでなく、受付結果の確認や、同じ依頼を重複して処理しない仕組みも、サーバー側と合わせて検討します。オフライン保存が必要かどうかも、実際の利用環境から判断します。
開発前に確認したいこと
- 利用者はどこで、どんな端末を使うか。
- 操作を中断した場合、どこから再開するか。
- 通信失敗時に入力内容を残せるか。
- 同じ操作を繰り返した場合に何が起こるか。
- 完了したことを利用者が確認できるか。
使いやすい業務アプリは、画面の見た目と処理の仕組みを一緒に設計することで形になります。株式会社Appsでは、iOS・Androidアプリの設計、開発、技術支援に対応しています。業務アプリの新規開発や既存アプリの改善については、お問い合わせページからご相談ください。
参考資料
この記事を書いた人
