App Store Connect Missing Compliance: Exportangaben 2026

Symptom: Der Build wurde erfolgreich hochgeladen, aber TestFlight zeigt „Missing Compliance“ und lässt die Verteilung nicht wie erwartet fortsetzen.

Schnellste Lösung: Prüfen Sie zuerst die Verschlüsselungsquellen des vollständigen App-Bundles. Nur Apple-Systemfunktionen wie bestimmte HTTPS- und Keychain-Nutzungen führen typischerweise zu einer einfachen Ausnahme; externe Standardalgorithmen oder eigene Kryptografie müssen Sie im App-Store-Connect-Fragebogen gesondert bewerten und gegebenenfalls mit Unterlagen belegen. Erst danach setzen Sie ITSAppUsesNonExemptEncryption im finalen Build korrekt.

Dieser Leitfaden richtet sich an Sie, wenn Sie einen iOS- oder macOS-Build nach dem Upload nicht an TestFlight-Tester verteilen können, obwohl Signatur und Upload erfolgreich waren. Er ist besonders relevant für unabhängige Entwickler und kleine Teams mit Login-, Zahlungs- oder Ende-zu-Ende-Verschlüsselungsfunktionen sowie für Teams, die regelmäßig über einen Remote Mac oder eine CI/CD-Umgebung veröffentlichen.

SECTION 01Was bedeutet „Missing Compliance“ tatsächlich?

„Missing Compliance“ bedeutet, dass dem hochgeladenen Build die erforderlichen Angaben zur Exportkonformität fehlen. Das ist eine andere Fehlerklasse als ein ungültiges Binärpaket, eine fehlgeschlagene Signatur oder ein Build, der lediglich noch verarbeitet wird. Apple führt diese Zustände getrennt; die jeweilige Bedeutung ist in der Übersicht der App-Store-Connect-Build-Status beschrieben.

Der entscheidende Prüfgegenstand ist nicht nur Ihr Swift- oder Objective-C-Quellcode. Bewertet wird die tatsächlich hochgeladene App einschließlich:

• eigener Verschlüsselungslogik,
• Aufrufen von Apple-Systemframeworks,
• statisch oder dynamisch eingebundenen Bibliotheken,
• Login-, Zahlungs- und Analyse-SDKs,
• aktivierten Sicherheitsfunktionen innerhalb dieser SDKs,
• weiterer Binärdateien und Ressourcen im finalen Archive.

Eine App kann daher im Geschäftsablauf scheinbar nur „Anmeldung“ anbieten, während ein eingebettetes SDK trotzdem kryptografische Funktionen bereitstellt. Umgekehrt bedeutet die Verwendung von HTTPS nicht automatisch, dass Sie formale Exportdokumente hochladen müssen. Die Apple-Übersicht zur Exportkonformität beschreibt den vorgesehenen Prüf- und Zuordnungsweg.

Die drei möglichen Routen

Ordnen Sie Ihren Build nach der Abhängigkeitsprüfung einer dieser Routen zu:

1. Keine zusätzlichen Unterlagen: Die App nutzt ausschließlich einschlägige, bereits durch Apple bereitgestellte Systemfunktionen und fällt nach Ihrer Prüfung unter eine Ausnahme.
2. Weitere Bewertung erforderlich: Ein SDK oder eine Bibliothek enthält Standardverschlüsselung, aber die konkrete Nutzung, Aktivierung oder Verteilung ist noch nicht ausreichend dokumentiert.
3. Unterlagen oder formale Klassifizierung erforderlich: Die App verwendet eigene Protokolle, nicht standardisierte Algorithmen oder stellt Sicherheits- beziehungsweise Verschlüsselungsfunktionen als Hauptleistung bereit.

Diese Einteilung ist eine technische Entscheidungshilfe, keine Rechtsberatung für alle Länder, Geschäftsmodelle oder Vertriebswege. Die Apple-Dokumentation zu Verschlüsselungs-Exportregeln weist ausdrücklich auf die Notwendigkeit hin, die konkrete Implementierung und die jeweils relevanten Vorschriften zu prüfen.

SECTION 02Erste Szene: HTTPS, Keychain und Apple-Systemfunktionen

Ein gewöhnlicher Netzwerkdienst kann HTTPS über Apple-Systemframeworks verwenden, ohne dass Sie deshalb automatisch eine umfangreiche eigene Kryptografie-Dokumentation einreichen müssen. Gleiches gilt häufig für die Nutzung von Keychain oder anderen vom Betriebssystem bereitgestellten Sicherheitsfunktionen. Die richtige Schlussfolgerung lautet aber nicht „Die App verwendet keine Verschlüsselung“.

