1. 収益化が入った瞬間にアプリが別物になる理由
収益化前のアプリは、多くの場合こうだ。
・状態は画面単位
・判断はユーザー操作起点
・結果は即時反映
しかし収益化が入ると、次の状態が常駐する。
・外部SDKが持つ内部状態
・OSが管理する課金状態
・サーバーが持つ正解データ
これらはアプリの意思とは無関係に更新される。ここでアプリは、イベント駆動システムへ強制的に変質する。
2. 広告SDKがイベント順序を壊すプロセス
広告SDKの本質的な問題は、処理が重いことではない。アプリのイベント順序を勝手に挿入・遅延・割り込みすることだ。
実行時には次のようなことが起きる。
画面表示要求
→ レイアウト計算
→ 描画直前
→ 広告SDKコールバック割り込み
→ 状態変更
→ 再描画要求
この割り込みは、UI設計側からは制御できない。
Swift / Kotlinではフレーム落ちとして現れ、Flutter / React Nativeでは「なぜか一瞬遅れる」体感になる。
広告が入った瞬間、描画は決定論ではなくなる。
3. サブスクリプションが「即時判断」を不可能にする構造
サブスクリプションで最も厄介なのは、「今使っていいか」を即断できない点だ。
なぜなら判断材料が分散している。
・ローカル：最後に取得した状態
・OS：現在の課金情報
・サーバー：検証済みの正解
これらは更新タイミングが揃わない。結果としてアプリは、確定できない状態でUI判断を迫られる。
多くのアプリがここで「一旦使わせる」「後で止める」という暫定設計を選び、その暫定が永続化して破綻する。
4. 課金処理が状態不整合を拡散する経路
課金処理は一操作に見えるが、実体は以下の連鎖だ。
- ユーザー操作
- OS課金開始
- 完了通知
- サーバー検証
- 権限反映
このどこかでアプリが終了・バックグラウンド遷移すると、状態は簡単に分岐する。
特に問題なのは、「成功したが反映されていない状態」が長期間残るケースだ。
これは実装バグではなく、分散トランザクションを軽視した設計の結果だ。
5. 言語・実行基盤ごとに表面化する破綻点
・Swift（iOS）
StoreKitは状態機械。状態遷移をログで追えない設計は必ず破綻する。
・Kotlin（Android）
Billingはコールバック連鎖。直列化できていないと再入で壊れる。
・Flutter
Dart側の状態とネイティブ課金状態は別系統。同期前提設計は成立しない。
・React Native
JSとネイティブで真実が分かれる。どちらが正かを決めない限り事故は止まらない。
ここで初めて分かる。収益化はUI設計でもAPI設計でもなく、ランタイム設計の問題だ。
アプリ収益化は、金を取る仕組みではない。アプリプログラミングにおいて、外部状態・非同期イベント・分散トランザクションを内部に受け入れる決断だ。その覚悟なしに広告・サブスク・課金を入れたアプリは、必ずどこかで状態が壊れる。長く稼ぐアプリは、最初から壊れ方を設計している。
