TestFlight 앱은 개발용 APNs와 운영 APNs 중 어디로 보내야 하나요?

TestFlight는 베타 테스트용 배포이므로 푸시 제공 서버는 운영 APNs 환경을 사용해야 합니다. 개발 환경 토큰을 운영 서버에 보내거나 반대로 설정하면 요청이 거부될 수 있습니다. 다만 환경만 맞추면 해결된다고 단정하지 말고, Archive의 APS Environment 값과 서버가 실제 선택한 연결 환경을 함께 확인하세요. Apple 문서는 사전 출시 버전과 베타 테스트에 운영 환경을 사용한다고 설명합니다.

기기 토큰을 받았는데도 푸시가 도착하지 않는 이유는 무엇인가요?

토큰을 받았다는 사실은 앱이 APNs 등록 절차를 진행했다는 뜻이지, 서버 전송이나 기기 표시까지 성공했다는 뜻은 아닙니다. 토큰이 서버에 저장됐는지, 해당 앱과 기기의 최신 토큰인지, 요청에 맞는 운영 환경과 인증 정보가 사용됐는지 따로 확인하세요. 서버 응답의 거부 사유와 요청 식별 정보를 보존하면 실패 지점을 좁히기 쉽습니다.

Archive에 푸시 알림 권한이 들어 있는지 어떻게 확인하나요?

먼저 Xcode의 서명된 Archive에서 실제 앱을 내보내고, 최종 앱의 entitlements를 확인하세요. 프로젝트 설정 화면에 Push Notifications가 켜져 있어도 최종 산출물의 Bundle ID, 서명 설정, Provisioning Profile이 달라지면 기대한 권한이 포함되지 않을 수 있습니다. 로컬 빌드와 원격 빌드의 값을 나란히 비교하고, 로그나 화면을 공유할 때 Team ID와 Bundle ID는 가리세요.

서버 요청은 성공했는데 iPhone에 알림이 보이지 않으면 무엇을 확인하나요?

서버가 요청을 보냈거나 APNs가 요청을 받아들였다는 결과만으로 화면 표시까지 보장되지는 않습니다. 같은 기기와 같은 빌드에서 앱이 앞에 있을 때와 백그라운드에 있을 때를 비교하고, 앱의 알림 처리 코드와 앞쪽 화면에서 표시를 결정하는 로직을 확인하세요. 기기 설정과 알림 권한도 살펴보되, 먼저 서버 응답과 앱 수신 기록을 분리해 기록해야 전송 실패와 표시 문제를 혼동하지 않습니다.

TestFlight 푸시가 오지 않을 때? 2026 APNs 점검

TestFlight로 iOS 앱을 시험하는데 푸시가 도착하지 않는 개발자를 위한 점검 안내입니다. 운영 APNs 환경부터 서명된 앱 권한, 토큰 전달, 서버 응답과 화면 표시까지 시나리오별로 나눠 확인합니다. 비교표와 점검 순서를 따라 등록·전송·수신·표시 중 막힌 단계를 구분할 수 있습니다.

Apple은 사전 출시 버전과 베타 테스트에서 운영 APNs 환경을 사용한다고 안내합니다(APS Environment 설명). 따라서 TestFlight 푸시가 오지 않으면 인증서를 다시 만들기 전에 최종 서명 산출물의 푸시 권한과 기기 토큰을 확인하고, 서버가 운영 APNs에 보낸 요청의 응답을 살펴보세요.

이번 주에는 빌드 권한 확인, 토큰 전달 점검, 서버 응답 확인, 기기 표시 확인 순으로 진행하세요. 테스트 빌드가 안 된다는 이유만으로 재업로드를 반복하면 원인을 찾기 어렵습니다.

이 글은 TestFlight로 푸시를 시험하는 독립 개발자와 소규모 팀을 위한 점검 안내입니다.
Xcode에서 Push Notifications를 켰지만 최종 Archive의 권한이 확실하지 않은 경우에도 해당합니다.
원격 Mac에서 빌드를 반복하며 서명과 푸시를 함께 확인해야 하는 팀도 활용할 수 있습니다.

