TL;DR. 予約注文(Pre-Order)を使うと、まだリリースされていないアプリのプロダクトページをApp Store Connect上で最大180日前から公開し、ユーザーからの予約を集め、リリース日が来た瞬間にすべての予約を単一の自動ダウンロードとして一斉に届けることができます。これはその国・地域でまだ一度もリリースされたことのないアプリにしか使えません——すでに公開済みのアプリのアップデートを予約注文にすることはできません。ローンチを計画しているなら、予約注文は初日のインストールを1つの瞬間に集中させる仕組みであり、これはフェーズドリリースが最初の週に分散させるのとは正反対の性質を持ちます。
多くのインディー開発者は、新しいアプリを毎回同じ手順で出荷します。提出し、承認され、リリースし、そしてローンチ当日はApp Store Connectをリロードし続けながらProduct Huntからの流入がコンバージョンにつながることを祈る、というものです。予約注文はその日が来る前から需要を積み上げられる仕組みですが、ゲームスタジオ以外でこれを使っている人はほとんどいません。
App Storeの予約注文はどれくらい前から開始できますか？
その国・地域でまだ一度もリリースされたことのない新規アプリであれば、予定リリース日を最大180日先まで設定できます。すでに他の少なくとも1つの地域でアプリが公開済みで、新しい地域向けに予約注文を開始する場合は、この期間は365日まで延びます。
これはApp Store Connectの該当アプリの「価格および提供状況」セクションで、そのロケーションで一度も「販売準備完了」になったことがない状態のうちに設定します。ある国・地域で一度でもダウンロード可能としてリリースされたアプリは、その地域では永久に予約注文の対象外になります——すでにユーザーがダウンロードできるアプリのメジャーアップデートや再ローンチに予約注文を使うことはできません。
予約注文によるダウンロードは一斉に発生しますか、それとも段階的ですか？
一斉に発生します。設定したリリース日に、予約注文したすべての顧客に通知が届き、(自動ダウンロードが有効になっていれば)アプリが自動的に端末にダウンロードされます——段階的な配信は一切ありません。これはフェーズドリリースとは正反対です。フェーズドリリースは既存ユーザーへのアップデートのロールアウトを、7日間かけて割合ベースで分散させる仕組みです。予約注文は最初のリリースを集中させるための仕組みであり、フェーズドリリースはその後のリリースのリスクを下げるための仕組みです。この2つを混同しないでください。
その「集中」こそが実際の狙いです。同じ24時間のうちに一斉にダウンロードへ転換する予約注文の積み重ねは、App Storeのディスカバリー機能——New Apps We Loveのような枠——が注目するように設計されている、あの単日インストール急増の形を生み出します。Appleは正確な重み付けを公開していませんが、ゆっくりと薄く広がる最初の週のローンチと、同じ合計インストール数が1日に集中するローンチとでは、シグナルとして明らかに異なります。
計画が変わった場合、リリース日はどうなりますか？
その国・地域でリリース日が過ぎる前であれば、いつでも変更でき、回数の制限もありません。新しい日付は、初回リリースであれば予約注文の初回公開から180日以内、新しい地域への展開であれば365日以内という、元の対象期間の中に収まっている必要があります。ある地域でリリース日が過ぎると、そこでは日付をロックされ、そのバージョンがまだ承認されていなくても、もう動かすことはできません。
この期間中の価格には独自のルールがあります。すでに予約注文した人がいる状態で価格を下げた場合、その人たちはリリース時に、元々合意した価格ではなく、下がった後の価格で課金されます。価格を上げても、既存の予約注文に遡って高い金額が請求されることはありません——値上げが適用されるのは、変更後に行われた新しい予約注文だけです。リリース日そのものが来るまで誰にも課金されません。予約注文は取引ではなく、あくまで約束です。
予約注文期間中のビルドの提出とアップデート
アプリは予約注文のリスティングが公開される前に、必ずApp Reviewを通過している必要があります——承認されていないビルドで予約注文ページを公開することはできません。一度公開されれば、予約注文期間中も、すでにリリース済みのアプリと同じように新しいバージョンを提出でき、自動リリース、手動リリース、スケジュールリリースのいずれかを選べます。予約注文の日付が来た時点で承認・リリースされているバージョンが、すべての顧客に届くバージョンになります——ローンチ直前までビルドを調整しているなら、リリース日が来る前に最終提出が確実に「リリース」の状態になっている(「デベロッパによるリリース待ち」のまま放置されていない)ことを確認してください。そうしないと、意図していたより古いビルドがユーザーに届いてしまいます。
計画する前に知っておくべき対象外のケースがもう2つあります。単体のApp内課金は予約注文の対象にできません。また、アプリバンドルは予約注文の対象外です——バンドルは、その中のすべてのアプリが少なくとも1つの地域ですでに「販売準備完了」になっていることが条件です。
予約注文を設定する前に
- 予約注文を開始する国・地域で、そのアプリがこれまで一度もダウンロード可能としてリリースされていないことを確認しましょう——これは純粋に新規の提供にしか使えず、再ローンチには使えません。
- 実際に守れるリリース日を選びましょう。対象期間の範囲内であれば後から先延ばしにできますが、ある地域で日付が過ぎるとロックされます。
- ローンチ直前の最終ビルド提出を、絶対厳守の締め切りとして扱いましょう。リリースオプションを自動リリースに設定するか、余裕を持って手動でリリースし、承認済みだが未リリースのバージョンが初日に全員に古いまま出荷されることを防ぎましょう。
- サブタイトル、キーワードフィールド、スクリーンショットが未完成なら、提出前に仕上げておきましょう。これらはすべての予約注文顧客が一斉に受け取る同じビルドと一緒に公開され、ゆっくりとしたロールアウトでやり直すチャンスはありません。