iOS 26에서 홈 화면에 추가한 웹앱의 쿠키가 사라졌다.
모바일 웹에는 "홈 화면에 추가" 기능이 있습니다. 앱을 설치하지 않아도 휴대폰 홈 화면에 아이콘을 만들어두고, 앱처럼 탭해서 들어올 수 있게 해주는 기능입니다. 크롬, 삼성인터넷, 사파리 모두 이 기능을 제공합니다.
그런데 최근 iOS 26 기기에서 이상한 경우를 발견했습니다. 사파리에서 로그인한 사용자가 홈 화면에 추가한 아이콘으로 다시 들어오면 로그인이 풀려 있었습니다. 안드로이드의 크롬과 삼성인터넷에서는 같은 현상이 없었습니다.
이 글에서는 세 브라우저가 "홈 화면에 추가"를 각각 어떻게 처리하는지, 왜 사파리만 로그인이 풀리는지, 그리고 대응법을 정리합니다.
같은 버튼인데 브라우저마다 다른 일을 한다
먼저 세 브라우저의 "홈 화면에 추가"가 실제로 무엇을 만드는지 확인했습니다.
크롬(안드로이드)은 두 가지를 만듭니다. 사이트가 PWA 조건을 갖췄고 기기에 구글 모바일 서비스(GMS)가 있으면 WebAPK라는 작은 안드로이드 앱 패키지를 만들어 설치합니다. 그렇지 않으면 크롬 아이콘이 붙은 바로가기를 만듭니다. 어느 쪽이든 탭하면 크롬이 페이지를 띄웁니다. 최근 크롬은 매니페스트가 없는 사이트도 설치할 수 있게 바뀌었습니다.
삼성인터넷도 구조가 같습니다. 갤럭시 기기에서는 삼성이 운영하는 서버가 WebAPK를 만들어주고, 다른 기기에서는 바로가기를 만듭니다. 역시 탭하면 삼성인터넷이 열립니다.
사파리는 다릅니다. iOS 26 전까지는 사이트가 매니페스트나 메타 태그로 "나는 웹앱이다"라고 선언했을 때만 앱처럼 열렸고, 아니면 사파리 북마크로 열렸습니다. iOS 26부터는 이 규칙이 바뀌었습니다. WebKit 블로그의 설명을 옮기면 이렇습니다.
기본적으로 홈 화면에 추가된 모든 웹사이트는 웹앱으로 열립니다. 사용자가 브라우저용 북마크를 원하면, 사이트가 웹앱으로 설정되어 있더라도 홈 화면에 추가할 때 "웹앱으로 열기"를 끌 수 있습니다.
즉 iOS 26에서는 매니페스트가 있든 없든 모든 사이트가 기본으로 웹앱이 됩니다. 그리고 웹앱으로 열지 북마크로 열지는 개발자가 아니라 사용자가 토글로 정합니다. 사파리 공유 시트에서 "홈 화면에 추가"를 누르면 "웹앱으로 열기" 토글이 보이는데, 이 토글이 이번 글의 주인공입니다.
사파리 웹앱은 사파리가 아니었다
토글을 켜고 만든 웹앱은 사파리가 아닙니다. 사파리와 같은 엔진(WebKit)을 쓰는 별도의 앱 컨테이너입니다. 그래서 쿠키, localStorage, IndexedDB, 서비스 워커까지 저장소가 전부 따로 있습니다.
이건 iOS 26에 새로 생긴 동작이 아닙니다. WebKit 버그 트래커에는 2018년에 올라온 "Add to homescreen" apps don't share storage with Safari라는 리포트가 있습니다. iOS 11.3에서 홈 화면 웹앱의 저장소가 사파리와 분리됐고, 그 뒤로 지금까지 같은 구조입니다. WebKit 블로그도 2020년 글에서 "홈 화면에 추가된 웹 애플리케이션은 사파리의 일부가 아니다"라고 직접 적었습니다.
그럼 iOS 26 이전에는 왜 이 문제를 못 봤을까요. 그때는 매니페스트에 display: standalone을 넣은 사이트만 웹앱이 됐고, 그렇지 않은 사이트는 북마크로 열려 사파리 저장소를 그대로 썼습니다. 웹앱을 선언하지 않은 사이트는 자연히 로그인이 유지됐던 겁니다. iOS 26에서 기본값이 웹앱으로 바뀌면서, 그동안 웹앱과 무관하던 사이트들까지 이 분리된 저장소를 마주하게 됐습니다.
그래도 쿠키는 한 번 복사된다
여기서 한 가지 짚어둘 것이 있습니다. 애플도 "만들자마자 로그인이 풀리는" 경험이 나쁘다는 건 알고 있었습니다. 그래서 iOS 17.2부터 홈 화면에 추가하는 순간 사이트의 쿠키를 웹앱으로 복사합니다. WebKit 블로그의 Safari 17.2 글에 이렇게 적혀 있습니다.
사파리, Safari View Controller, 혹은 다른 브라우저에서 "홈 화면에 추가"를 탭해 웹앱을 만들면 로그인 상태를 포함한 쿠키가 복사됩니다. 이는 인증 상태가 쿠키에 저장돼 있을 때만 동작하며, 다른 종류의 로컬 저장소는 복사하지 않습니다. 웹앱을 홈 화면에 추가한 뒤에는 다른 웹사이트 데이터가 공유되지 않습니다.
복사는 "추가하는 순간" 딱 한 번입니다. 그 뒤로 두 저장소는 서로 독립됩니다.
그래서 다음 경우에 웹앱의 로그인이 풀립니다.
- 홈 화면에 먼저 추가하고, 로그인은 나중에 사파리에서 했다. 웹앱에는 로그인 전 상태가 복사돼 있습니다.
- 추가할 때는 로그인 상태였지만, 세션 쿠키가 만료된 뒤 사파리에서만 다시 로그인했다. 웹앱은 만료된 옛 쿠키를 들고 있습니다.
- 로그인 정보를 쿠키가 아니라 localStorage에 토큰으로 저장했다. 이 경우는 처음부터 아무것도 복사되지 않습니다.
안드로이드는 왜 괜찮았을까
크롬과 삼성인터넷에서 문제가 없었던 이유는 반대로 단순합니다. 홈 화면 아이콘이 브라우저 밖으로 나가지 않기 때문입니다.
WebAPK는 이름은 앱이지만 속은 얇은 껍데기입니다. 아이콘, 스플래시 화면, 시스템 설정 항목 정도만 가지고 있고, 실행하면 그 WebAPK를 설치한 브라우저의 프로세스를 띄워 지정된 URL을 엽니다. 크롬의 web.dev 문서는 저장소에 대해 이렇게 설명합니다.
크롬은 현재 프로필을 사용해 데이터를 저장하며, 데이터를 따로 분리하지 않습니다. 브라우저와 설치된 앱 사이에 공유된 경험이 가능합니다. 쿠키는 공유되고 활성 상태이며, 클라이언트 측 저장소에 접근할 수 있고, 서비스 워커는 이미 설치돼 있습니다.
바로가기는 더 단순합니다. 크롬 탭 하나를 여는 것과 같습니다. 크롬으로 만든 바로가기는 크롬에서, 삼성인터넷으로 만든 바로가기는 삼성인터넷에서 열리고, 각 브라우저의 저장소를 그대로 씁니다. 삼성인터넷의 WebAPK도 같은 방식으로 삼성인터넷을 띄우는 구조인데, 저장소 공유를 명시한 삼성 공식 문서 문장은 찾지 못했습니다. 다만 브라우저 프로세스 안에서 페이지가 열리는 구조상 크롬과 같은 결과가 나온다고 이해하고 있고, 제가 확인한 갤럭시 기기에서도 로그인이 유지됐습니다.
그러니 안드로이드에서는 "홈 화면 아이콘 = 브라우저의 다른 입구"이고, iOS에서는 "홈 화면 웹앱 = 브라우저와 닮은 다른 앱"입니다.
그래서 무엇을 할 수 있나
원인을 알고 나서 몇 가지 대응을 검토했습니다. 각각 한계가 있어서 함께 적어둡니다.
첫째, 로그인 상태를 쿠키에 둡니다. localStorage 토큰 방식은 iOS 웹앱에 아무것도 복사되지 않습니다. 쿠키라면 최소한 추가 시점의 로그인은 넘어갑니다. 제 케이스는 이미 쿠키 방식이어서 이 부분은 해당하지 않았습니다.
둘째, 쿠키 수명을 충분히 길게 잡고 서버에서 갱신합니다. 복사된 쿠키가 빨리 만료되면 웹앱은 곧 로그아웃 상태가 됩니다. 리프레시 토큰을 쿠키로 두고 웹앱 안에서 갱신되게 하면 복사본 하나로 오래 버틸 수 있습니다. 단, 추가 이후에 사파리에서 새로 로그인한 세션은 여전히 넘어오지 않습니다.
셋째, 웹앱으로 열린 상태를 감지해 안내합니다. window.matchMedia("(display-mode: standalone)")이나 iOS 전용 navigator.standalone으로 지금 웹앱 안인지 알 수 있습니다. 웹앱인데 로그인이 없다면 "홈 화면 앱에서는 처음 한 번 다시 로그인이 필요합니다"라고 알려주는 편이, 아무 설명 없이 로그인 화면을 보여주는 것보다 낫다고 판단했습니다.
const isStandalone =
window.matchMedia("(display-mode: standalone)").matches ||
(navigator as { standalone?: boolean }).standalone === true;
넷째, 사용자에게 토글을 끄는 방법을 안내합니다. "웹앱으로 열기"를 끄면 북마크가 되고 사파리 저장소를 그대로 씁니다. 하지만 이 선택은 사용자 손에 있습니다. WebKit 블로그는 "사이트 코드가 어떻게 설정돼 있든 UI는 항상 같다"고 적고 있어서, 개발자가 매니페스트로 북마크를 강제할 방법은 없다고 이해했습니다. 안내는 할 수 있지만 보장은 못 합니다.
다섯째, 캐시 스토리지가 두 저장소 사이에 공유된다는 점을 이용해 상태를 주고받는 우회법이 예전에 소개된 적이 있습니다. 다만 2019년 무렵의 글이고, 문서화되지 않은 동작에 의존하는 방식이어서 저는 시도하지 않았습니다. 현재 iOS 26에서 여전히 동작하는지도 확인하지 못했습니다.
참고 자료
- WebKit Features in Safari 26.0 — iOS 26의 "웹앱으로 열기" 기본값과 토글 설명
- News from WWDC25: WebKit in Safari 26 beta — 매니페스트 없이도 웹앱이 되는 변경
- WebKit Features in Safari 17.2 — 홈 화면 추가 시 쿠키 복사 동작
- Full Third-Party Cookie Blocking and More — "홈 화면 웹앱은 사파리의 일부가 아니다"
- WebKit Bug 181849 — "Add to homescreen" apps don't share storage with Safari — 2018년부터 이어진 저장소 분리 리포트
- Apple Support — Turn a website into an app in Safari on iPhone — 사용자용 "웹앱으로 열기" 안내
- Apple confirms iOS 17.4 removes Home Screen web apps in the EU (9to5Mac) — 애플의 저장소 격리·권한 모델 설명 인용
- WebAPKs on Android (web.dev) — 크롬 WebAPK의 저장소 공유 설명
- Installation (web.dev Learn PWA) — 크롬·삼성인터넷의 WebAPK와 바로가기 구분
- Adding web apps to your homescreen (Samsung Internet Dev Hub) — 삼성인터넷 홈 화면 추가 안내