TestFlight APNs 푸시가 오지 않을 때는 실패 단계를 먼저 나눕니다

푸시 문제는 등록, 토큰 전달, APNs 요청, 기기 수신, 화면 표시 중 어느 단계에서 막혔는지에 따라 조치가 다릅니다. 앱이 토큰을 받았다고 서버 전송까지 성공한 것은 아니며, 서버가 요청을 보냈다고 iOS가 알림을 화면에 표시한 것도 아닙니다. Apple의 APNs 등록 안내는 앱이 원격 알림 등록을 요청하고 받은 토큰을 제공자 서버에 안전하게 전달하는 흐름을 설명합니다.

등록 콜백이 오지 않으면 앱의 등록 요청과 권한 처리를 확인하세요. 토큰이 앱에서 확인되지만 서버에 없다면 클라이언트의 전송과 서버 저장 로직이 우선 점검 대상입니다. 서버에는 토큰 일부만 남기고 요청 시각, 빌드 식별 정보, 응답 상태를 함께 기록하면 민감한 값을 노출하지 않고 비교할 수 있습니다.

최종 Archive에서 서명 권한과 환경을 대조합니다

Xcode 프로젝트에서 기능을 켰는지가 아니라, 실제 배포하려는 Archive에 어떤 권한이 서명됐는지가 기준입니다. Apple의 Xcode 기능 설정 문서는 기능과 앱의 서명 설정을 다룹니다. 최종 앱의 entitlements에서 aps-environment 값이 기대한 환경인지 확인하고, Bundle ID와 프로비저닝 설정도 같은 산출물 기준으로 비교하세요.

아카이브가 로컬과 원격 Mac에서 각각 만들어졌다면 두 결과를 대조합니다. 설정 화면이 같아 보여도 빌드 구성, 서명 대상, 프로비저닝 프로파일이 달라질 수 있습니다. 원격 빌드에서는 생성된 앱과 서명 정보를 확인하고, 인증 키나 계정 정보는 터미널 기록과 공유 로그에 남기지 마세요.

첫 번째 시나리오: 토큰을 받았지만 서버 전송이 거부됩니다

이 경우에는 기기 등록을 반복하기보다 서버가 어느 APNs 환경에 연결하는지, 인증 자격 정보가 대상 앱과 맞는지, 요청에 어떤 토큰을 넣었는지 확인합니다. 토큰은 영구 주소처럼 취급하면 안 됩니다. 앱에서 새 토큰을 받을 때 서버 기록도 갱신하고, 서로 다른 앱의 토큰이 섞이지 않도록 앱 식별 정보와 함께 관리하세요.

Apple의 APNs 응답 처리 안내를 참고해 응답의 실패 원인을 요청 로그와 연결합니다. 요청 본문 전체나 토큰을 그대로 남기는 대신, 토큰은 일부만 마스킹하고 요청 식별 정보와 응답 사유를 보존하세요. Apple의 푸시 상태 지표 안내도 서버 기록과 함께 확인할 자료가 될 수 있습니다.

앞에서 실행 중인 앱에서만 알림이 보이지 않습니다

APNs 요청이 받아들여졌는지와 iOS가 현재 앱 상태에서 알림을 표시하는지는 다른 확인 항목입니다. 동일한 기기와 동일한 빌드에서 앱이 앞에 있을 때와 백그라운드에 있을 때를 비교하고, 앱이 알림을 받은 뒤 어떤 처리를 하는지 확인하세요. 앞쪽 화면에서 표시 방식을 정하는 코드가 알림을 가릴 수도 있습니다.

Apple의 알림 처리 문서는 앱이 알림을 처리하는 흐름을 설명합니다. 전송 성공 로그만 보고 기기 표시까지 성공했다고 판단하지 마세요. 필요하면 Apple의 푸시 알림 콘솔 안내로 테스트를 분리하되, 앱에서 받은 기록과 화면 표시 결과를 별도로 남기세요.