Die belastbare Frage ist vielmehr: Verwendet die App ausschließlich die vom Betriebssystem bereitgestellten Fähigkeiten, oder bringt sie zusätzliche Verschlüsselung mit?

Identifikationsbelege

Legen Sie für die interne Prüfung eine kleine Abhängigkeitsliste an. Sie sollte mindestens enthalten:

• verwendete Netzwerkframeworks und deren Rolle,
• Keychain- oder andere Sicherheits-APIs,
• jede eingebundene Binärbibliothek,
• SDK-Version und Herstellerdokumentation,
• aktivierte Sicherheitsmodule,
• tatsächliche App-Funktionen, die Verschlüsselung auslösen,
• Zielregionen und geplante Vertriebswege.

Prüfen Sie nicht nur die sichtbaren Abhängigkeiten Ihrer Paketverwaltung. Ein vorkompiliertes Framework kann zusätzliche Komponenten enthalten, die im Quellcode nicht erkennbar sind. Sichern Sie deshalb die technische Beschreibung des Anbieters, die verwendete SDK-Version und einen Screenshot oder Export der beantworteten App-Store-Connect-Fragen als interne Nachweise.

Deklarationsschluss

Wenn Ihre Prüfung ausschließlich Apple-Systemfunktionen ergibt und die konkrete App unter eine passende Ausnahme fällt, beantworten Sie die Abfrage entsprechend dem Apple-Fragebogen. Sie müssen dann nicht vorsorglich komplexe Exportdateien hochladen. Dokumentieren Sie aber, warum Sie diese Einordnung getroffen haben.

Vermeiden Sie zwei typische Fehlentscheidungen:

• HTTPS pauschal als nicht relevante Verschlüsselung zu behandeln;
• wegen HTTPS pauschal eine nicht ausgenommene Verschlüsselung zu erklären.

Beides ignoriert die tatsächliche Zusammensetzung des Builds. Die Apple-Referenz für ITSAppUsesNonExemptEncryption ist für die technische Konfiguration maßgeblich, ersetzt aber nicht die Prüfung der eingebetteten Komponenten.

SECTION 03Zweite Szene: Standardalgorithmen in Drittanbieter-SDKs

Ein SDK für Anmeldung, Zahlungen, sichere Speicherung oder Kommunikation kann Standardalgorithmen selbst mitbringen. Dass Ihr eigener Code keinen AES-, RSA- oder anderen Algorithmus direkt aufruft, reicht dann nicht als Begründung für eine automatische Ausnahme. Maßgeblich ist, was im ausgelieferten Produkt enthalten und tatsächlich aktiviert ist.

Welche Unterlagen Sie anfordern sollten

Fordern Sie vom SDK-Anbieter eine technische Aussage zu folgenden Punkten an:

• verwendete Algorithmen und Protokolle,
• statische oder dynamische Einbindung,
• Zweck der Verschlüsselung,
• optionale und standardmäßig aktive Funktionen,
• betroffene Plattformen,
• Zielregionen und Einschränkungen der Verteilung,
• vorhandene Klassifizierungs- oder Exportdokumente.

Vergleichen Sie diese Angaben mit dem finalen Archive. Eine Dokumentation für eine ältere SDK-Version ist nicht automatisch ein Nachweis für die aktuell ausgelieferte Binärdatei. Ebenso genügt es nicht, nur den Namen eines SDKs zu betrachten: Ein Zahlungs-SDK kann Verschlüsselung für den Transport nutzen, zusätzlich aber sichere lokale Speicherung oder Geräteschutz aktivieren.

Deklarationsschluss

Wenn die Bibliothek Standardverschlüsselung enthält, beantworten Sie die Fragen in App Store Connect anhand der Gesamtfunktion und der vorliegenden Herstellerangaben. Können Sie die Ausnahme nicht sicher begründen, wechseln Sie nicht einfach auf „keine nicht ausgenommene Verschlüsselung“, nur damit der Build weiterläuft.

Für die Vereinigten Staaten können je nach Sachverhalt die offiziellen BIS-Informationen zu Verschlüsselungsfragen relevant sein. Bei einer Verteilung in Frankreich sollten Sie zusätzlich die Hinweise der zuständigen französischen Stelle zur regulatorischen Kontrolle kryptografischer Mittel prüfen. Diese Quellen geben einen regulatorischen Rahmen; sie sind keine pauschale Freigabe für Ihr konkretes SDK.

