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 를 사용할 수 없다. 블록의 로직을 전부 스스로 쓰는 날개가 되어, 애플이 플랫폼 레벨로 유지해 주는 구조의 혜택을 일절 받을 수 없다.
전환 결론
개인 유저를 위한 셀프 컨트롤계 iOS 앱이라면 Family Controls + ManagedSettings의 조합이 정답이다. iOS 개발 경험이 없으면 “정규 API가 있다”는 것 자체를 모르는 채 진행된다.
DNS의 구조를 괴롭히고 싶다는 마음은 알 수 있다. 하지만 애플 플랫폼 정책을 타는 것이 앱 리뷰의 마찰도 장기적인 유지 보수 비용도 작아진다. NEDNSProxyProvider에 시간을 사용하기 전에 Screen Time API 문서를 먼저 읽는 것이 좋습니다.