아이폰과 안드로이드를 동시에 만든다는 것

iPhone 화면에서는 일정이 잘 보였습니다. 초대도 되고 위젯도 뜨고, 스토어 이미지도 준비됐어요. 이제 Android에 같은 앱을 올리면 끝이라고 생각했습니다.

그런데 기기가 달라지니 위젯의 빈 상태가 달랐고, 뒤로 가기 동작이 달랐고, 스토어가 요구하는 테스트 증거도 달랐어요. 한쪽에서 자연스러운 설명 문장이 다른 쪽 메타데이터에서는 맞지 않을 수도 있었고요. 같은 제품을 복사하는 일이 아니라 같은 약속을 서로 다른 규칙으로 증명하는 일이었습니다.

데이리플은 한 사람만 쓰는 도구가 아니에요. iPhone을 쓰는 사람과 Android를 쓰는 사람이 같은 일정을 봐야 제품이 완성됩니다. 그래서 한 플랫폼에서 먼저 예쁘게 끝내는 것보다, 처음부터 두 플랫폼에서 같은 핵심 행동이 되는지를 더 중요하게 봤어요.

"같이 지원한다"는 말부터 쪼개야 했습니다

두 스토어에 앱이 있다는 사실만으로 함께 쓸 수 있는 건 아니에요. 초대 링크가 열리고, 같은 공간에 들어가고, 한 사람이 만든 일정이 다른 사람에게 보이고, 수정과 삭제가 맞게 반영되고, 알림과 위젯이 각 기기에서 작동해야 합니다.

저는 이걸 기능 목록이 아니라 왕복으로 봐야 한다는 걸 꽤 늦게 배웠어요.

"iPhone에서 일정을 만들어요 → Android에서 봐요 → Android에서 시간을 바꿔요 → iPhone에서 바뀐 값을 확인해요."

이 한 줄이 성공해야 "크로스 플랫폼 공유"라고 말할 수 있습니다. 빌드가 둘 다 끝났다는 사실이나 스토어 페이지가 열렸다는 사실은 왕복 증거가 아니에요. 이 차이는 혼자 QA할 때 확인해야 할 것에도 적어 뒀습니다.

화면은 비슷해도 운영체제의 문법은 다릅니다

iPhone과 Android에는 각각 익숙한 뒤로 가기, 날짜 선택, 알림 권한, 위젯 추가 방식이 있어요. 모든 픽셀을 같게 만들면 브랜드는 통일돼 보이겠지만 한쪽 사용자가 불편해집니다.

그래서 같은 것은 결과와 정보 순서로 잡고, 조작은 플랫폼 문법을 따르는 편이 낫다고 봤어요. 월간 화면에서 오늘과 선택한 날짜가 구분되고, 새 일정을 만들고, 공유 상대가 결과를 보는 흐름은 같아야 합니다. 하지만 뒤로 가는 버튼 위치나 위젯을 홈 화면에 추가하는 동작까지 억지로 같게 만들 필요는 없어요.

2026년 8월 Apple 공식 도움말은 홈 화면 배경을 길게 누르고 편집, 위젯 추가를 거쳐 크기와 스타일을 고르는 흐름을 안내합니다. Google Android 공식 도움말은 빈 공간을 길게 누른 뒤 위젯을 선택하고 원하는 앱의 위젯을 끌어 놓도록 안내하고요. 그러니 사용자에게 설명할 때도 "둘 다 위젯 지원"까지만 같고, 설치 순서는 각각 써야 정확합니다.

iPhone 위젯 추가법과 iPhone·갤럭시 일정 공유를 따로 둔 이유가 여기 있어요.

스토어 이미지는 장식이 아니라 제품 설명이었어요

같은 앱의 두 스토어 화면을 만들 때 달, 일정, 문구가 서로 다르면 사용자는 실제 기능 차이로 오해합니다. 그래서 같은 시나리오와 같은 가상 데이터를 쓰되, 각 스토어 규칙에 맞춰 문구와 기기 프레임을 조정해야 했어요.

Apple의 2026년 8월 App Review Guidelines는 스크린샷이 실제 사용 모습을 보여야 하고, 메타데이터가 최신 핵심 경험을 정확히 반영해야 한다고 안내합니다. 다른 모바일 플랫폼의 이름·아이콘·이미지를 앱이나 메타데이터에 넣지 말라는 조항도 있어요. 그래서 iPhone 스토어 설명에서 Android를 과하게 전면에 내세우는 방식은 조심해야 합니다.