Vor- und Nachteile dieser Route

Vorteile einer dokumentierten SDK-Prüfung:

• Sie können die Antwort bei späteren Rückfragen nachvollziehbar begründen.
• Wiederholte Uploads lassen sich anhand derselben Abhängigkeitsliste bewerten.
• Ein Wechsel der SDK-Version löst eine klar definierte erneute Prüfung aus.

Nachteile einer oberflächlichen Prüfung:

• Ein neues SDK kann die Verschlüsselungseigenschaften des Builds verändern.
• Eine lokale Projektangabe kann von der finalen Binärdatei abweichen.
• Falsche Antworten verschieben das Problem nur vom Upload zur späteren Prüfung.

SECTION 04Dritte Szene: Eigene Protokolle und Sicherheitsprodukte

Eine strengere Behandlung ist angebracht, wenn Sie ein eigenes Verschlüsselungsprotokoll, einen nicht als Standard anerkannten Algorithmus oder eine App mit Sicherheitsfunktionen als Hauptzweck ausliefern. Dazu zählen beispielsweise Produkte, deren Kernleistung sichere Kommunikation, verschlüsselte Datenspeicherung oder ein eigener Schutzmechanismus ist.

In diesem Fall sollten Sie nicht versuchen, die Abfrage durch eine Änderung der Info.plist zu umgehen. Die Einstellung beschreibt eine technische Eigenschaft des Builds; sie macht eine möglicherweise erforderliche regulatorische Einstufung nicht überflüssig.

Drei Dokumente, drei unterschiedliche Aufgaben

Verwechseln Sie die folgenden Dinge nicht:

• CCATS oder eine andere formale Klassifizierung: Sie dient der regulatorischen Einordnung eines Verschlüsselungsprodukts nach den jeweils geltenden Vorgaben.
• Französische Erklärung oder Meldung: Sie betrifft eine mögliche nationale Anforderung bei der Verteilung in Frankreich und ist nicht automatisch mit einer US-Klassifizierung gleichzusetzen.
• Codeprüfung durch Apple: Sie betrifft die Prüfung des eingereichten App-Codes und beantwortet nicht automatisch die exportrechtliche Einordnung.

Welche Unterlage tatsächlich erforderlich ist, hängt von Implementierung, Funktionsumfang, Zielregion und Vertriebsmodell ab. Bei einem eigenen Protokoll oder einem Produkt mit zentraler Sicherheitsfunktion sollten Sie vor der Veröffentlichung eine fachkundige Beratung mit Erfahrung im Exportkontrollrecht einbeziehen.

SECTION 05Vierte Szene: TestFlight-Fragebogen und Info.plist zusammenführen

Nachdem Sie die Verschlüsselungsquelle geklärt haben, öffnen Sie in App Store Connect die Details des betroffenen Builds. Dort können Sie die Export-Compliance-Informationen bereitstellen, die Fragen beantworten oder bereits genehmigte Unterlagen mit dem Build verknüpfen. Die Apple-Anleitung für Beta-Builds in TestFlight beschreibt diesen Ablauf.

Ein Fragebogenabschluss in der Benutzeroberfläche und eine Konfiguration im Build sind jedoch nicht dasselbe. Sie müssen beide Ebenen kontrollieren:

1. Ermitteln Sie die Verschlüsselungsquellen des vollständigen App-Bundles.
2. Beantworten Sie die Fragen für den konkreten Build.
3. Verknüpfen Sie vorhandene Genehmigungen oder reichen Sie geforderte Unterlagen ein.
4. Prüfen Sie, ob ITSAppUsesNonExemptEncryption zur tatsächlichen Einordnung passt.
5. Erstellen Sie ein neues Archive, wenn Sie die Projektkonfiguration geändert haben.
6. Laden Sie das neue Archive mit einer neuen Build-Nummer hoch.
7. Warten Sie die Verarbeitung ab und kontrollieren Sie anschließend TestFlight.

Bedeutung von YES, NO und fehlender Konfiguration

ITSAppUsesNonExemptEncryption auf NO bedeutet nicht „Die App nutzt keinerlei Verschlüsselung“. Es bedeutet, dass die enthaltene Verschlüsselung nach Ihrer Einordnung nicht als nicht ausgenommene Verschlüsselung behandelt wird. Diese Aussage muss zum finalen Bundle passen.

