cordova-plugin-inappbrowser는 구현 자체는 단순하지만, 릴리즈(서명/배포) 단계에서 설정이 조금만 어긋나도 “열리긴 열리는데 외부 브라우저로 빠짐”, “리다이렉트가 막힘”, “iOS에서 아무 반응 없음” 같은 문제가 자주 나옵니다. 이 글은 기능 구현 팁이 아니라, 서명/배포 실수 방지 관점에서 Android/iOS를 나눠 점검하는 가이드입니다.
개발 빌드에서 되면 안심하기 쉬운데, 릴리즈는 다른 규칙으로 굴러갑니다.
1) 릴리즈에서만 이슈가 나는 전형적인 패턴(먼저 증상 분류)
릴리즈에서 문제를 빨리 잡으려면 “무슨 기능이 안 되냐”보다 “어떤 패턴이냐”로 나누는 게 빠릅니다.
- 외부 브라우저(Safari/Chrome)로 열림: target 옵션/플랫폼 정책/플러그인 설치 상태/빌드 산출물 반영 문제
- 창이 안 뜨거나 바로 닫힘: iOS ATS(App Transport Security), 리다이렉트 차단, scheme/딥링크 충돌
- 로그는 조용한데 JS 콜백이 안 옴: 릴리즈에서 minify/난독화(Proguard/R8) 또는 WebView 설정 차이
- 특정 도메인만 실패: http/https 혼용, 인증서 체인, 리다이렉트, SSO 쿠키 정책(SameSite) 차이
아래 체크는 “Android/iOS 분기 가이드”로 구성했고, 마지막에 공통 체크리스트를 넣었습니다.
2) 공통: 릴리즈 전에 가장 먼저 확인할 것(플러그인/버전/반영)
릴리즈 이슈의 절반은 “설정은 바꿨는데 빌드 산출물에 반영이 안 됨”입니다. 특히 Cordova는 platform 폴더가 캐시처럼 남아서, 릴리즈 때만 다른 결과가 나기도 합니다.
- 플러그인 설치 확인: cordova-plugin-inappbrowser가 실제로 설치되어 있는지(프로젝트 루트에서 플러그인 목록 확인)
- 플랫폼별 정리 후 재추가: 설정을 크게 바꿨다면 platform remove/add로 반영 꼬임을 줄이기
- 릴리즈 빌드 플래그: Android는 release variant, iOS는 Archive/Release configuration에서 테스트
- 테스트 URL 고정: 릴리즈 검증용으로 리다이렉트가 단순한 https URL을 하나 고정해 두기
여기까지가 “환경이 정상인가?” 확인이라면, 아래부터는 플랫폼별 분기로 들어갑니다.
3) Android 분기 가이드: 서명/릴리즈 설정에서 InAppBrowser가 흔들리는 지점
Android는 “서명” 자체가 InAppBrowser를 직접 막는 경우는 드물지만, 릴리즈 빌드에서만 적용되는 설정들 때문에 동작이 달라집니다. 특히 targetSdk/Network Security/Chrome Custom Tabs 쪽에서 차이가 납니다.
- Network Security 정책: http로 열거나, 사설 인증서/중간 인증서가 빠진 서버에 접근하면 release에서만 실패처럼 보일 수 있습니다. 가능하면 InAppBrowser로 여는 URL은 https만 사용하세요.
- targetSdk 상승 후 동작 변화: targetSdk가 올라가면 WebView/쿠키 정책이 바뀌며 SSO가 깨지는 케이스가 있습니다. 릴리즈 업그레이드 직후라면 이 변화를 의심하세요.
- 릴리즈에서만 minifyEnabled 적용: 앱 JS가 아니라 네이티브 쪽이지만, 특정 플러그인이 Proguard/R8 규칙 부족으로 오동작하는 경우가 있습니다. InAppBrowser 자체보다는 연동(로그인 SDK, deep link 처리)이 묶여서 문제처럼 보입니다.
- 외부로 열리는 문제: _blank가 아닌 _system으로 열고 있지 않은지, 또는 앱 내에서 target 옵션이 빌드 타입별로 분기되어 있지 않은지 확인하세요.
Android는 릴리즈에서 “안전 정책”이 강해진다고 보면 편합니다. 릴리즈 전에는 https/리다이렉트/쿠키가 안정적인지 먼저 확인하는 게 시간 절약입니다.
4) iOS 분기 가이드: 배포(Archive)에서 자주 나는 실수(ATS/Entitlements/도메인)
iOS는 릴리즈(Archive/TestFlight/App Store)로 갈수록 네트워크 정책과 서명 관련 제약이 더 눈에 띄게 드러납니다. InAppBrowser가 “그냥 WebView로 URL 여는 것”처럼 보여도, ATS와 도메인/리다이렉트에서 막히는 일이 많습니다.
- ATS(App Transport Security): http를 열면 거의 확실히 막힙니다. 개발에서 임시로 예외 처리했더라도, 릴리즈에서는 예외를 최소화하고 https로 정리하세요.
- 리다이렉트 체인: 최종 목적지는 https여도, 중간에 http가 끼거나 인증서 문제가 있으면 iOS에서 조용히 실패합니다. 릴리즈 검증은 “최종 URL”이 아니라 리다이렉트 전체를 기준으로 봐야 합니다.
- SSO/쿠키 이슈: iOS는 쿠키/세션 정책 변화에 민감합니다. 릴리즈에서만 로그인 유지가 풀린다면, SameSite 설정이나 도메인(서브도메인 포함) 차이를 먼저 점검하세요.
- 관련 Capability/Entitlements 충돌: InAppBrowser 자체가 특별한 Capability를 요구하진 않지만, 결제/딥링크/로그인 SDK가 함께 들어간 앱은 Archive 시 서명 설정이 달라지면서 리다이렉트 처리나 앱 복귀 흐름이 깨질 수 있습니다.
iOS는 “열리는지”만 보지 말고, 열고 난 뒤 로그인/결제/리다이렉트 후 복귀까지 한 번에 통과하는지를 릴리즈에서 확인하는 게 핵심입니다.
5) 릴리즈 실수 방지 체크리스트(배포 직전 10분 점검)
배포 직전에 아래만 체크해도 “스토어 올리고 나서 발견하는” 사고를 많이 줄일 수 있습니다.
- URL 정책: InAppBrowser로 여는 URL이 전부 https인지(중간 리다이렉트 포함)
- 동일 URL로 릴리즈 빌드 테스트: Debug가 아니라 Release/Archive 산출물로 직접 실행
- target 옵션 재확인: _blank / _system 선택이 의도와 맞는지(플랫폼별 분기 코드 포함)
- 리다이렉트/딥링크 흐름: 외부 인증 후 앱 복귀까지 한 사이클 점검
- 플랫폼 캐시 정리: 설정 변경 후에는 platform 재추가 또는 clean 빌드로 반영 확인
- 로그 확보: Android는 logcat, iOS는 Xcode device log로 “실패 순간” 기록 남기기
체크리스트가 통과했는데도 릴리즈에서만 문제가 나면, “서명 그 자체”보다는 네트워크 정책(ATS/https), 리다이렉트, 쿠키 정책, 릴리즈 빌드 전용 설정에서 답이 나오는 경우가 대부분입니다.
마무리
InAppBrowser는 구현보다 배포 단계의 정책/설정 차이가 변수를 만듭니다. Android는 릴리즈 전용 설정(minify, targetSdk, 네트워크 정책)을, iOS는 ATS와 리다이렉트/쿠키 흐름을 중심으로 먼저 의심해 보세요.
릴리즈 빌드로 같은 URL을 반복 테스트하고, 플랫폼별 분기 포인트를 체크리스트로 고정하면 배포 실수를 크게 줄일 수 있습니다.