Mac 개발자가 읽은 Apple의 새 App Review Help 문서

짧은 답

2026년 11월 Hello Developer 공지에서 Apple은 새로운 App Review 도움말 문서를 안내했어요. 대부분 리젝트를 겪으며 배운 내용을 글로 적어 둔 거예요. Apple은 제출된 앱의 50%를 24시간 이내에, 90%를 48 이내에 심사하는 것을 목표로 해요. 데모 로그인은 심사가 시작될 때도 작동해야 해요. 질문에 답하려고 다시 제출하지 말고 App Store Connect에서 답장해야 해요. "Bug Fix Submissions:"로 시작하는 리젝트는 수정 사항을 배포하고 문제는 다음에 처리할 수 있어요. 스크린샷의 절반 넘게는 앱을 사용하는 모습을 보여 줘야 해요. 그리고 모든 권한에는 각각 명확한 purpose string이 필요해요. Mac을 직접 언급한 문서는 하나뿐이지만, 모든 규칙이 Mac App Store 제출에 적용돼요.

App Review에 대해 제가 아는 건 대부분 리젝트 메일에서 배웠어요. 그래서 Apple의 2026년 11월 Hello Developer에서 "Browse new App Review help articles"라고 했을 때 전부 읽었어요. 이제 한곳에 모여 있는 App Review Help에는, 예전엔 떠도는 이야기였던 것들이 많이 명확하게 적혀 있어요.

Mac 앱에 중요한 내용과, 다음 제출 전에 제가 바꿀 것들을 정리했어요.

먼저, 누구를 위한 글인지

App Review는 App Store Connect를 거치는 것만 봐요. Mac App Store, TestFlight, In-App Purchases 같은 것들이에요. Developer ID로 내 사이트에서 Mac 앱을 직접 판매한다면 Apple에서 아무도 심사하지 않아요. 대신 자동 검사인 공증을 거쳐요. 그러니 직접 배포만 한다면 가볍게 훑어보고, Mac App Store 버전을 추가하는 날을 위해 저장해 두세요.

심사에 걸리는 시간

심사 상태 문서에는 Apple 자신의 목표가 나와 있어요. 제출된 앱의 50% 이상을 24시간 미만에, 90%를 48시간 미만에 심사한다는 거예요. 심사가 더 느려지는 이유도 적혀 있는데, 심사 이력이 적은 경우, Apple이 필요로 하는 서류, 복잡하거나 새로운 문제 같은 것들이에요.

제가 한다면 이렇게 해요. 출시일 전에 이틀의 여유를 두고 계획하세요. 첫 앱이라면 더 넉넉하게요. 그리고 일찍 제출하고 수동 출시로 설정해서, 공개되는 시각을 직접 고르세요.

심사는 Notes 항목에서 결정돼요

완전한 심사 문서는 단호해요. "불완전한 제출은 리젝트됩니다." 중요한 내용은 이래요.

데모 로그인은 제출할 때뿐 아니라 심사가 시작될 때도 작동해야 해요. 그 사이에 만료되거나 바뀌는 테스트 계정은 리젝트로 이어질 수 있어요.
로그인에 코드가 필요하면 Notes에 적으세요. 없으면 Apple이 전화를 해야 할 수 있고, 통화는 보통 영업일 기준 3~5일 안에 이루어져요. 그러면 일주일이 훌쩍 지나가요.
구독 앱에는 구독이 만료된 데모 계정이 필요해요. 심사자가 구매 과정 전체를 볼 수 있도록요.

제가 한다면 이렇게 해요. Notes 항목을 처음 보는 사람을 위한 짧은 사용 설명서처럼 쓰세요. 어디를 먼저 클릭하는지, 어떤 계정을 쓰는지, 앱에 창이 없다면 메뉴 막대 아이콘이 무엇을 하는지요. 마지막 항목은 정말 Mac다운 부분이에요.

리젝트됐을 때

몇 년 전에 글로 있었으면 좋았을 부분이에요.

질문에 답하려고 다시 제출하지 마세요. App Review가 정보를 요청하면 App Store Connect에서 답장하세요. 빌드를 수정해야 할 때만, 그리고 지적받은 문제를 모두 고친 뒤에만 다시 제출하세요.
맨 위에 "Bug Fix Submissions:"가 있는지 보세요. 리젝트가 그 문구로 시작하면 Bug Fix Submissions 문서에 따라 답장으로 수락하고 문제는 다음 업데이트에서 처리할 수 있어요. 다시 제출하지 마세요. 전에 승인된 적이 있는 앱에만 해당하고, 법적 문제나 안전 문제에는 쓸 수 없으며, 같은 문제를 두 번 미룰 수도 없어요.
신속 심사는 정말 필요할 때만. Apple은 신속 심사 요청이 "진짜 급한 경우에만 사용해야" 하며, 이미 심사에 보낸 빌드에만 가능하다고 말해요. 행사에 맞춘 출시라면 행사 이름과 날짜를 Notes에 적으세요.
이의 신청은 마지막에. 먼저 리젝트에 답장해서 설명하세요. 그래도 해결되지 않으면 App Review Board가 앱당 한 번 이의 신청을 받아요. 다시 제출하고 나면 그 리젝트에 대해서는 이의 신청을 할 수 없어요.