YES signalisiert die gegenteilige technische Einordnung und kann eine weitergehende Abfrage oder die Zuordnung von Unterlagen auslösen. Ein fehlender Schlüssel lässt die Information offen; er ist kein zuverlässiger Ersatz für eine bewusste Entscheidung.

Wenn Apple Ihnen einen Genehmigungscode oder eine vergleichbare Referenz bereitstellt, kann ITSEncryptionExportComplianceCode für die Zuordnung relevant sein. Verwenden Sie einen solchen Wert nur nach den konkreten Apple-Anweisungen und behandeln Sie ihn wie ein vertrauliches Veröffentlichungs- oder Zugangselement.

Warum eine Änderung oft scheinbar wirkungslos bleibt

Kontrollieren Sie die Info.plist im finalen Archive, nicht nur die Build Settings oder eine Quelldatei im Projekt. Typische Ursachen für eine weiterhin erscheinende Abfrage sind:

• ein altes Archive wurde erneut hochgeladen,
• die Build-Nummer wurde nicht geändert,
• eine Release-Konfiguration nutzt andere Einstellungen,
• ein SDK oder Build-Skript überschreibt den Schlüssel,
• der Upload stammt aus einer anderen CI/CD-Umgebung,
• die App-Store-Connect-Antwort wurde noch nicht dem neuen Build zugeordnet.

Die Apple-Dokumentation zum Hochladen von Builds sollte dabei als Referenz für den Uploadablauf dienen. Entscheidend ist die Kette aus Archive, Upload, Verarbeitung, Compliance-Antwort und TestFlight-Verfügbarkeit.

SECTION 06FAQ: Häufige Blockaden nach dem Upload

Kann der Build trotz „Missing Compliance“ installiert werden?

Behandeln Sie den Status als offene Compliance-Aufgabe und nicht als verlässlichen Nachweis einer verfügbaren TestFlight-Verteilung. Öffnen Sie die Exportangaben, beantworten Sie den Fragebogen oder verknüpfen Sie die erforderlichen Unterlagen. Prüfen Sie danach den konkreten Build-Status erneut. Eine lokale Installation oder ein früherer Build beweist nicht, dass der aktuelle Upload freigegeben ist.

Wie beantworten Sie die Abfrage bei HTTPS und Keychain?

Prüfen Sie zuerst, ob ausschließlich Apple-Systemfunktionen verwendet werden. Dokumentieren Sie zusätzlich jede externe Bibliothek und jedes SDK. Wenn keine zusätzliche Kryptografie eingebettet ist und die konkrete Nutzung unter eine Ausnahme fällt, beantworten Sie die Fragen entsprechend. Wählen Sie nicht pauschal „keine Verschlüsselung“, denn HTTPS und Keychain sind weiterhin kryptografische Funktionen.

Wann ist ITSAppUsesNonExemptEncryption auf NO richtig?

NO ist nur dann sinnvoll, wenn die vollständige App nach Ihrer Prüfung ausschließlich in den relevanten Ausnahmebereich fällt. Enthält ein SDK eigene, nicht ausgenommene Kryptografie, kann NO falsch sein. Prüfen Sie deshalb das Archive und nicht nur die sichtbaren Quellcode-Abhängigkeiten. Bei einer unklaren SDK-Lage sollten Sie die Antwort erst nach technischer Klärung festlegen.

Was ist bei Login- und Zahlungs-SDKs zu belegen?

Lassen Sie sich vom Anbieter Algorithmen, Protokolle, Binärbestandteile, aktivierte Funktionen und die betroffene SDK-Version bestätigen. Ordnen Sie diese Angaben anschließend der Gesamt-App und den Zielregionen zu. Der Begriff „Login-SDK“ oder „Zahlungs-SDK“ entscheidet nicht allein über eine Ausnahme. Bei formaler Unsicherheit benötigen Sie möglicherweise eine regulatorische Klassifizierung oder fachkundige Beratung.

Weshalb reicht die Info.plist-Änderung nicht?

Die Änderung wirkt erst in einem neu erzeugten und hochgeladenen Build. Prüfen Sie die Datei im finalen Archive, erhöhen Sie die Build-Nummer und archivieren Sie erneut. Wenn ein Build-Skript, eine Release-Konfiguration oder ein SDK den Schlüssel verändert, muss auch diese Ursache korrigiert werden. Danach vergleichen Sie den neuen TestFlight-Status mit der beantworteten Compliance-Abfrage.

