アプリを手放す日の実務 — App Store の「Appを転送」で引き継がれるもの・作り直すもの

アプリの売却話が具体化したとき、最初に手が止まるのは価格交渉ではなく「引き渡し」の実務だと感じています。App Store Connect には「Appを転送」という正式な機能がありますが、何がそのまま移り、何が移らないのかを把握しないまま進めると、譲渡後に買い手の元でプッシュ通知が止まったり、ユーザー全員が突然ログアウトされたりします。

私自身、個人開発で複数のアプリを運営しています。いま手放す予定はないのですが、「もしその日が来たら、何を渡すことになるのか」を一度洗い出しておきたくなり、Apple の公式ヘルプと突き合わせながら整理しました。売る側だけでなく、買う側に回るときの確認リストとしてもそのまま使える内容です。

なお、いくらで売れるのか・どこで売るのかという話は、Rorkで作ったアプリを売却する — FlippaとAcquire.comで「EXIT」を収益にする方法で扱っています。本稿はその先、つまり契約がまとまった後に待っている作業の話です。

そもそも、そのアプリは転送できるのか

転送を始める前に、対象のアプリが条件を満たしているかを確かめます。App transfer criteria（Apple Developer）に列挙されている要件のうち、個人開発者に関係が深いものを表にまとめました。

見落としがちなのはアプリ内課金のプロダクト ID です。たとえば pro_upgrade のような汎用的な ID を複数アプリで使い回す癖があると、買い手のアカウントに同じ ID が存在した時点で転送条件を満たせなくなります。私はこの整理をして以来、プロダクト ID には必ずアプリ固有のプレフィックスを付けるようにしています。売る予定のないアプリでも、将来の選択肢を狭めない小さな保険になります。

引き継がれるもの — 評価とレビューは移る

転送で最も重要な事実は、評価とレビューがそのまま移ることです。App Store での公開は途切れず、既存ユーザーは何も操作しないまま更新を受け取り続けます。Bundle ID も維持されます（そもそもビルドを一度アップロードした後は変更できません）。

買い手の視点に立つと、これは「星とレビューを資産として買える」ことを意味します。ゼロから同じ評価を積み直すコストを考えると、レビューが健全なアプリはコード以上の値打ちを持ちます。逆に売り手としては、Webhook のように自分のサーバーへ通知が飛び続ける設定を消し忘れると、譲渡後も相手のイベントが自分に届き続けることになります。転送前の棚卸しに含めておきたい項目です。

作り直しになるもの — 転送前に消すもの、転送後に発行し直すもの

一方で、開発・配信の裏側にあるものの多くは移りません。「転送前に自分が消すもの」と「転送後に相手が作り直すもの」に分けて把握すると混乱しません。

TestFlight を空にする作業は地味に手間がかかります。外部テストを運用しているアプリなら、テスターへの事前告知も含めて数日単位の段取りになります。テスター運用の全体像はRork アプリを TestFlight でベータテストする：内部テスターから外部公開まで全工程 — 実装パターンに書いたので、逆算の材料にしていただければと思います。

ユーザーに影響が出る3箇所 — 静かに壊れるのはここ

転送そのものはユーザーに見えません。しかし転送後の最初のアップデートで、目に見える影響が出る箇所が3つあります。

1つ目はキーチェーンです。キーチェーン共有のグループ名にはチームの Team ID がプレフィックスとして含まれるため、買い手のチームでビルドし直した瞬間に、旧グループへ保存された認証トークンが読めなくなります。Apple のヘルプも「アップデート後、ユーザーは1回再ログインが必要になる」と明記しています。ログイン必須のアプリなら、アプリ内での事前告知を買い手と申し合わせておくべき箇所です。

2つ目は自動更新サブスクリプションのレシート検証です。転送を開始する前に App 用共有シークレットを生成して買い手に渡し、買い手はそれで検証サーバーを動かし始めます。そして転送完了後、買い手は共有シークレットを再生成して、旧所有者がレシート検証にアクセスできない状態を作ります。渡す→動かす→再生成で締める、という順序が大切です。

3つ目は Wallet のパスです。アプリやWebサービスから更新を受けるパスは、転送後に新しい識別子で発行し直す必要があります。既存のパスは失効するため、Apple はアプリ内でユーザーに告知して新しいパスの取得を促すことを推奨しています。

Sign in with Apple を使っている場合は、さらにユーザー移行の準備が要ります。データベース内のユーザーごとに transfer identifier を Apple の REST エンドポイント経由で生成し、買い手側で新しいチームのユーザー ID に引き当て直します。ここを飛ばすと「Apple でサインイン」しているユーザーが全員迷子になるので、売買契約の作業項目に明示しておきたいところです。

Rork で作ったアプリなら、Apple の外に「もう半分」がある

ここまでは Apple の管轄の話でした。しかし Rork で作って運用しているアプリの場合、引き渡すべき資産の半分は App Store Connect の外にあります。

とくに広告 ID は収益に直結する割に見落とされやすい箇所です。ID 差し替えのアップデートが審査を通るまでの間、広告収益がどちらに入るのかも含めて、契約時に取り決めておくと揉めません。

プライバシーポリシーの置き場所も同様です。自分のドメイン配下で運用している場合、譲渡後もそのページの生存が買い手のアプリの生命線になります。ポリシーページの作りと審査要件はRorkで作ったアプリのプライバシーポリシー：App Store審査をすんなり通す日本語テンプレートと書き方で書いたとおりですが、譲渡を見据えるなら「アプリと一緒に移せる場所に置く」ことも設計のうちだと考えるようになりました。

まとめ — 売る予定がなくても「引き渡せる状態」は資産になる

今日の時点で売却の予定がなくても、転送条件のセルフチェックには意味があります。プロダクト ID の付け方、キーチェーンへの依存箇所、ポリシーページの置き場所。どれも後から直すほど高くつく設計判断だからです。

次のアクションとしては、自分のアプリを1本選んで、この記事の最初の表の6条件を照らし合わせてみることをお勧めします。15分ほどの作業で、自分のアプリが「引き渡せる状態」からどれくらい離れているかが見えてきます。手放す日の段取りを考えることが、続ける日々の設計を引き締めてくれる。整理を終えたいま、そんな実感があります。