원격 Mac에서 빌드한 뒤에만 실패하면 산출물을 비교합니다

Mac은 Xcode로 앱을 빌드하고 서명하는 역할을 합니다. APNs와 연결해 푸시 요청을 보내는 일은 앱의 푸시 제공 서버가 담당하므로, 빌드 머신을 바꿨다는 사실만으로 서버 인증 문제가 해결되지는 않습니다. 로컬과 원격 Archive에서 Bundle ID, 서명 설정, 프로비저닝 프로파일, 최종 entitlements를 비교해 차이가 있는지 찾으세요.

반복해서 같은 설정으로 빌드해야 하거나 로컬 저장 공간과 서명 환경을 분리하고 싶다면 원격 Mac 환경 선택지를 살펴볼 수 있습니다. 서울에서 개발 서버에 접속하는 조건이 중요하다면 서울 원격 Mac 안내도 비교 대상입니다. 다만 현재 문제가 APNs 서버의 인증이나 기기 토큰 매핑에 있다면 빌드 환경을 바꾸는 것만으로 해결되지 않습니다.

증거를 남기는 비교표와 최종 판정

아래 점수는 통계나 측정 결과가 아니라, 어떤 확인부터 시작할지 정하기 위한 진단 우선순위입니다. 가장 높은 점수의 단계부터 관련 기록을 대조하고, 이상이 없으면 다음 단계로 이동하세요.

관찰된 상황	우선 확인할 기록	점검 우선도
앱에서 토큰이 확인되지 않음	등록 요청, 콜백, 최종 앱 권한	5/5
앱에는 토큰이 있지만 서버에 없음	클라이언트 전송, 서버 저장 및 갱신 기록	5/5
서버 요청이 거부됨	운영 APNs 환경, 인증 정보, 응답 사유	5/5
일부 기기에서만 실패함	각 기기의 최신 토큰과 앱 연결 정보	4/5
앞에서 실행할 때만 알림이 안 보임	앱 수신 처리와 앞쪽 표시 결정	4/5

원격 빌드가 의심되면 아래 항목을 로컬 산출물과 나란히 비교합니다. 값이 다르면 그 차이를 고친 뒤 같은 흐름으로 다시 검증하세요.

비교 항목	확인할 내용	문제가 있을 때
앱 식별 정보	Bundle ID와 서버에 저장된 앱 연결 정보	다른 앱 토큰 혼용 여부 확인
서명 산출물	Archive의 entitlements와 `aps-environment`	기능 설정과 서명 결과를 다시 대조
APNs 요청	서버가 선택한 환경과 인증 정보	대상 앱 및 환경에 맞게 수정
기기 기록	최신 토큰, 수신 시각, 표시 상태	토큰 갱신과 앱 처리 흐름 확인

수정 후에는 빌드 식별 정보, 토큰 갱신 여부, 서버 요청 결과, 기기 수신 및 표시 상태를 하나의 탈취 없는 기록으로 연결하세요. 토큰 전체와 서명 키, 계정 정보, 기기 식별 정보는 기록과 공유 자료에서 가립니다. 한 기기에서 성공했더라도 다른 기기나 빌드까지 통과했다고 확대 해석하지 말고, 등록·전송·수신·표시를 각각 확인해야 합니다.

마무리 점검

TestFlight 푸시 문제는 운영 APNs 환경만 확인해서 끝나지 않습니다. 최종 서명 권한, 최신 기기 토큰의 서버 반영, APNs 응답, iOS의 수신과 표시를 분리해야 재작업을 줄일 수 있습니다. 서명 산출물 차이가 원인으로 확인됐다면 원격 Mac에서 Xcode Archive를 반복 검증하는 방법을 고려할 수 있습니다. 반대로 지속적인 고정 부하나 물리 기기 연결이 필수라면 원격 환경이 항상 적합한 것은 아니므로, 필요한 테스트 조건부터 정한 뒤 VPSMAC의 원격 Mac 이용 방식을 비교하세요.