Apple이 모바일 Safari를 의도적으로 제한하고 있다는 증거들

웹 앱의 미래를 가로막는 보이지 않는 벽

웹 기술은 지난 10년간 놀라운 속도로 발전해왔습니다. Service Worker, Web Push, IndexedDB, WebGL 등 브라우저에서 네이티브 앱 수준의 경험을 제공할 수 있는 API들이 속속 등장했고, 이를 기반으로 한 PWA(Progressive Web App)는 "한 번 만들면 모든 플랫폼에서 동작하는 앱"이라는 오랜 꿈에 가장 가까이 다가간 기술이었습니다. 그런데 이 꿈을 현실에서 가로막고 있는 존재가 있습니다. 바로 Apple의 모바일 Safari입니다.

pwa.gripe 사이트는 Apple이 모바일 Safari에서 의도적으로 웹 표준 기능을 제한하거나 지연 구현하고 있는 사례들을 체계적으로 정리한 프로젝트입니다. 단순한 불만 제기가 아니라, 구체적인 API별 지원 현황과 타 브라우저 대비 격차를 데이터로 보여주고 있어 웹 개발자라면 한 번쯤 짚고 넘어가야 할 내용입니다.

무엇이 문제인가: 구체적인 제한 사항들

PWA가 네이티브 앱처럼 동작하려면 몇 가지 핵심 기능이 필요합니다. 오프라인 동작을 위한 Service Worker, 사용자 재방문을 유도하는 Web Push Notification, 앱 설치 경험을 제공하는 Web App Manifest, 그리고 다양한 하드웨어 접근 API들이 그것입니다.

Chrome(Chromium 기반 브라우저)과 Firefox는 이러한 기능들을 비교적 빠르게 구현해왔습니다. 반면 Safari는 핵심 기능의 구현을 수년씩 지연시키거나, 구현하더라도 다른 브라우저와 미묘하게 다르게 동작하도록 만들어 개발자들에게 추가적인 부담을 안겨왔습니다.

대표적인 예로 Web Push를 들 수 있습니다. Chrome은 2015년에 Web Push를 지원하기 시작했지만, Safari는 2023년 iOS 16.4에서야 비로소 이를 지원했습니다. 무려 8년의 격차입니다. 그마저도 홈 화면에 추가된 PWA에서만 동작하는 제한이 있었습니다. 일반 Safari 브라우저 탭에서는 여전히 Push 알림을 받을 수 없다는 뜻입니다. 이는 사용자가 먼저 "홈 화면에 추가"라는 비직관적인 단계를 거쳐야 한다는 것을 의미하며, 대부분의 일반 사용자는 이 기능의 존재조차 모릅니다.

Fullscreen API도 마찬가지입니다. 웹 게임이나 미디어 앱에서 전체 화면 모드는 기본적인 사용자 경험인데, iOS Safari에서는 이 API의 지원이 불완전합니다. Background Sync, Screen Wake Lock, Web Bluetooth, Web NFC 등 하드웨어 접근과 관련된 API들도 대부분 미지원이거나 부분 지원 상태입니다.

왜 Apple은 이렇게 하는가

여기서 핵심적인 질문이 나옵니다. Apple은 기술력이 부족해서 이러한 API들을 구현하지 못하는 것일까요? WebKit 엔진을 직접 개발하고 유지보수하는 Apple의 역량을 생각하면 그럴 가능성은 극히 낮습니다.

많은 개발자와 업계 분석가들은 이것이 비즈니스 전략의 일환이라고 봅니다. PWA가 네이티브 앱과 동등한 수준의 기능을 제공하게 되면, 개발자들이 App Store를 우회할 수 있습니다. App Store는 Apple의 핵심 수익원 중 하나로, 30%의 수수료를 부과합니다. PWA가 완전히 기능하면 이 수수료 수익이 줄어들 수 있다는 것이 배경에 있는 논리입니다.

iOS에서는 모든 브라우저가 내부적으로 WebKit 엔진을 사용해야 하는 정책이 있었습니다. 즉, iOS에서 Chrome을 설치하더라도 실제로는 WebKit 기반으로 돌아가므로 Chrome의 PWA 지원 기능을 온전히 사용할 수 없었습니다. EU의 디지털 시장법(DMA) 시행 이후 이 정책에 일부 변화가 생겼지만, 현실적으로 대부분의 iOS 사용자는 여전히 Safari 또는 WebKit 기반 브라우저를 사용하고 있습니다.

개발 현장에서 체감하는 고통

이러한 제한이 개발자에게 미치는 실질적인 영향은 상당합니다. 크로스 플랫폼 웹 앱을 만들려는 팀은 iOS Safari에서의 제한 사항을 매번 확인하고 우회 방법을 찾아야 합니다. "한 번 작성하면 모든 곳에서 동작한다"는 웹의 약속이 iOS에서 무너지는 셈입니다.

실무에서 흔히 마주치는 상황을 예로 들어보겠습니다. Service Worker 기반 캐싱을 구현했는데 iOS Safari에서 14일 후 캐시가 자동 삭제되는 문제, 홈 화면 PWA에서 외부 OAuth 로그인 시 Safari로 튕겨나가는 문제, iOS에서 input 요소의 줌 동작이 다르게 작동하는 문제 등이 개발자들이 반복적으로 겪는 어려움입니다.

이런 이슈들 하나하나는 사소해 보일 수 있지만, 종합적으로 보면 "PWA로 서비스를 만들자"는 의사결정을 주저하게 만드는 강력한 억제 요인이 됩니다. 결국 많은 팀이 iOS 지원을 위해 별도의 네이티브 앱을 만들거나, React Native, Flutter 같은 크로스 플랫폼 프레임워크로 전환하게 됩니다.

한국 개발자에게 주는 시사점

한국은 전 세계에서 iOS 점유율이 가장 높은 시장 중 하나입니다. 2025년 기준 약 30~35%의 모바일 사용자가 iPhone을 사용하고 있으며, 특히 20~30대에서는 이 비율이 훨씬 높습니다. 이는 한국에서 웹 앱을 서비스할 때 Safari의 제한 사항을 무시할 수 없다는 뜻입니다.

PWA를 메인 전략으로 고려하고 있는 팀이라면, 반드시 iOS Safari에서의 제한 사항 목록을 사전에 확인하고 프로젝트 범위에 반영해야 합니다. pwa.gripe 사이트는 이러한 확인을 위한 좋은 출발점이 됩니다. 또한 EU의 DMA가 Apple에 가하는 압력이 결국 전 세계 정책 변화로 이어질 가능성이 있으므로, 이 흐름을 지속적으로 주시할 필요가 있습니다.