App Store Connect에서 PrivacyInfo.xcprivacy가 유효하지 않다고 알리고, 제출한 빌드의 처리가 멈췄습니다.
가장 빠른 해결은 알림의 파일 경로를 먼저 확인한 뒤 앱 타깃, Swift Package, 서드파티 SDK 중 실제 소유 위치에서 수정하고 새로 아카이브해 검증하는 것입니다. 파일을 무작정 지우거나 앱의 매니페스트로 덮어쓰지 마세요.
이 글은 무효 알림을 받고 문제가 된 파일을 찾아야 하는 독립 개발자와 소규모 팀을 위한 안내입니다.
서드파티 SDK를 추가하거나 업데이트한 뒤 매니페스트가 아카이브에 들어갔는지 확인하려는 경우에도 참고할 수 있습니다.
원격 Mac에서 Xcode 아카이브를 만들고 제출 전 검증까지 재현하려는 개발자에게도 유용합니다.
먼저 오류 경로로 매니페스트의 주인을 가리세요
Apple의 알림은 파일 이름과 아카이브 내 경로를 제공할 수 있습니다. 그 경로를 기준으로 파일이 앱 번들에 있는지, 프레임워크나 SDK 번들 안에 있는지 확인하세요. 로컬 프로젝트에 같은 이름의 파일이 있다는 사실만으로 제출 파일에도 포함됐다고 단정할 수는 없습니다. Apple의 TN3181 무효 개인정보 매니페스트 진단 문서는 알림의 경로를 따라 아카이브 안의 문제 파일을 찾도록 안내합니다.
| 알림에서 확인한 위치 | 우선 확인할 대상 | 수정할 곳 |
|---|---|---|
| 앱 번들 안의 PrivacyInfo.xcprivacy | 앱 타깃과 빌드 리소스 | 앱 프로젝트의 타깃 및 매니페스트 내용 |
| Swift Package의 리소스 경로 | 패키지 타깃의 리소스 선언 | 패키지 manifest와 리소스 설정 |
| 프레임워크 또는 XCFramework 경로 | 포함된 SDK와 버전 | SDK 배포자가 제공한 매니페스트 또는 SDK 버전 |
앱 자체가 사용하는 required reason API와 데이터 수집 선언은 같은 의미가 아닙니다. 또한 앱의 매니페스트가 있다고 해서 SDK 안에 필요한 매니페스트가 대신 생기지는 않습니다. Apple은 앱과 서드파티 SDK의 매니페스트 추가 방법을 개인정보 매니페스트 구성 안내에서 구분합니다.
앱 타깃에 추가한 파일이 실제 앱 번들에 있는지 확인하세요
프로젝트에 파일을 보이게 추가했더라도 빌드 대상에 포함되지 않았다면 아카이브에 들어가지 않을 수 있습니다. Xcode에서 PrivacyInfo.xcprivacy의 타깃 소속과 빌드에 포함되는 리소스 구성을 확인하세요. 이어서 현재 제출에 사용할 아카이브 안에 파일이 실제로 들어 있는지 대조합니다.
Apple의 개인정보 매니페스트 파일 배치 안내를 기준으로 앱 번들과 SDK 번들의 위치를 따로 살펴보세요. 프로젝트 탐색기에 보이는 경로와 최종 아카이브의 경로는 서로 다를 수 있습니다. 제출 알림이 가리키는 파일과 로컬 원본이 같은 파일인지도 확인해야 합니다.
앱의 매니페스트는 앱이 사용하는 항목을 선언합니다. SDK가 자체적으로 제공해야 할 내용을 앱 매니페스트에 임의로 옮기면, 파일 소유 관계와 실제 사용을 잘못 나타낼 수 있습니다.
Swift Package의 매니페스트가 아카이브에 빠졌다면
Swift Package 저장소에 PrivacyInfo.xcprivacy가 있어도 패키지 빌드 결과에 자동으로 포함된다고 볼 수는 없습니다. 패키지 타깃의 리소스로 선언했는지 확인하고, 빌드된 앱 아카이브에서 패키지에 해당하는 파일이 포함됐는지 검사하세요. Apple의 Swift Package 리소스 번들링 설명은 패키지 리소스를 타깃에 선언하는 방법을 다룹니다.
다음 순서로 확인하면 원인을 좁힐 수 있습니다.
- 패키지 소스에 매니페스트가 있는지 확인합니다.
- 해당 패키지 타깃이 매니페스트를 리소스로 선언하는지 확인합니다.
- 앱이 실제로 사용하는 패키지와 타깃이 맞는지 살펴봅니다.
- 새로 만든 아카이브 안에서 파일의 포함 여부와 위치를 확인합니다.
- 파일이 빠졌다면 패키지 리소스 선언을 수정한 뒤 앱을 다시 빌드합니다.
패키지 소스의 파일만 수정하고 앱 프로젝트에 남아 있는 이전 아카이브를 제출하면 변경 사항이 반영되지 않습니다. 수정한 빌드가 아카이브에 반영됐는지 마지막에 다시 확인하세요.
서드파티 SDK 경로라면 앱이 아니라 SDK를 추적하세요
알림의 경로가 SDK, 프레임워크 또는 XCFramework 내부를 가리킨다면 먼저 프로젝트의 의존성 목록에서 해당 구성 요소와 버전을 찾으세요. 이 경우 앱 자체의 매니페스트를 고치는 것만으로 SDK의 무효 파일이 해결되지는 않습니다.
| 확인 항목 | 판단 기준 | 다음 조치 |
|---|---|---|
| 오류 경로 | 어느 프레임워크나 SDK 내부인지 | 의존성 이름과 연결 |
| 의존성 버전 | 프로젝트가 실제로 빌드한 버전인지 | 버전 기록 및 잠금 파일 확인 |
| SDK 제공 파일 | 배포자가 제공한 매니페스트인지 | 배포 자료와 수정 안내 확인 |
| 아카이브 결과 | 업데이트 후 오류 경로가 바뀌었는지 | 새 아카이브에서 재검사 |
배포자가 제공한 새 버전이나 수정 안내가 있는지 확인하세요. 문제가 계속되면 오류 경로와 SDK 버전을 함께 정리해 배포자에게 문의하는 편이 안전합니다. SDK의 매니페스트를 직접 편집하거나 제거하면 업데이트 때 수정이 사라질 수 있고, 서명된 구성 요소를 바꾸는 과정에서 서명 검증 문제가 생길 수도 있습니다. Apple의 코드 서명 관련 기술 안내를 확인하고, 수정이 필요하면 배포자가 권장하는 방법을 우선하세요.
매니페스트가 있는데도 거부된다면 키와 값을 검토하세요
파일이 존재하고 아카이브에도 포함됐는데 무효 알림이 계속되면 구조와 값을 확인하세요. Apple의 TN3181 문제 해결 안내에 따라 오류가 지목한 항목을 원본 매니페스트와 대조합니다. 허용되지 않은 키나 값, 잘못된 구조가 있는지 살펴보고, 다른 종류의 선언을 한 항목으로 혼합하지 마세요.
required reason API 선언은 실제 앱이나 SDK에서 사용하는 API에 맞춰 작성해야 합니다. 허용되는 API와 사유 값은 Apple의 required reason API 문서에서 확인하세요. 확인되지 않은 이유를 추측해 넣는 방식은 피해야 합니다.
데이터 수집에 관한 선언은 별도로 검토합니다. 매니페스트의 데이터 사용 설명과 required reason API 선언은 목적이 다르므로, 한쪽의 값을 다른 쪽에 복사해 문제를 해결하려 하지 마세요. 데이터 사용 항목은 Apple의 개인정보 매니페스트 데이터 사용 설명과 실제 앱 동작을 함께 확인해야 합니다.
오류 메시지에 파일 경로가 있다면 그 파일을 먼저 조사하세요. 앱의 매니페스트를 고치는 것만으로 SDK 내부 파일의 오류가 해결된다고 가정하지 마세요.
Xcode Archive에서 수정 결과를 다시 검증하세요
수정한 소스 파일이 맞더라도 이전 Archive를 다시 제출하면 오류가 반복될 수 있습니다. 다음 순서로 제출할 빌드를 확인하세요.
- [ ] App Store Connect 알림에서 파일 이름과 아카이브 경로를 기록합니다.
- [ ] 경로와 의존성 정보를 대조해 앱, Swift Package, SDK 중 소유 위치를 정합니다.
- [ ] 원본 프로젝트나 의존성의 올바른 위치에서 매니페스트를 수정합니다.
- [ ] Xcode에서 수정 사항을 반영해 새 Archive를 만듭니다.
- [ ] Organizer에서 제출할 Archive를 선택하고 내부 파일이 수정됐는지 확인합니다.
- [ ] Xcode의 배포 및 제출 흐름에서 새 Archive를 선택해 제출 전 검증을 진행합니다.
- [ ] 검증 결과와 수정한 파일 경로, 의존성 버전을 기록합니다.
Apple의 Xcode에서 앱을 배포하는 안내는 Organizer를 통한 아카이브 확인과 배포 절차를 설명합니다. 로컬 원본이 아니라 이번 제출에 선택한 Archive를 기준으로 검증하세요.
아카이브 내부 파일을 직접 바꾸거나 제거하는 방식은 기본 해결책으로 삼지 않는 편이 좋습니다. 패키지나 프레임워크의 서명에 영향을 줄 수 있기 때문입니다. 예외적으로 아카이브 내용을 변경해야 한다면 Apple의 코드 서명 안내와 해당 구성 요소의 재서명 요건을 먼저 확인하고, 가능하면 원본 프로젝트나 SDK 배포 단계에서 수정한 뒤 다시 아카이브하세요.
제출을 미루지 않도록 기록을 남기고 환경을 고르세요
수정 기록에는 알림의 파일 경로, 문제가 된 매니페스트의 소유자, 앱 또는 SDK 버전, 변경한 항목, 새 Archive의 검증 결과를 포함하세요. 이 기록이 있으면 같은 오류가 다시 생겼을 때 이전 빌드와 새 빌드의 차이를 확인하기 쉽습니다. 한 프로젝트에서 해결됐다는 사실만으로 다른 앱이나 SDK에서도 같은 수정이 통한다고 판단해서는 안 됩니다.
현재 로컬 Mac에서만 제출을 처리한다면 저장 공간을 다른 작업과 나눠 써야 하고, 장비가 꺼져 있거나 다른 사람이 사용 중일 때 빌드와 검증을 이어가기 어렵습니다. 별도 Mac을 구매하면 초기 장비 비용과 유지 관리가 생깁니다. 반대로 원격 Mac은 사용 중인 Xcode와 프로젝트 의존성이 작업에 맞는지, 필요한 접근 권한과 파일 전달 방식이 있는지 먼저 확인해야 합니다.
정기적으로 같은 프로젝트를 빌드하고 물리적 장비 접근이 필요하다면 직접 보유한 Mac이 적합할 수 있습니다. 제출 전 아카이브 검증이나 일시적인 빌드 환경이 필요하고 사용하지 않을 때 장비를 유지하고 싶지 않다면 원격 Mac을 비교해 볼 수 있습니다. Xcode 실행, 새 Archive 생성, 제출 전 검증을 원격으로 이어갈 환경이 필요할 때는 OsxNode의 한국어 원격 Mac 안내에서 이용 조건을 확인하세요. 미리 설정과 작업 흐름을 살펴보려면 문서 안내도 참고할 수 있습니다.