앱을 만들자는 이야기가 나오면 대개 견적서부터 받습니다. iOS와 안드로이드 두 벌, 스토어 등록, 심사 대응까지 항목이 붙으면서 금액이 커집니다. 그런데 그 목록의 상당수는 홈 화면에 추가하는 웹앱으로도 해결됩니다.
문제는 어디까지 웹으로 되는지 한 줄로 정리해 주는 곳이 없다는 점입니다. iOS 푸시 알림만 해도 된다는 말과 안 된다는 말이 같이 돌아다닙니다. 조건을 알면 견적서를 받기 전에 직접 가를 수 있습니다.
홈 화면에 추가한 웹사이트는 이제 그냥 앱처럼 열립니다
2025년 9월 15일 공개된 Safari 26.0부터 홈 화면에 추가한 모든 웹사이트가 웹앱으로 열립니다. WebKit은 이제 Safari에 설치 요건이 전혀 없다고 밝혔습니다. 매니페스트 파일이나 서비스 워커를 갖춰야만 앱처럼 열리던 제약이 사라진 것입니다.
사용자가 보는 결과는 주소창 없는 전체 화면, 홈 화면 아이콘, 독립 실행입니다. 고객이 앱 같다고 느끼는 요소는 대부분 여기서 충족됩니다. 남는 차이는 알림, 스토어, 하드웨어 세 갈래입니다.
iOS 웹 푸시가 되는 조건은 두 개입니다
첫째, 기기가 iOS 또는 iPadOS 16.4 이상이어야 합니다. 이 버전은 2023년 3월에 배포됐습니다. 둘째, 사용자가 그 사이트를 홈 화면에 추가한 상태여야 합니다. Safari 탭에서 열어 둔 상태로는 푸시가 오지 않습니다.
권한을 요청하는 시점에도 제약이 있습니다. WebKit 문서 기준으로 알림 권한은 사용자가 버튼을 누르는 등 직접 조작한 직후에만 요청할 수 있습니다. 화면이 열리자마자 권한 팝업을 띄우는 방식은 iOS에서 동작하지 않습니다.
iOS에서 웹 푸시가 안 된다는 말은 절반만 맞습니다. Safari 탭에서 안 되는 것이고, 홈 화면에 추가된 웹앱에서는 됩니다.
진짜 장벽은 버전이 아니라 홈 화면에 추가하는 단계입니다
애플이 2026년 6월 7일 App Store 거래 기준으로 공개한 수치를 보면 전체 iPhone의 79%, 최근 4년 내 출시 기기의 86%가 iOS 26을 쓰고 있습니다. 16.4 이상 비율은 따로 공개되지 않지만, 세 세대 이전 버전이라 기기 버전이 발목을 잡는 상황은 아닙니다.
대신 사용자가 공유 메뉴에서 홈 화면에 추가를 직접 눌러야 푸시 대상이 됩니다. 네이티브 앱의 설치 버튼 한 번과 비교하면 여기서 이탈이 생깁니다. 푸시가 사업의 핵심이라면 이 안내 화면을 만드는 비용을 견적에 넣으세요.
웹으로 되는 것과 안 되는 것을 표로 갈라 보세요
아래 표는 홈 화면에 추가한 웹앱 기준입니다. 오른쪽 칸이 필요로 표시된 항목 중 하나라도 사업의 핵심이면, 그때부터 네이티브 견적을 받으면 됩니다.
| 항목 | 홈 화면 웹앱(iOS) | 네이티브 필요 여부 |
|---|---|---|
| 푸시 알림 | 16.4 이상 + 홈 화면 추가 시 가능 | 조건 밖이면 필요 |
| 아이콘 배지 숫자 | 16.4부터 가능 | 불필요 |
| App Store 노출 | 불가 | 필요 |
| Google Play 노출 | TWA 방식으로 등록 가능 | 대체로 불필요 |
| 디지털 상품 판매 | 스토어 밖에서 자체 결제 가능 | 스토어 판매 시 필요 |
| 블루투스 기기 연결 | 불가 | 필요 |
| NFC 태그 읽기 | 불가 | 필요 |
| 오프라인 자동 재전송 | 불가 | 필요 |
| 저장 데이터 7일 삭제 | 홈 화면 웹앱은 예외 | 불필요 |
스토어에 보여야 한다면 iOS는 네이티브가 필요합니다
앱 심사 지침 4.2는 웹사이트를 그대로 옮긴 수준을 넘어서는 기능과 UI를 갖추라고 요구합니다. 4.2.2는 웹 페이지 조각이나 링크 모음이 주된 앱을 허용하지 않습니다. 웹앱을 껍데기로 감싸 App Store에 올리려는 계획은 여기서 막힙니다.
안드로이드는 사정이 다릅니다. 구글은 Trusted Web Activity 방식으로 웹앱을 Play에 등록하도록 지원하고, 사이트와 앱이 같은 소유자임을 Digital Asset Links로 검증합니다. 스토어 노출이 요구사항이면 iOS 쪽에만 별도 비용이 생깁니다.
디지털 상품을 판다면 결제 규정부터 확인하세요
심사 지침 3.1.1은 앱 안에서 구독, 프리미엄 콘텐츠, 정식 버전 잠금 해제 같은 것을 열어 줄 때 인앱결제를 쓰라고 요구합니다. 라이선스 키나 QR 코드로 우회하는 방식도 금지합니다. 스토어에 들어가는 순간 결제 수단 선택권이 사라집니다.
반대로 3.1.3(e)는 앱 밖에서 소비되는 실물 상품과 서비스는 인앱결제가 아닌 수단으로 받으라고 정합니다. 예약, 방문 서비스, 배송 상품을 파는 사업이라면 웹앱에서 쓰던 결제사를 그대로 쓰는 편이 규정과 정산 양쪽에서 단순합니다.
블루투스와 NFC, 백그라운드 동작은 웹에서 막힙니다
Safari는 데스크톱과 iOS 모두 Web Bluetooth를 지원하지 않습니다. caniuse 집계 기준으로 26.6 버전까지 미지원입니다. 웹 NFC도 안드로이드 크롬 계열에만 있고 Safari에는 없습니다. 기기와 직접 연결하는 제품은 여기서 갈립니다.
오프라인에서 쌓인 요청을 네트워크가 돌아왔을 때 자동으로 보내는 백그라운드 동기화도 Safari에는 없습니다. 크롬은 49 버전부터 지원합니다. 현장 점검이나 배송 기사용처럼 통신이 자주 끊기는 환경이라면 이 차이가 실제 사고로 이어집니다.
7일 뒤 데이터가 지워진다는 걱정은 홈 화면 웹앱에 해당하지 않습니다
Safari의 추적 방지 정책은 사용자 조작이 7일간 없으면 스크립트가 쓴 저장소를 지웁니다. IndexedDB, 로컬 스토리지, 서비스 워커 등록이 여기 포함됩니다. 웹앱은 로그인이 자꾸 풀린다는 이야기가 여기서 나왔습니다.
다만 WebKit은 홈 화면 웹앱의 자기 도메인은 이 7일 규칙에서 제외한다고 명시합니다. 해당 데이터는 Safari와 분리해 보관됩니다. 홈 화면에 추가된 상태라면 로그인 유지 때문에 네이티브를 고를 이유는 없습니다.
이럴 때는 웹앱으로 가지 마세요
다음 중 하나라도 핵심 기능에 들어 있으면 네이티브가 맞습니다. 부가 기능이면 그 부분만 따로 떼어 생각하세요.
- 블루투스 기기, NFC 태그, 외장 센서와 연결해야 하는 경우
- 앱이 꺼진 동안 위치를 기록하거나 데이터를 자동 동기화해야 하는 경우
- App Store 등록 자체가 계약이나 입점 조건인 경우
- 디지털 콘텐츠 구독을 스토어 안에서 팔아야 하는 경우
- 홈 화면에 추가를 스스로 하기 어려운 고객층이 주 사용자인 경우
반대로 조회, 예약, 신청, 사내 업무 화면처럼 화면과 데이터가 중심인 서비스는 웹앱으로 충분합니다. 표에 없는 개별 기능은 사용할 API마다 지원 여부를 따로 확인해야 합니다.
견적을 받기 전에 이 순서로 걸러 보세요
- 기능 목록을 적고 위 표에서 필요로 표시된 항목과 대조합니다.
- 푸시가 필요하면 16.4 이상 지원과 홈 화면 추가 안내 화면을 요구사항에 넣습니다.
- 스토어 노출이 누구의 요구인지, 실제 유입 경로가 맞는지 확인합니다.
- 걸리는 항목이 없으면 웹앱으로 만들고, 남으면 그 기능만 네이티브로 견적을 받습니다.
조건을 직접 확인하려면 WebKit의 웹 푸시 안내와 애플 앱 심사 지침 한국어판이 1차 자료입니다. 비슷한 판단 기준은 실무 가이드 카테고리에도 정리해 두었고, 요구사항 정리가 막히면 Codeforest에 문의하셔도 됩니다.
결론: 웹으로 안 되는 항목이 있는지부터 확인하세요
iOS 웹 푸시는 16.4 이상과 홈 화면 추가라는 두 조건만 맞으면 동작하고, 아이콘 배지도 같은 조건에서 됩니다. 반면 App Store 노출, 스토어 안 디지털 결제, 블루투스, NFC, 백그라운드 동기화는 웹으로 대체되지 않습니다.
그래서 판단의 순서는 앱이냐 웹이냐가 아니라, 웹으로 못 하는 항목이 우리 기능 목록에 있느냐입니다. 없으면 웹앱 한 벌로 끝나고, 있으면 그 기능 때문에 두 벌을 만드는 것입니다. 이 확인을 먼저 하면 견적서의 절반은 줄어듭니다.