SECTION 07Fünfte Szene: Die Prüfung in eine Remote-Mac-Veröffentlichung einbauen

Wenn Sie über einen Remote Mac oder eine CI/CD-Pipeline veröffentlichen, darf die Compliance-Prüfung nicht auf einem persönlichen Rechner stattfinden und anschließend nur mündlich dokumentiert werden. Sie benötigen einen reproduzierbaren Kontrollpunkt vor dem Upload.

Eine belastbare, projektinterne Abnahme umfasst mindestens:

1. Abhängigkeiten erfassen: Vergleichen Sie die aktuelle SDK- und Bibliotheksliste mit der letzten freigegebenen Version.
2. Archive untersuchen: Öffnen Sie das tatsächlich erzeugte Archive und prüfen Sie die enthaltene Info.plist.
3. Antwort zuordnen: Dokumentieren Sie, welche App-Store-Connect-Antwort zu welchem Build gehört.
4. Upload protokollieren: Speichern Sie den relevanten Upload- und Verarbeitungsstatus, jedoch nur in bereinigter Form.
5. TestFlight prüfen: Kontrollieren Sie, ob die Compliance-Aufgabe abgeschlossen und der erwartete Verteilungsstatus erreicht ist.
6. Wiederholbarkeit testen: Führen Sie nach einer relevanten SDK-, Build- oder Konfigurationsänderung denselben Kontrollpfad erneut aus.

Die drei möglichen Abschlussentscheidungen lauten:

• Manuelle Fragebogenbearbeitung genügt: Die finale App fällt nach dokumentierter Prüfung in einen Ausnahmebereich, benötigt aber noch die Antwort in App Store Connect.
• Build-Konfiguration verhindert wiederholte Abfragen: Die Antwort ist geklärt und die finale Info.plist enthält die passende Einstellung.
• Materialprüfung abwarten: Die App benötigt Unterlagen, eine Genehmigung oder eine formale Einstufung; ein Konfigurationsschlüssel darf diese Prüfung nicht ersetzen.

Veröffentlichen Sie in Logs oder Screenshots niemals Zugangsdaten, Bundle-IDs, API-Schlüssel, Genehmigungscodes oder private SDK-Namen. Ersetzen Sie diese Werte vor der Weitergabe durch neutrale Platzhalter. Das gilt besonders für gemeinsam genutzte Remote-Mac-Sitzungen und CI/CD-Artefakte.

Für die technische Umgebung können Sie bei Bedarf die Remote-Mac-Angebote von MACNOX mit Ihrem eigenen Archivierungs- und Prüfprozess abgleichen. Wenn Sie eine temporäre Veröffentlichungsumgebung benötigen, finden Sie die verfügbaren MACNOX-Bestelloptionen. Die Mietumgebung ersetzt jedoch nicht Ihre Compliance-Entscheidung: Sie bleiben für Abhängigkeiten, Antworten, Unterlagen und den finalen Build verantwortlich.

SECTION 08Entscheidungstabelle für den nächsten Upload

Wenn Sie heute einen Build mit „Missing Compliance“ sehen, beginnen Sie nicht mit einer zufälligen Änderung der Info.plist. Ermitteln Sie zuerst, welche Verschlüsselung im vollständigen Bundle steckt, und trennen Sie Systemfunktionen, Drittanbieter-Implementierungen und eigene Kryptografie. Erst danach entscheiden Sie über Fragebogen, Unterlagen und Build-Konfiguration.

Für wiederkehrende Veröffentlichungen ist die bessere Lösung ein kontrollierter Remote-Mac-Ablauf: ein bereinigtes Archive, eine nachvollziehbare Abhängigkeitsliste, ein dokumentierter Upload und ein abschließender TestFlight-Status. Mit MACNOX können Sie dafür eine zeitweise oder regelmäßig verfügbare macOS-Umgebung einsetzen; prüfen müssen Sie trotzdem selbst, ob Compliance-Antworten, Signaturmaterial und automatisierte Veröffentlichung in Ihrem konkreten Projekt reproduzierbar zusammenpassen.

SECTION 09Weiterlesen

• iOS-Export mit Godot: Voraussetzungen für Build, Simulator und Signierung
• CI-Abnahme für iOS-Builds: Archiv, Signierung und Upload zuverlässig prüfen