実務メモ / リリースガイド

App Store にリリースする手順

開業届を出している個人開発者が、App Store にアプリを公開するまでの手順。
Google Play と違ってテスター人数の関門はありません。代わりに効いてくるのは、アカウント種別(=公開される販売者名)審査で落ちる理由、そしてアプリ内課金を初回リリースに含めるかどうかです。

対象開業届を出している個人開発者(個人事業主)で、これから App Store にアプリを公開する人
前提iOS アプリをビルドできる状態にあること。例は Flutter で書いています
時点2026-08-15 時点の要件にもとづく
最終更新2026-08-15
対になるノートGoogle Play にリリースする手順
注意一般的な情報の整理であり、税務・法務の助言ではありません。Apple の要件と画面は頻繁に変わります。最終的な判断は App Store Connect の表示に従ってください

TL;DR

ひとことで

個人開発者は Individual(個人)で登録することになります。開業届を出していても、それは法人格ではないので Organization(組織)にはできません。年 99 USD、登録自体は最短で当日〜数日です。

代わりに、App Store の販売者名として本名が公開されます。屋号で出したいなら法人を作るしかありません。ここだけは後から変えるのが重いので、最初に決めます。

アプリ内課金を出すなら、初回リリースには含めないほうが安全です。購入導線がまだ画面に無い状態で課金アイテムを審査に出すと、レビュアーが購入画面に到達できず差し戻されます。

Decision

最初の分岐は「誰の名前で売るか」

Apple Developer Program の登録種別は 2 つで、App Store に表示される販売者名がここで決まります。Google Play で「12 人 × 14 日間テスト」を避けるために組織アカウントを選ぶ、というような性能差はありません。差は名前と手続きの重さだけです。

  Individual(個人) Organization(組織)
個人事業主が選べるか 選べる 選べない(法人格が要る。開業届は法人格ではない)
販売者名の表示 本名(登録した個人名) 法人名
D-U-N-S ナンバー 不要 必須。取得に日数がかかる
登録にかかる時間 最短で当日〜数日 D-U-N-S の取得と法人確認のぶん長い
費用 99 USD / 年 99 USD / 年
チームで開発できるか できない(1 人) できる(役割を分けて招待)
!

本名の公開が困るなら、コードを書く前に決める

個人で登録して公開したあとに「やはり屋号で出したい」となると、法人を作り、別のアカウントでアプリを登録し直し、既存の利用者を移すことになります。アプリの移管(App Transfer)自体はできますが、アプリ内課金を含むアプリには条件があり、移管中は配信が止まります。最初に決めるのがいちばん安いタイミングです。

Setup

公開までの段取り

実際の順番です。4 と 5 は審査より先に終わらせておくこと——ここが未完了だと、ビルドを上げても価格が設定できません。

Apple ID と 2 ファクタ認証30 分

開発用の Apple ID を用意し、2 ファクタ認証を有効にします。個人用と分けるかは好みですが、連絡先メールは長く使えるものにしてください。契約更新や審査の通知がここに届きます。

Apple Developer Program に登録99 USD / 年

Developer アプリか Web から申し込みます。本人確認が入るので、身分証と、Apple ID に登録した名前・住所が一致していることを確認しておきます。年次で自動更新されます。更新が切れるとアプリは App Store から消えるので、支払い方法の有効期限に注意します。

Bundle ID を決める15 分

逆ドメイン形式(例: jp.nzw.certly)。あとから変えられません。アプリ名は変えられますが Bundle ID は別アプリ扱いになります。ドメインを持っているならそれを使うのが素直です。

契約・税金・口座を埋める1〜2 時間

App Store Connect の「ビジネス」で、有料アプリ契約(Paid Apps Agreement)に同意し、税務情報と入金口座を登録します。無料アプリだけなら不要ですが、アプリ内課金を出すなら必須です。米国の源泉徴収に関する申告フォームもここで出します。日本居住者はマイナンバーの入力を求められます。

ここが「処理中」のあいだは価格やアプリ内課金を設定できません。審査待ちの時間と重ねられるので、先に片付けます。

アプリを登録して情報を埋める2〜3 時間

名前・サブタイトル・カテゴリ・キーワード・説明文・サポート URL・プライバシーポリシー URL。プライバシーポリシーの URL は必須なので、公開できる場所に先に置いておきます。年齢制限のアンケートと「App のプライバシー」(データ収集の申告)もここです。

ビルドを上げて、審査に出す

下の「ビルドとアップロード」へ。

Build

ビルドとアップロード

Flutter の場合はこれだけです。

flutter build ipa --release

できあがった .ipa を Transporter(Mac App Store で配布されている Apple 製アプリ)で上げるか、Xcode の Organizer から Distribute します。上げてから App Store Connect に出てくるまで、数分から十数分かかります。

毎回引っかかるところ

TestFlight

TestFlight は「配る」より「確かめる」ために使う

内部テスター(自分のチーム、最大 100 人)は審査なしで即配布できます。外部テスター(最大 10,000 人)にはベータ審査が入りますが、本審査より軽く、通れば以後のビルドはほぼ素通りです。

