심사자에겐 피아노가 없다
LevelUp Piano의 딜레마는 분명했습니다. 핵심 경험은 외부 USB-MIDI 피아노를 연결해 연주하는 것인데, 심사자에게는 그 피아노가 없습니다. 하드웨어가 없으면 앱의 절반은 검증할 수 없습니다.
이 앱을 심사에 올리며 배운 것들을 정리합니다. 특별한 편법이 아니라, "검증할 수 있게 준비해 두기" 라는 원칙의 반복이었습니다.
LevelUp Piano는 지금 App Store에 올라가 있습니다. 한 번에 통과한 건 아니고, 반려됐던 항목(구독 법적 링크·계정 삭제·현지화)을 갖춰 재제출한 뒤 승인됐습니다.
배움 1 — 하드웨어 앱은 데모 영상이 필요하다
리뷰어가 하드웨어를 가질 수 없다면, 실물로 도는 장면을 영상으로 보여줘야 합니다. 물리 아이패드에 MIDI 키보드를 연결하는 장면, 앱이 "연결됨"에 도달하는 장면, 건반을 눌렀을 때 앱이 실시간으로 반응하는 전 과정을 컷 없이 담았습니다. 시뮬레이터 흔적 없이, 실제 기기로.
배움 2 — 하드웨어가 없어도 둘러볼 길을 열어라
영상만으로는 부족합니다. 리뷰어가 직접 만져볼 수 있어야 합니다. 그래서 온보딩에 "아직 피아노가 없어요 — 나중에 연결하고 둘러보기" 버튼을 두었습니다. 키보드 없이도 화면 터치 건반으로 샘플 곡을 쳐보고 앱 곳곳을 둘러볼 수 있습니다 — 단, 이 모드는 점수·진급 미반영이라 실제 MIDI 연주와 구분됩니다(체험 전용). 리뷰어가 하드웨어 없이 핵심 화면에 닿는 유일한 경로라, 이 우회로가 심사 통과의 관건이었습니다.
배움 3 — 구독 화면엔 진짜 열리는 법적 링크가 필요하다
자동갱신 구독 앱은 구매 화면 안에 제목·기간·가격뿐 아니라 개인정보처리방침·이용약관으로 실제로 열리는 링크가 있어야 합니다. 설명 페이지에만 있으면 부족합니다. 링크가 죽어 있어도 안 됩니다 — "기능하는" 링크여야 합니다.
배움 4 — 계정을 만들면, 앱 안에서 지울 수 있어야 한다
로그인으로 계정을 만드는 앱은 앱 안에서 계정을 삭제할 수 있어야 합니다. 설정에 삭제 버튼을 두고, 로그인 방식(Sign in with Apple)에 맞춰 삭제 시 연결도 정리되도록 흐름을 갖췄습니다. 계정 생성과 삭제는 세트입니다.
배움 5 — 공용 데모 계정이 없다면, 접근법을 적어라
이 앱은 Sign in with Apple 만 씁니다. 즉 공용 아이디·비밀번호 데모 계정이 없습니다. 그래서 접근 경로를 심사 노트에 상세히 적었습니다. 리뷰어가 헤매지 않도록, 그가 밟을 길을 미리 깔아주는 것입니다. 노트에 넣은 경로는 대략 이런 식이었습니다:
- "Sign in with Apple"로 로그인 (리뷰어 본인 Apple ID, 아이디/비밀번호 칸은 비워둠)
- 역할 선택에서 학생 선택
- "피아노 없이 둘러보기"로 화면 건반 체험 → 온보딩·연습·결과 화면 확인
마인드셋: 리뷰어의 동선을 설계한다
이 과정에서 얻은 가장 큰 교훈은, 심사를 적대적 관문이 아니라 하나의 사용자 동선으로 봐야 한다는 것입니다. 리뷰어도 사용자입니다. 그가 무엇을 확인해야 하는지 알고, 그 길에 필요한 것(영상·둘러보기·링크·삭제·안내)을 미리 놓아두면, 심사는 마찰이 아니라 체크리스트가 됩니다.
리뷰어도 사용자다. 그가 무엇을 확인해야 하는지 알고 그 길에 필요한 걸 미리 놓아두면, 심사는 적대적 관문이 아니라 하나의 체크리스트가 된다.
실제로 갖춰야 했던 항목을 한 표로 정리하면:
| 항목 | 요구 | 어디에 |
|---|---|---|
| 데모 영상 | 실기기 연결·연주 전 과정, 컷 없이 | App Store Connect |
| 하드웨어 없는 둘러보기 | 터치 건반 체험(점수 미반영) | 온보딩 |
| 구독 법적 링크 (3.1.2c) | 구매 화면 안에서 열리는 약관·개인정보 | 구독 화면 |
| 계정 삭제 | 앱 내 삭제 + 로그인 연결 정리 | 설정 |
| 데모 접근 경로 | 로그인 → 역할 → 둘러보기 순서 | 심사 노트 |
마치며
하드웨어 의존 앱의 출시는 "기능을 잘 만들었다"로 끝나지 않았습니다. 검증 가능성 자체를 하나의 기능으로 다뤄야 했습니다. 영상으로 보여주고, 하드웨어 없이도 둘러보게 하고, 정책과 규칙(구독 링크·계정 삭제)을 지키고, 리뷰어의 동선을 적어두는 것 — 이 준비가 곧 좋은 사용자 경험과 겹친다는 점이 흥미로웠습니다.
The reviewer doesn't have a piano
LevelUp Piano's dilemma was clear. The core experience is connecting an external USB-MIDI piano and playing — but the reviewer doesn't have that piano. Without the hardware, half the app can't be verified.
Here's what I learned submitting this app. Not clever tricks, but the same principle over and over: make it verifiable.
LevelUp Piano is now on the App Store. It didn't pass in one shot — it was approved after resubmitting with the rejected items (subscription legal links, account deletion, localization) in place.
Lesson 1 — a hardware app needs a demo video
If the reviewer can't have the hardware, you have to show it working on video. Connecting a MIDI keyboard to a physical iPad, the app reaching "connected," and the whole flow of the app responding in real time when keys are pressed — captured without cuts, on a real device, no simulator traces.
Lesson 2 — open a path to look around without hardware
A video alone isn't enough; the reviewer needs to touch it. So onboarding has an "I don't have a piano yet — connect later and look around" button. Even without a keyboard they can play a sample song on the on-screen touch keyboard and browse the app — though this mode records no score or progression, keeping it distinct from real MIDI play (it's for trying, not grading). It's the only path for a reviewer to reach the core screens without hardware, so that one detour decided whether review passed.
Lesson 3 — the subscription screen needs legal links that actually open
An auto-renewable subscription app needs, inside the purchase screen, not just title, length, and price but links that actually open the Privacy Policy and Terms of Use. Having them only on the description page isn't enough. Dead links aren't allowed either — they must be functional.
Lesson 4 — if you create accounts, you must be able to delete them in-app
An app that creates accounts by sign-in must let users delete their account from within the app. We put a delete button in settings and built a flow that, matching the sign-in method (Sign in with Apple), also cleans up the link on deletion. Account creation and deletion are a set.
Lesson 5 — if there's no shared demo account, write down the access path
This app uses Sign in with Apple only — meaning there's no shared username/password demo account. So we wrote detailed access notes for the reviewer. You lay the path they'll walk, so they don't get lost. The notes ran roughly like this:
- Sign in with Apple (reviewer's own Apple ID; leave the username/password fields empty)
- Choose the Student role at role selection
- Tap "Look around without a piano" for the on-screen keyboard → check the onboarding, practice, and results screens
Mindset: design the reviewer's journey
The biggest takeaway was to see review not as a hostile gate but as one more user journey. The reviewer is a user too. Know what they need to verify, place what that path needs (video, a way to browse, links, deletion, notes) in advance, and review becomes a checklist rather than friction.
The reviewer is a user too. Know what they need to verify, place what that path needs in advance, and review stops being a hostile gate and becomes just a checklist.
The items I actually had to have, in one table:
| Item | Requirement | Where |
|---|---|---|
| Demo video | Full connect-and-play on a real device, no cuts | App Store Connect |
| No-hardware browse | Touch-keyboard trial (no score) | Onboarding |
| Subscription legal links (3.1.2c) | Terms & privacy that open inside the purchase screen | Subscription screen |
| Account deletion | In-app delete + sign-in link cleanup | Settings |
| Demo access path | Sign-in → role → browse, in order | Review notes |
Closing
Launching a hardware-dependent app didn't end at "the features are well built." Verifiability itself had to be treated as a feature. Show it on video, let people browse without hardware, honor the policies and rules (subscription links, account deletion), and write down the reviewer's path — and it was striking how much that preparation overlaps with a good user experience.