이건 다른 플랫폼을 숨기는 일이 아니에요. 제품 페이지는 해당 스토어 사용자가 자신이 받을 경험을 이해하는 자리니까요. 크로스 플랫폼이라는 효익은 설명하되, 다른 운영체제의 로고를 장식처럼 쓰지 않는 식으로 풀어야 합니다. 앱스토어 심사에서 배운 것에 이 판단을 이어 적어 뒀어요.

Android의 12명·14일은 숫자 채우기가 아니었습니다

Google Play 공식 도움말은 2026년 8월 기준으로 2023년 11월 13일 이후 만든 개인 개발자 계정이 프로덕션 접근을 신청하려면 최소 12명의 테스터가 14일 동안 계속 참여한 비공개 테스트를 운영해야 한다고 안내합니다.

여기서 제가 놓친 건 "참여"와 "테스트"의 차이였어요. 사람 수와 날짜 조건을 채웠다고 앱이 준비됐다는 뜻은 아니거든요. 프로덕션 접근을 신청할 때는 앱 설계, 테스트 과정, 준비 상태에 대한 질문에 답해야 합니다. 실제로 어떤 화면을 확인했고 무엇을 고쳤는지가 남아 있어야 해요.

테스터에게 "그냥 설치만 해 주세요"라고 부탁하면 숫자는 채워도 제품은 검증되지 않습니다. 초대 수락, 일정 생성, 반대 기기에서 수정, 알림, 위젯 같은 짧은 시나리오를 주는 편이 좋아요. 실패한 화면과 기기 종류를 적으면 14일이 기다림이 아니라 개선 기간이 됩니다.

첫 달에 밟은 실수는 비개발자가 처음 만드는 앱의 함정에, 제품을 만들 때 기능보다 먼저 정할 것은 기능보다 중요한 것에 정리했어요.

출시일보다 기능 약속을 맞추는 게 먼저였어요

두 스토어 심사 속도가 다르면 한쪽만 먼저 승인됩니다. 이때 날짜를 무조건 같게 맞추려고 준비된 버전을 오래 묶어 두는 것도, 다른 쪽 핵심 기능이 빠진 채 "동시 지원"이라고 알리는 것도 위험해요. 사용자에게 한 약속 가운데 무엇이 두 플랫폼에서 실제로 가능한지 먼저 정해야 합니다.

출시 표에는 플랫폼별 상태를 따로 적는 편이 좋아요. 빌드가 만들어졌는지, 실제 기기에서 왕복했는지, 심사에 제출됐는지, 스토어에서 받을 수 있는지를 서로 다른 칸으로 둡니다. "완료" 한 칸으로 묶으면 iPhone 승인 사실을 Android 출시로 잘못 읽기 쉬워요.

기능을 업데이트할 때도 같은 원칙이 필요합니다. 한쪽에만 먼저 들어간 기능이 공유 데이터 형식을 바꾸면, 이전 버전의 상대가 일정을 열지 못할 수 있어요. 새 값을 모르는 버전에서도 기존 일정이 깨지지 않는지 확인하고, 두 플랫폼의 최소 지원 버전과 업데이트 안내를 정해야 합니다.

스토어 설명에는 지금 받을 수 있는 버전의 기능만 적어요. 개발이 끝났지만 아직 심사 중인 기능을 이미 쓸 수 있는 것처럼 소개하면, 사용자는 다운로드 뒤 다른 화면을 만납니다. 로드맵, 코드 완료, 실제 배포를 분리해 말하는 습관이 두 플랫폼에서는 훨씬 더 중요했어요.

자주 나오는 오해 넷

"한 코드로 만들면 두 플랫폼 비용도 하나다." 공유 코드가 많으면 개발량은 줄어듭니다. 하지만 권한, 알림, 위젯, 스토어 자산, 심사, 실제 기기 확인은 그대로 따로 남아요. 코드 묶음이 하나라는 사실과 출시 과정이 하나라는 사실은 다릅니다.

"iPhone에서 되면 Android에서도 거의 된다." 핵심 로직은 같을 수 있어요. 그런데 홈 화면, 뒤로 가기, 권한 거부 후 흐름, 제조사별 위젯 동작은 다릅니다. 한쪽 성공을 다른 쪽 증거로 쓰면 안 돼요. 적어도 서로 다른 기기에서 왕복 시나리오는 확인해야 합니다.

