とじまる開発手順書 ・ 第2回
#2 Family Controls の申請と、Macを買わずに済ませた判断
前回、競合調査から「穴の少なさで勝つ」と決めました。次は技術的に成立するかの確認です。
この回の主題は、Macを買うかどうかでした。
目的
iOSでアプリをロックするには、**Screen Time API（Family Controls）**を使います。これは誰でも使える一般のAPIではなく、Appleが個別に審査して配る特権です。
確かめたかったのは2つ。
- 申請は何件必要で、どう出すのか
- 開発にMacが必要になるのか（予算5万円に対して、Macは最大3万円＝60%を占める）
手順
1. 申請が「4件」必要だと確定させる
Family Controls の entitlement は、アプリ本体だけでは足りません。機能を分担する Extension それぞれにも要ります。
| 申請対象 | 役割 |
|---|---|
| アプリ本体 | 設定・記録の画面 |
| DeviceActivityMonitor | 時間の監視 |
| ShieldConfiguration | ロック中に出る画面の見た目 |
| ShieldAction | ロック画面のボタンが押されたときの挙動 |
合計4件。 ここを1件でも漏らすと、あとでビルドが通らなくなります。
大事なのは、bundle ID を推測で書かないことです。expo config で実際に生成される値を出力させ、実物の4件を確定させてから申請しました。
2. 「Macが要る」という情報の出どころを確かめる
使うライブラリのREADMEに、こう書かれていました。
entitlement が全 bundle ID に承認されるまでは、ローカルのXcodeビルドしかない
Xcodeが要る = Macが要る、と読めます。ここで一度、企画が止まりかけました。
ですが、よく読むと**「承認されるまでは」**と書いてあります。承認後の話ではありません。
そこでApple Developer Forumsで、EAS Build（クラウドビルド）が失敗している事例を調べました。原因はどれも次の2つでした。
- Extension の App ID の承認漏れ
- 古いプロビジョニングプロファイルのキャッシュ
1については、こちらは4件すべてを申請する手順にしてあるので起きません。2は運用で回避できます。
結論はこうなりました。
承認が下りるまで実機で何も試せないという「待ち」が発生するだけで、Macは要らない。
3. Macを買わないと決める
判断はこうです。
| 変更前 | 変更後 | |
|---|---|---|
| 予算リスク | Macに最大3万円（予算の60%） | 0円 |
| Phase 0 の待ち時間 | — | 承認が下りるまで実機検証できない。ここは飲む |
MacinCloud（月額レンタル）、中古のMac mini、借りる、はすべて却下しました。不要だからです。
ただし条件付きです。entitlement が却下された場合は、話が変わります。 そのときに再検討する、として先送りしました。
4. 前提が2つ抜けていたことに気づく
ここで指摘が入りました。「ぽんまるのときは、こんな手順を踏まなかったのでは？」
調べたところ、踏んでいました。段階が違うだけでした。
| ぽんまる | とじまる | |
|---|---|---|
| entitlement の申請 | 不要（写真・カメラは申請なしで使える） | 必要。4件 |
| App Store Connect にアプリを作る | 必要。提出直前にやった | 必要。申請フォームがApple IDを求めるので最初にやる |
| 公開Webページ（プライバシー・サポート） | 必要 | 必要 |
| 有料App契約・銀行・税務情報 | 不要（無料アプリ） | 必要（課金する） |
新しく発生するのは entitlement 申請と有料App契約の2つだけで、残りはぽんまるでもやっていた作業が前倒しになっただけでした。
「前と違う」と感じたときは、本当に新しいのか、順番が変わっただけなのかを分けると、無駄な調査が減ります。
つまずいた点
「承認された」の意味が2つあった
これが後で1回分の審査を無駄にします。
Developer Portal で App ID に Family Controls のチェックを入れられるようになった時点で、「申請は通った」と判断しました。これは開発用については正しかったのですが、配布用の承認とは別物でした。
- 開発用（Development）: 自分の実機で動かすための許可
- 配布用（Distribution）: App Store に出すための許可
このアプリは後に、「Screen Time API を使っているのに entitlement なしで提出された」という理由で審査に落ちます（詳しくは第4回）。原因の有力候補が、この配布用の承認漏れでした。
ポータルでチェックを入れられることと、配布の承認が下りていることは、別。
先に記録しておいた地雷
実装に入る前に、こういう記録を残しておきました。
EASは古いプロビジョニングプロファイルをキャッシュして使い回す。承認が下りた後にビルドして
Synced capabilities: No updatesと出たら、Expo側とApple側の両方の証明書・プロファイルを削除して作り直す。
これを知らずにハマると半日溶けます。調査中に見つけた地雷は、踏む前に書いておく。 あとで自分を助けます。
成果物
- 申請すべき4件を、推測ではなく実物のbundle IDで確定
- Macを買わないと決定（予算リスク3万円 → 0円）
- ぽんまるとの差分が「entitlement 申請」と「有料App契約」の2つだけだと確定
- 「開発用の承認 ≠ 配布用の承認」という、後で高くつく区別を（結果的に）記録に残せた
次回は、実装の前に競合アプリを実機で試したら、設計の前提が崩れた話です。
この手順書の「実物」版
ここまでの記録は物語として書いています。実際に使ったファイルそのものは、有料記事にまとめました。
- 審査に通った設定ファイルの全文（
package.json/app.json/eas.json/ ストア文言） - 審査メモの全文と、却下への返信文の型
- リジェクト4回の全記録（何が届いて、本当の原因は何で、どう直したか）
- つまずき67件の逆引き表（症状 → 原因 → 対処）
- 提出前チェックリスト
稼ぎ方は書いていません。 2026年9月8日時点のダウンロードは、道の駅ぽんまるが公開26日で36件、とじまるが6日で7件です。売れる方法は、まだ分かっていません。
→ Windows1台・コード0行でiOSアプリを2本App Storeに出した全記録｜審査4回リジェクトの原文と、通った設定ファイル（3,980円・Brain）
同じ記事を note でも同じ価格で出しています。安い経路はありません。