!

TestFlight のビルドは、そのまま App Store に出せてしまう

ここが地雷です。TestFlight へ上げたビルドは同じものを製品版として公開できるので、検証用の抜け道をビルドフラグだけで作ると、そのまま出荷されます

手元では、動作確認用の解放を「ビルドフラグ」と「レシートの種別」の 2 つが揃ったときだけ効くようにしています。レシートが sandboxReceipt なら TestFlight 実行中、production なら App Store 版です。どちらか片方が欠けたら閉じる向きに倒すのが要点で、レシートが読めなかったときも閉じます——ここを開ける向きにすると、判定が壊れた瞬間に全機能が無料になります。

TestFlight で動いていることを画面からも分かるようにしておくと、フラグを付けたまま配った事故に気づけます。手元では起動して最初に目に入る場所に帯を出し、レシート種別の実測値も設定画面に出しています。「解放されない」ときに、原因がフラグ側なのか判定側なのかを端末だけで切り分けられるようにするためです。

In-App Purchase

アプリ内課金は「2 回目のリリース」から

1

初回リリースに課金アイテムを含めない

差し戻しの定番

アプリ内課金は初回だけアプリ本体と一緒に審査されます。このとき購入導線が画面に出ていないと、レビュアーが購入画面に到達できず「購入項目を確認できない」で返ってきます。初回は課金なしで出し、次の更新で課金を載せるほうが確実です。

2

価格は「価格ポイント」からしか選べない

2026-08-13 実測

好きな数字を入れられるわけではありません。日本円の候補は ¥100 / ¥200 / ¥300 …100 円刻みで、¥680¥1,480登録そのものができません。値付けを詰めてから管理画面を開くと、そこで作り直しになります。先に候補を確認してください。

3

「購入を復元」を画面に置く

審査要件

非消費型(買い切り)を売るなら、復元導線が要ります。機種変更した人が復元できないと審査で落ちますし、実際に困ります。設定画面の上のほうとペイウォールの両方に置いておくのが無難です。

4

「押す → 返る」で終わらない経路がある

購入の結末は購入 API の戻り値だけでは完結しません。承認待ち(Ask to Buy やコンビニ払い)が後から通った購入前回の起動でやり残したトランザクションApp Store から直接買う経路が、あとから流れてきます。購読は起動直後に始めること——ペイウォールを開くまで繋がない作りだと取りこぼします。

届いた購入は必ず完了処理で閉じます。非消費型でここを呼ばないと保留のまま残り、起動のたびに再送されます。ただし承認待ちのあいだは閉じないこと(閉じると承認前に消える)。

5

入手時期は「日付」では取れない

「この日までに入れてくれた人は無料のまま」をやろうとすると詰まります。iOS が返すのは AppTransaction.originalAppVersion——その Apple ID がそのアプリを最初に入手したときのビルド番号——だけで、入手した日付は取れません。無料期間中に配ったビルド番号を覚えておき、ビルド番号で線を引きます。文字列のまま比べると '10' < '2' になるので、整数に直してから比べること。

サンドボックスでの購入テストは実機と Sandbox Apple ID で行います。ただし成功の道だけ試して出荷しないこと。実際に踏むのは、やめた・買えない・失敗・通信が遅い、のほうが多く、そこで出す画面は成功経路をいくら試しても検証されません。手元では結末と待ち時間を選べる仮のストアをデバッグビルドに積んでいます。

Review

審査で落ちやすいところ

審査の所要時間は数時間から数日で、内容によって振れます。返ってくる理由はだいたい決まっています。

A

他社の商標をアプリ名に冠している

製品名を冠した「◯◯ 対策アプリ」は、その会社の公式に見えます。中立な名前+サブタイトルで説明するのが安全です。非公式である旨は、ストアの説明文とアプリ内の両方に書きます。「Anthropic および Claude は Anthropic PBC の商標です」のような帰属表示も添えます。

B

機能が薄い(Guideline 4.2)

Web サイトを包んだだけ、設定だけ、というアプリは落ちます。個人開発でよくあるのは「最初の 1 画面だけ作って出す」ケースです。

C

レビュアーが中身に入れない(Guideline 2.1)

ログインが要るならテスト用アカウントを備考欄に書きます。課金で開く機能があるなら、何を買えばどこが開くのかを備考に書いておくと戻ってきません。

D

スクリーンショットが実物と違う

実装していない画面や、加工した画面を並べると落ちます。実機の画で撮って、見出しの帯を外側に足すだけにしておくと、この理由では返ってきません。

E

評価の求め方(Guideline 1.1.7)

「高評価をくれたら何かあげる」はガイドライン違反です。評価を求めること自体は問題ありませんが、訊くタイミングは成果が出た直後に限るのが実務的にも正解です。落ちた直後に訊けば低い評価が付きます。

Release

審査に通ったあと、どう出すか

Assets

公開までに揃えるもの

Checklist

提出前チェックリスト

Sources

一次情報

要件も画面も変わります。ここに書いたことと管理画面が食い違ったら、管理画面が正しいと考えてください。