번호가 붙은 네 가지 규칙

가이드라인 문서는 짧고 구체적이에요.

스크린샷, 2.3.3. 스크린샷의 절반 넘게는 앱을 사용하는 모습을 보여 줘야 하고, 기기 종류별로 세요. 스크린샷이 세 장이면 두 장은 앱 화면이어야 해요. 스플래시 화면이나 타이틀 카드는 소수라면 괜찮아요. MacPip의 스크린샷 검사기가 크기를 확인해 주고, 나머지는 직접 세면 돼요.
모방 앱, 4.1. 어떤 메타데이터 항목에도 인기 앱 이름이나 상표 용어를 넣으면 안 돼요. 키워드도 포함이고, 경쟁 앱 이름을 넣는 게 흔한 실수예요. App Store 키워드 검사기가 각 항목의 글자 수를 세어 주니 무엇이 들어 있는지 볼 수 있어요.
purpose string, 5.1.1(ii). 보호된 리소스마다 각각 명확한 purpose string이 있어야 하고, 앱이 현지화되어 있다면 purpose string도 현지화해야 해요. Apple이 직접 든 나쁜 예는 "To use location."이에요. SDK가 요청하는 내용도 내 책임이에요. Info.plist를 Info.plist 해설 도구에 붙여 넣으면 비어 있거나 모호한 항목을 짚어 줘요.
계정 삭제, 5.1.1(v). 앱에서 계정을 만들 수 있다면 앱 안에서 삭제를 시작할 수 있어야 해요. 비활성화만으로는 부족하고, 전화하라고 할 수도 없어요. 구독 중이라면 취소할 때까지 Apple을 통해 결제가 계속된다고 알려 주세요.

Mac에 대한 한 줄

Mac을 언급하는 건 호환 기기 문서뿐이에요. 호환되는 iPhone 및 iPad 앱은 Apple silicon이 탑재된 Mac에서 수정 없이 실행될 수 있고, 키보드로는 할 수 없는 터치 조작에 의존하는 앱은 macOS에 잘 맞지 않는다고 해요. iPad 앱을 만든다면 Mac App Store에 노출되고 있는지 확인하고, 키보드와 트랙패드로 잘 쓸 수 없다면 노출을 끄세요. 같은 페이지에는 TestFlight가 내부 테스터 최대 100명과 외부 테스터 최대 10,000명을 받을 수 있고, 외부 테스터에게 처음 주는 빌드도 App Review를 거친다고 적혀 있어요.

What's New도 심사 대상이에요

새 문서가 아니라 가이드라인에서 하나 더 있어요. Guideline 2.3.12는 What's New 문구에 새 기능과 변경 사항을 적어야 하고, 단순한 버그 수정과 성능 개선만 일반적인 한 줄로 넘어갈 수 있다고 해요. 새 기능이 있는 릴리스에 "Bug fixes and improvements"라고 쓰면 질문을 불러와요.

그래서 오늘의 새 무료 도구는 릴리스 노트 포매터예요. 대충 쓴 메모나 git log --oneline 줄을 붙여 넣으세요. 새 기능, 개선, 수정으로 나누고, chore, ci, merge 줄은 빼고, 티켓 번호와 파일 이름에 표시를 하고, 4,000자 제한을 확인한 다음 세 가지 사본을 만들어 줘요. App Store Connect용 일반 텍스트, Sparkle appcast용 HTML, GitHub용 Markdown이에요. 메모는 브라우저 안에만 있어요. 이 내용이 들어가는 피드는 옆에 있는 Sparkle appcast 검사기로 확인할 수 있어요.

제 짧은 목록

출시일까지 이틀의 여유, 그리고 수동 출시.
처음 보는 사람도 따라 할 수 있는 Notes 항목과 작동하는 데모 계정.
질문만 받았다면 다시 제출하지 말고 답장하기.
스크린샷을 세어 보고, purpose string을 하나하나 읽고, 키워드에 다른 앱 이름을 넣지 않기.
무엇이 바뀌었는지 알려 주는 What's New.

그리고 앱이 나오면 Mac App Store에 있든 없든 MacPip에 등록하는 건 무료예요. 등록된 앱은 제출될 때 자동으로 스캔되고, 파란 체크는 사람이 어느 날짜에 앱을 직접 써 봤다는 뜻일 뿐이에요.

출처

계속 읽기

앱 제출하기 메이커를 위한 무료 도구

Apple이 App Review 방식을 글로 적었어요. 제출하기 전에 제가 바꿀 것들을 정리했어요