hsb.horse
iOS 開発を始めたばかりで「サイトをブロックするアプリを作りたい」と思ったとき、まず DNS という発想にたどり着くことがある。プロセスを監視するより名前解決の段階で止めてしまう方が確実そうだし、シンプルに見える。
検索すると NEDNSProxyProvider というクラスが出てくる。名前もそのままで、用途も一致しているように見える。
でも、これを使ってはいけない。iOS 未経験だと特にここで時間を溶かしやすい。
何のために設計されているクラスか
NEDNSProxyProvider は Network Extension フレームワークの一部で、デバイス上に DNS プロキシを立てるためのクラスだ。技術的にはそういう動きをする。
問題はターゲット環境にある。Apple の TN3134（Network Extension Provider Deployment）を読むと、このクラスが想定しているのは MDM でコントロールされたスーパーバイズドデバイス——企業や学校が管理する端末——だとわかる。
App Store で個人ユーザーに配布するアプリ向けではない。iOS 開発の経験があれば「MDM 管理下の端末向け」という文脈でピンとくるが、最初はここが読み取りにくい。
開発者フォーラムの一貫したメッセージ
Apple Developer Forums でセルフコントロール系アプリの実装について聞くと、答えはほぼ一貫している。Family Controls + ManagedSettings へ誘導される。
DNS を自前でフィルタしたいというニーズを説明しても、「それは想定ユースケースではない」という趣旨のレスポンスが返ってくる。個人ユーザー向けの有害サイトブロックを Network Extension で実装しようとすること自体、Apple の設計思想に反している。
フォーラムを読んで初めて「iOS にはそれ専用の API がある」とわかる人も多い。
実際どうなるか
スーパーバイズドデバイス向けの機能なので、通常の App Store アプリとして審査が通るかどうか不明確になる。App Review のリジェクトリスクを抱えながら開発を進めることになる。
それ以上に、この道を選ぶと FamilyActivityPicker や ManagedSettings が使えない。ブロックのロジックを全部自分で書く羽目になり、Apple がプラットフォームレベルで維持してくれる仕組みの恩恵を一切受けられない。
切り替えの結論
個人ユーザー向けのセルフコントロール系 iOS アプリなら、Family Controls + ManagedSettings の組み合わせが正解だ。iOS 開発の経験がないと「正規の API がある」こと自体を知らないまま進んでしまう。
DNS の仕組みをいじりたいという気持ちはわかる。でも Apple のプラットフォームポリシーに乗っかった方が、App Review の摩擦も長期的なメンテナンスコストも小さくなる。NEDNSProxyProvider に時間を使う前に、Screen Time API のドキュメントを先に読む方がいい。