"스토어 심사는 기능이 좋으면 통과한다." 기능뿐 아니라 설명, 스크린샷, 개인정보 표시, 결제 방식, 테스트 준비도 함께 봅니다. 실제 기능이 있어도 메타데이터가 오해를 만들면 문제가 될 수 있어요. 반대로 심사를 통과했다고 모든 기기에서 오류가 없다는 뜻도 아니고요.

"12명과 14일만 채우면 Android 출시는 자동이다." Google의 공식 안내는 조건을 충족한 뒤 프로덕션 접근을 신청한다고 설명합니다. 테스트 과정과 준비 상태에 답해야 하니 달력만 채우는 절차로 보면 안 돼요. 게다가 이 숫자는 특정 시점 이후 개인 계정에 적용되는 조건이지 모든 개발자 계정의 보편 규칙이 아닙니다.

이 숫자를 읽을 때 알아두실 것

12명, 14일, 2023년 11월 13일은 2026년 8월 Google Play 공식 도움말에서 확인한 현재 조건이에요. 정책은 바뀌고, 계정 유형과 생성 시점에 따라 적용 범위도 달라집니다. 출시 직전 Play Console과 공식 도움말을 다시 확인해야 해요.

Apple 메타데이터 설명도 2026년 8월 공식 심사 지침을 기준으로 했습니다. 이 글은 모든 거절 사유를 목록화한 법칙이 아니라, 제가 겪은 개발 과정을 공식 문서와 대조해 정리한 기록이에요. 어느 스토어에서 통과한 경험을 다음 심사의 보장으로 읽으면 안 됩니다.

두 플랫폼을 함께 만들 때 남겨야 할 증거

기능마다 "구현됨"이라는 체크 대신 실제 왕복 기록을 남겨 보세요. 어느 기기에서 시작했고, 반대 기기에서 무엇을 확인했으며, 알림과 위젯은 언제 보였는지 적는 겁니다. 스크린샷도 같은 가상 일정으로 맞추고, 스토어별 설명은 각 정책에 맞게 검토하고요.

그리고 완료를 세 층으로 나누면 좋습니다.

• 코드가 준비됐는가
• 실제 기기에서 핵심 흐름이 왕복했는가
• 스토어가 현재 버전을 배포하고 있는가

첫 번째가 끝났다고 세 번째까지 됐다고 말하지 않는 것. 비개발자가 두 플랫폼을 함께 만들며 제가 배운 가장 비싼 기준이에요. 위젯 하나가 오래 걸린 이유도 같은 증거 문제를 다룹니다.

자주 묻는 질문

한 플랫폼부터 출시하는 게 더 빠르지 않나요?

빠를 수 있어요. 다만 공유 앱의 핵심 사용자가 서로 다른 기기를 쓴다면 한쪽 출시만으로는 제품의 핵심 약속을 검증하기 어렵습니다. 대상 사용자의 기기 조합으로 순서를 정해야 해요.

크로스 플랫폼 프레임워크면 실제 기기 테스트를 줄여도 되나요?

공유 코드의 오류는 줄어들어도 운영체제와 기기 차이는 남습니다. 초대, 수정 왕복, 알림, 위젯처럼 플랫폼 경계에 닿는 기능은 각각 확인하는 편이 안전해요. 특히 제조사가 다양한 Android는 화면 크기와 운영체제 버전이 갈라져 있어서, 한두 기종 통과가 전체의 안전을 보장하지 않습니다. 점유율 높은 기종 몇 개를 최소 확인 기준으로 정해두는 편이 현실적이에요.

Google Play의 12명·14일 조건은 모든 계정에 적용되나요?

아니요. 2026년 8월 공식 안내는 2023년 11월 13일 이후 생성된 개인 개발자 계정을 대상으로 설명합니다. 본인 계정의 Play Console 안내가 우선이에요. 조건이 궁금하면 커뮤니티 글이나 지난 경험담 대신 Play Console에 로그인해 본인 계정에 뜨는 안내를 확인하는 게 가장 정확합니다. 시점에 따라 오래된 정보가 섞여 있을 수 있어요.

데이리플은 두 플랫폼에서 현재 같은 기능인가요?

공식 App Store 설명은 iPhone과 Android가 달라도 함께 쓸 수 있다고 안내합니다. 다만 모든 세부 화면이 완전히 같다는 뜻은 아니에요. 설치하려는 각 스토어의 현재 버전 설명과 실제 왕복을 확인하는 것이 가장 정확합니다.