スマートフォンアプリを1本、企画からApp Storeの審査提出まで作りきって分かったのは、 「アプリの本体機能」よりもその周りの仕組みに落とし穴が多いということでした。 このページは、これから初めてアプリを作る人に向けて、「最初から入れておくと後で泣かずに済むもの」を 作る順番どおりに22個、できるだけやさしい言葉でまとめたものです。
コードを書く前の準備。ここをさぼると、後半すべてが遅くなります
これは何? 「どんな画面があるか」「何ができるか」「何はやらないか」を、作る前に文章にしておくことです。数ページのメモで十分です。
なぜ入れる? 作っている途中で必ず「あれもこれも」と欲が出ます。書いた仕様が「迷ったときに戻る場所」になり、完成まで走りきれます。特に「やらないことリスト」が効きます。
要件・画面・データ・デザインの文書5本を先に作り、実装と食い違ったら「文書を直してからコードを直す」ルールで最後までブレませんでした。
これは何? コードのセーブポイントを作る仕組みです。「コミット」という単位で変更を記録し、GitHubに置けばPCが壊れてもコードが残ります。
なぜ入れる? アプリ開発では「さっきまで動いてたのに壊れた」が日常です。こまめにコミットしていれば、いつでも動いていた状態に戻れます。「1機能できたら1コミット」から始めれば十分です。
「1つの区切りが終わるごとにコミット」を徹底し、18日間で71コミット。何かを壊しても、どこで壊したかすぐ特定できました。
これは何? 個人開発なら、iPhone/Android両対応のクロスプラットフォーム（React Native + Expo、Flutterなど）が現実的です。そして言語は型のあるモード（TypeScriptのstrictなど）で始めます。「型」は変数に入るデータの種類をコンピュータに約束させる仕組みです。
なぜ入れる? 型があると、書きまちがいの多くが実行前にエラーとして見つかります。アプリはユーザーの手元でクラッシュすると取り返しがつきにくいので、この保険がとても効きます。「あとで型を厳しくしよう」は現実にはやらないので、初日からです。
React Native (Expo) + TypeScript strictを初日に設定。「any（型チェックの無効化）は使わない」ルールで、13,000行を超えてもコンパイラが常に守ってくれました。
これは何? 「メインの色は1色だけ」「文字サイズは決めた段階のみ」「余白は8の倍数」のような、少数のルールを決めて定数ファイルに書いておくことです。
なぜ入れる? デザインが素人っぽく見える一番の原因は、画面ごとに色やサイズが微妙にバラバラなことです。ルールで選択肢を減らせば、デザイナーでなくても統一感が出ます。色をコードのあちこちに直書きしないのがコツです。
「アクセント色は青1色だけ」「フォントの太さは3段階だけ」等をルール化して定数に集約。11画面作ってもトーンが揃いました。
機能を積む前に入れる基礎工事。あとから入れ直すのが一番大変な層です
これは何? ユーザーのデータを端末内のデータベース（SQLiteなど）に保存します。大事なのはセットでマイグレーション（保存形式をあとから安全に変更する仕組み）を最初から用意することです。
なぜ入れる? アプリを更新しても、ユーザーの端末には古い形式のデータが残っています。「列を1つ追加したらアプリが起動しなくなった」は定番の事故です。「変更は追加だけ・削除しない」「バージョン番号で管理」の2つを守るだけで、この事故はほぼ防げます。
データ形式はv1→v9まで9世代（初期作成+8回の変更）を重ねましたが、「追加だけの変更」と「古いバージョンのデータが新形式へ正しく引き継がれるかを確かめるテスト」のセットで、データが消える事故はゼロでした。
これは何? 画面に表示する文字を、コードに直接書かず「辞書ファイル」（日本語用・英語用のJSONなど）にまとめておくことです。
なぜ入れる? あとから多言語対応しようとすると全画面の書き直しになります。最初から分けておけば、英語版はファイルを1枚訳すだけ。日本語だけのつもりでも、文言の修正がコードを触らずにできるので開発中から楽です。
初日から「文字の直書き禁止」にして、日英2言語・約560個の文言を辞書ファイルで管理。英語版の追加はほぼ翻訳作業だけでした。
これは何? 「この関数にこれを入れたらこれが返る」を自動で確認するコードです。全部に書く必要はなく、間違えると痛い計算（ポイント計算、日付の判定、データ変換）だけでも効果絶大です。
なぜ入れる? アプリは修正のたびに全機能を手で確認するのが現実的でなくなります。テストがあれば「昨日まで動いていたものを今日壊していないか」を数秒で確認でき、安心して変更できるようになります。
経験値計算・連続記録・日付処理を中心に366個のテストを用意。リリース直前の変更も怖くありませんでした。
これは何? 「日時はこの形式で統一する」「『今日』はどう判定する」を決め、現在時刻を関数の外から渡す書き方にしておくことです。
なぜ入れる? スマホアプリのバグの名所は深夜0時前後です。「日付が変わった瞬間の連続記録」「開きっぱなしで日をまたいだ画面」——現在時刻を外から渡す書き方なら、こういう場面をテストで再現して事前に潰せます。
全ロジックが「現在時刻」を引数で受け取る規約に。深夜0時をまたぐ連続記録の挙動を、任意の時刻を指定したテストで固定できました。
これは何? 広告・課金・分析など外部のSDK（他社の部品）を使うときは、画面のコードから直接呼ばず、servicesのような専用フォルダに窓口を作って必ずそこを通すことです。
なぜ入れる? 外部SDKは仕様変更やサービス終了が起きます。窓口が1か所なら、差し替えもそこだけ。さらに「設定が未完成でも安全に動く」ようにしておくと、開発中にアプリが起動しなくなる事故を防げます。
広告・課金・分析・通知・バックアップを全部services/に隔離。APIキー未設定のときは「何もしないモード」で動く設計にしました。
本体機能ができたら入れる「続けてもらう・困らせない」ための仕組み
これは何? 初回起動のときだけ表示する、2〜3枚のかんたんな説明画面です。最後は「最初の1つを作ってみる」など、すぐ行動につながるボタンで終えます。
なぜ入れる? ユーザーは説明書を読みません。最初の30秒で「何をすればいいか」が分からないアプリは、そのまま削除されます。長い説明より「1歩目への誘導」が大事です。
世界観・成長・通知許可・最初の一歩の4ステップにして、最後は「最初のクエストを作る」ボタンで作成画面に直行する導線にしました。
これは何? データが0件のときに、白紙ではなく「まだ何もありません。＋ボタンから作ってみましょう」のような案内を出すことです。
なぜ入れる? 新規ユーザーが最初に見るのは、ほぼ必ず「データ0件の画面」です。つまり空状態こそ第一印象。白紙の画面は「壊れてる?」と誤解され、最初の離脱ポイントになります。
一覧・検索結果・ゴミ箱など「0件になり得る画面」を洗い出して、全部に案内文を入れました。
これは何? 「今日のタスクがあります」「期限が近いです」のようなお知らせです。サーバー不要のローカル通知（アプリが端末内で予約する通知）だけで、かなりのことができます。
なぜ入れる? タスク・習慣・学習系など「思い出してもらうことに価値がある」アプリなら強くおすすめです。どんなに良いアプリでも、ユーザーは忘れます。通知は「思い出してもらう」ほぼ唯一の手段です。ただし通知の許可は断られることも多いので、許可がなくても困らない設計にしておくこと。乱発すると通知ごとオフにされるので回数は控えめに。
デイリー・期限・連続記録が途切れそうなときの3種類をローカル通知だけで実装。サーバー代0円で毎日のリマインドが動いています。
これは何? 設定画面に「ご意見・お問い合わせ」ボタンを置き、タップでメール作成画面が開くようにする——最小構成ならこれだけです。
なぜ入れる? 不満を伝える場所がないと、ユーザーはストアの星1レビューに直接書きます。アプリ内に窓口があれば、不具合報告や要望が先にあなたへ届き、改善のヒントにもなります。実装は数行なのに効果が大きい、コスパ最強の機能です。
設定画面にフィードバックメールの導線を設置。宛先は定数ファイルにまとめ、件名にアプリ名、本文の末尾にバージョン・OS・言語が自動で入るようにしました。
これは何? 入れ方は2つあります。①OS標準のレビュー依頼画面（iOSならStoreKitのレビューAPI）を「ユーザーが良い体験をした直後」にだけ表示する ②設定画面に「アプリをレビューする」ボタンを置き、ストアのレビュー入力画面へ直接ジャンプさせる。
なぜ入れる? ストアの評価はダウンロード数に直結しますが、満足しているユーザーほど自分からはレビューを書きません。①は「目標を達成した直後」など気分がいい瞬間に一度だけお願いするのがコツで、OSの仕様で表示回数に上限があり乱発できません（表示される保証もありません）。だからこそ、自分から書きたくなったユーザーを逃さない②の常設ボタンをセットで持つのが定石です。
①はレベルアップ演出が終わった直後だけに限定し、さらに「累計10件完了・60日間隔・上限3回」の自前ルールで抑制。②は設定画面の「アプリをレビューする」からApp Storeのレビュー画面へ直接遷移する導線を用意しました（こちらは回数制限なし）。
これは何? ユーザーのデータをファイル（JSONなど）に書き出して、別の端末や再インストール後に読み込めるようにする機能です。
なぜ入れる? データが端末の中だけにあるアプリでは、機種変更=全データ消失になりかねません。長く使ってくれた人ほどダメージが大きく、信頼を一発で失います。読み込むときは「壊れたファイル・改ざんされたファイルかもしれない」と疑って中身をチェックするのが重要です。
書き出し/読み込みに対応し、読み込み時は形式・日付・数値の範囲まで検証してから復元。課金状態は改ざん防止のため意図的にバックアップへ含めていません。
これは何? 画面を読み上げる機能（iOSのVoiceOverなど）で操作できるようにすることです。ボタンに説明を付ける、開閉状態を伝える、といった小さな積み重ねです。
なぜ入れる? 読み上げで操作できない画面は、その人にとって「アプリが壊れている」のと同じです。多くの対応は数行で済みますが、知らないと「画面に重ねて表示される小窓（モーダル）の中が、読み上げでは一切操作できない」ような大きな事故も起きます。公開前に一度、読み上げだけで主要な操作を試してみてください。
読み上げだと編集シート（画面下からせり上がる入力画面）内の操作に到達できなくなる罠を実際に踏み、モーダル実装のルールとして対策を明文化しました。
ストアに出す直前〜出した後のこと。コード以外の作業が意外と多い場所です
これは何? 「どの機能が何回使われたか」を匿名で記録する仕組みです（PostHog、Firebase Analyticsなど無料枠のあるサービスで十分）。
なぜ入れる? 公開後の改善は「どこでユーザーが離脱しているか」「どの機能が使われていないか」が見えないと勘だよりになります。ただし何でも記録するのではなく、知りたいことを決めてから記録する項目を設計すること。名前やメールアドレスなどの個人情報は入れてはいけません。
「継続に効いている機能はどれか」を知るために11種類のイベントだけを定義。識別子は端末が生成する匿名IDのみで、個人情報は一切送っていません。
これは何? サブスクリプションや買い切りを売る機能です。大事な設計が2つ: ①価格をコードに直書きせずストアから動的に取得する（値上げ・値下げ・国別価格がアプリ更新なしで反映される） ②「月額プランを買ったか」ではなく「プレミアム権を持っているか」で判定する（あとからプランを増やしても画面のコードが変わらない）。
なぜ入れる? 料金は公開後にほぼ必ず見直します。直書きしていると、価格を変えるたびにアプリの審査からやり直しです。また課金は「購入が本物かをストアに確認する処理（レシート検証）」など罠が多いので、RevenueCatのような専門サービスに乗るのが個人開発では現実的です。
月額・年額・買い切りの3プランを「プレミアム」という1つの権利にまとめ、価格表示はすべてストアから取得。App Store Connect（Appleのアプリ管理サイト）で価格を変えるだけで、アプリはそのまま追従します。
これは何? 無料アプリの収益源です。バナー（画面端の帯）と、ユーザーが見る代わりに特典をもらうリワード広告が定番です。
なぜ入れる? 収益化の入り口として最も手軽ですが、注意が2つ。①開発中は必ずテスト用の広告IDを使うこと（本物の広告を自分でタップするとアカウント停止のリスク） ②どの画面に「置かないか」を先に決めること。体験の中心に広告を置くと、アプリごと削除されます。
開発ビルドでは自動でテストIDに切り替わる仕組みにして事故を防止。世界観の中心であるホーム画面にはバナーを置かない、と最初に決めました。
これは何? 「このアプリがどんなデータを集めるか」を書いた文書（Webページとして公開）と、ストア提出時のプライバシー申告フォームへの回答です。広告や分析のSDKを入れると、自分でデータを集めていなくても申告が必要になります。
なぜ入れる? これがないとそもそも審査に出せません。各SDKの公式が「こう申告してください」というガイドを出しているので、それに沿って正直に書くのが一番安全です。実装と申告が食い違うのが最悪パターンです。
ポリシーはGitHub Pagesで無料公開。AdMob/PostHog/RevenueCatの公式ガイダンスに沿って収集データ7種を申告しました。
これは何? アプリアイコン、規定サイズのスクリーンショット、アプリ名・説明文・検索キーワードなど、ストアの商品ページを構成する素材一式です。
なぜ入れる? ユーザーはコードではなく商品ページを見てダウンロードを決めます。スクリーンショットには規定サイズがあり、審査直前に慌てがちなので、撮影→リサイズの手順を先に作っておくとスムーズです。
実機で撮影→規定サイズ（1242×2688）へ自動変換する小さなスクリプトを用意。アイコンもアプリ内のドット絵素材から自動生成しました。
これは何? 公開はゴールではなくスタートです。行動分析（17）とフィードバック（13）とレビュー（14）から入ってくる情報を見て、小さく直して、また出す——この繰り返しの体制です。
なぜ入れる? 最初のバージョンの想定は必ずどこか外れています。すぐ直してすぐ出せるように、ビルドと提出の手順は自動化しておくこと。バージョン管理（2）・テスト（7）・マイグレーション（5）は全部、この「直し続けられる状態」のための投資だったと公開後に気づきます。
ビルド番号の自動更新と提出の非対話化までを整備済み。修正版を出す作業は「ビルド」と「提出」のコマンド2つだけになっています。
22個ぜんぶを最初のアプリで完璧にやる必要はありません。ただ、フェーズ1〜2の「土台」だけは後から入れ直すのが本当に大変なので、最初の1週間で仕込んでおくことを強くおすすめします。フェーズ3〜4は、動くものができてから1つずつ足していけば大丈夫です。
それぞれの項目の技術的な深掘りは ② 汎用技術ガイド に、これらを実際に全部入れて審査提出まで到達した記録は ① 開発ポートフォリオ にまとめてあります。