App-Store-Connect-Fehler
ITMS-91053 ist kein Urteil von App Review. App Store Connect teilt dir damit mit, dass nativer Code in deinem Build eine API nutzt, die Apple in einem Privacy Manifest (PrivacyInfo.xcprivacy) erklärt haben will. Die Lösung ist eine kleine Property List mit ehrlichen Reason Codes oder eine neuere SDK-Version; an deiner Web-App ändert sich gar nichts.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Apple führt eine Liste von "Required Reason APIs": Systemaufrufe, die für normale App-Funktionen nützlich sind, sich aber auch missbrauchen ließen, um ein Gerät per Fingerprinting wiederzuerkennen. Es gibt fünf Kategorien: Datei-Zeitstempel, Systemstartzeit, Speicherplatz, aktive Tastaturen und User Defaults. Jede App und jedes SDK, das sie nutzt, muss in einem Privacy Manifest angeben, warum, und dafür aus einer festen Liste genehmigter Gründe wählen.
Die E-Mail nennt zwei Dinge: die Datei, deren Code die API nutzt (die Haupt-Executable deiner App oder ein Framework im Ordner Frameworks), und die API-Kategorien, geschrieben wie NSPrivacyAccessedAPICategoryUserDefaults. Anfang 2024 waren diese E-Mails noch Erinnerungen; laut Apples Dokumentation zu Required Reason APIs werden Uploads ohne die Deklarationen seit dem 1. Mai 2024 nicht mehr angenommen. Deshalb nennen alte Forenthreads es "nur eine Warnung", und bei dir ist es keine.
Eine Web-Wrapper-App löst den Fehler über die native Hülle aus, nie über dein JavaScript. Jede iOS-App speichert Einstellungen in den User Defaults, legt Dateien im Cache ab und misst Zeit, und die SDKs für Push, Werbung und Analytics tun dasselbe. Typische Momente, in denen er auftaucht: Du hast ein SDK hinzugefügt, du hast Cursor oder Claude Code eigenen Swift-Code schreiben lassen, oder du hast ein älteres Projekt mit einem aktuellen Xcode neu gebaut.
| Code | Was App Store Connect sagt (sinngemäß) | Lösung |
|---|---|---|
| ITMS-91053 Missing API declaration | Code in der genannten Datei nutzt eine Required Reason API, und kein Privacy Manifest in diesem Bundle deklariert einen Grund dafür. | Ergänze die Kategorie und einen genehmigten Grund im Manifest des Bundles, das den Code enthält. Ist die Datei ein Framework eines Drittanbieters, aktualisiere stattdessen das SDK. |
| ITMS-91061 Missing privacy manifest | Ein SDK aus Apples Liste häufig genutzter SDKs steckt ohne eigenes Privacy Manifest im Build. | Aktualisiere dieses SDK auf eine Version, die ein Manifest mitliefert. Auf der Liste stehen neben vielen anderen Firebase-Komponenten, OneSignal und die Frameworks des Facebook SDK. |
| ITMS-91065 Missing signature | Ein gelistetes SDK ist als Binär-Abhängigkeit ohne die Code-Signatur des Herstellers eingebunden. | Nutze das signierte Release des Herstellers. Bearbeite keine Dateien innerhalb eines Frameworks; das zerstört die Signatur. |
| ITMS-91056 Invalid privacy manifest | Es gibt eine PrivacyInfo.xcprivacy, aber sie enthält einen falschen Schlüssel, einen falschen Wert oder eine falsche Struktur. | Öffne sie im Property-List-Editor von Xcode, vergleiche die Schlüssel mit dem Beispiel unten und entferne Tippfehler oder erfundene Reason Codes. |
Wähle nur Gründe, die beschreiben, was der Code wirklich tut. Apples Liste der Gründe knüpft an jeden davon Bedingungen, zum Beispiel dass die Daten das Gerät nie verlassen.
| Kategorie in der E-Mail | Genehmigte Gründe (Apple) | Übliche Wahl für eine WebViewGold-App |
|---|---|---|
NSPrivacyAccessedAPICategoryUserDefaults | CA92.1 Daten, die nur diese App liest und schreibt; 1C8F.1 innerhalb deiner App Group geteilt; C56D.1 SDK-Wrapper (nur für SDKs); AC6B.1 verwaltete Konfiguration per MDM | CA92.1. Ergänze 1C8F.1 nur, wenn die App über eine App Group Einstellungen mit einer Extension teilt (Push Service Extension, Widget, Share Extension). |
NSPrivacyAccessedAPICategoryFileTimestamp | C617.1 Dateien im Container der App oder der App Group; DDA9.1 Zeitstempel, die dem Nutzer angezeigt werden; 3B52.1 Dateien, die der Nutzer ausgewählt hat; 0A2A.1 SDK-Wrapper (nur für SDKs) | C617.1 für Caches und heruntergeladene Dateien im App-Container. 3B52.1 nur, wenn der Code Metadaten von Dateien liest, die der Nutzer ausgewählt hat. |
NSPrivacyAccessedAPICategorySystemBootTime | 35F9.1 verstrichene Zeit zwischen Ereignissen und Timern in der App; 8FFB.1 absolute Zeitstempel von Ereignissen in der App; 3D61.1 optionaler Fehlerbericht | 35F9.1, der Normalfall für Timer, Timeouts und Ladezeitmessungen. |
NSPrivacyAccessedAPICategoryDiskSpace | E174.1 Speicherplatz vor dem Schreiben von Dateien prüfen, mit sichtbarem Verhalten; 85F4.1 Speicherplatz dem Nutzer anzeigen; 7D9E.1 optionaler Fehlerbericht; B728.1 Apps für Gesundheitsforschung | E174.1 nur, wenn die App vor dem Speichern von Downloads wirklich den freien Speicher prüft. Kannst du nicht sagen, warum, finde erst heraus, welcher Code die API nutzt, bevor du irgendetwas deklarierst. |
NSPrivacyAccessedAPICategoryActiveKeyboards | 3EC4.1 Apps mit eigener Tastatur; 54BD.1 an die aktive Tastatur angepasste Oberfläche | Selten in einer WebView-App. Wird dein eigenes Target genannt, such nach eigenem Swift-Code, den ein KI-Agent ergänzt hat. |
Mit einer gut optimierten Version Ihrer Web-App können Sie innerhalb von wenigen Minuten eine beeindruckende mobile App erstellen. Zusätzlich dazu ist der Kundenservice sehr nett und hilfsbereit! Ich kann WebViewGold nur empfehlen :-)
Zwanzig Minuten in Xcode, dann eine neue Build-Nummer.
Ist es die Executable deiner App (der Name deiner .app), gehört die Deklaration in das Manifest des App-Targets. Ist es ein Pfad wie Frameworks/SomeSDK.framework, muss das SDK die API in seinem eigenen Manifest deklarieren, und deine Datei kann das nicht beheben.
Updates sind kostenlos. Ist dein Projekt alt, lade die aktuelle Version herunter, übertrage deine Werte aus Config.swift, die Texte aus Info.plist, Icons und Splash und prüfe, ob der Fehler bleibt, bevor du irgendetwas von Hand bearbeitest. Neuere Releases können neuere SDK-Versionen enthalten; wenn du unsicher bist, frag den WebViewGold-Support, welche Version du brauchst.
Suche im Project Navigator nach PrivacyInfo.xcprivacy. Hat das App-Target schon eine, erweitere sie; füge demselben Target nie ein zweites Manifest hinzu. Gibt es keine, wähle File, New, File from Template, nimm App Privacy, behalte den Namen PrivacyInfo und setze den Haken beim Haupt-Target der App.
Lege unter NSPrivacyAccessedAPITypes einen Eintrag an, mit NSPrivacyAccessedAPIType auf die Kategorie aus der E-Mail gesetzt und NSPrivacyAccessedAPITypeReasons mit den Reason Codes, die für deine App zutreffen. Das Beispiel unten zeigt den Aufbau.
Apple erwartet ein Manifest in jedem Bundle, dessen Executable die API nutzt. Nennt die E-Mail eine Extension (Notification Service Extension, Widget, Share Extension oder App Clip), bekommt dieses Target ein eigenes Manifest mit den passenden Gründen.
Archiviere, klicke dann im Organizer bei gedrückter Ctrl-Taste auf das Archiv und wähle Generate Privacy Report: Xcode fasst alle Manifeste in einem PDF zusammen, und du siehst deine Kategorien aufgelistet. Erhöhe die Build-Nummer, lade hoch und warte auf die Verarbeitungs-E-Mail, bevor du einreichst.
Zwei häufige Kategorien als Beispiel. Nutze nur die Kategorien, die deine E-Mail nennt, und die Gründe, die zu deiner App passen; behalte alle anderen Schlüssel, die schon in deiner Datei stehen.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<!-- Vorhandene Schlüssel wie NSPrivacyTracking oder NSPrivacyCollectedDataTypes bleiben unverändert -->
<key>NSPrivacyAccessedAPITypes</key>
<array>
<dict>
<key>NSPrivacyAccessedAPIType</key>
<string>NSPrivacyAccessedAPICategoryUserDefaults</string>
<key>NSPrivacyAccessedAPITypeReasons</key>
<array>
<string>CA92.1</string>
</array>
</dict>
<dict>
<key>NSPrivacyAccessedAPIType</key>
<string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
<key>NSPrivacyAccessedAPITypeReasons</key>
<array>
<string>C617.1</string>
</array>
</dict>
</array>
</dict>
</plist>NSPrivacyTracking gehört zum selben Thema wie App Tracking Transparency. Wenn du personalisierte AdMob-Werbung zeigst, lies den ATT-Guide für Web-Apps mit Werbung, bevor du den Schlüssel setzt.Füge die vollständige ITMS-E-Mail an der markierten Stelle ein. Prüfe den Diff, bevor du baust; der Agent darf keine Reason Codes erfinden. Mehr zu Agenten-Setups: das WebViewGold-Projekt mit Claude Code einrichten.
App Store Connect hat meinen Upload mit der E-Mail unten abgelehnt. Behebe das in diesem WebViewGold-iOS-Projekt. 1. Sag mir für jeden ITMS-91053-Eintrag, welche Datei er nennt und ob diese Datei mein App-Target, eine meiner Extensions oder ein Framework eines Drittanbieters ist. 2. Für meine eigenen Targets: Suche eine vorhandene PrivacyInfo.xcprivacy (lege keine zweite pro Target an). Gibt es keine, lege eine an, die nur zu diesem Target gehört. 3. Ergänze pro Kategorie aus der E-Mail ein NSPrivacyAccessedAPITypes-Dictionary. Wähle Gründe nur aus dieser Liste und begründe jede Wahl in einem Satz: UserDefaults CA92.1, 1C8F.1 (nur wenn eine App Group genutzt wird); FileTimestamp C617.1, DDA9.1, 3B52.1; SystemBootTime 35F9.1, 8FFB.1, 3D61.1; DiskSpace E174.1, 85F4.1, 7D9E.1; ActiveKeyboards 3EC4.1, 54BD.1. Wenn du keinen Code findest, der einen Grund rechtfertigt, hör auf und frag mich. 4. Frameworks von Drittanbietern: Fass sie nicht an. Nenne mir das SDK und seine Version in diesem Projekt und sag mir, mit welchem Update es ein eigenes Privacy Manifest mitbringt. 5. Ändere weder Config.swift noch die Purpose Strings in Info.plist noch irgendeine andere Datei. E-Mail: [hier die vollständige ITMS-E-Mail einfügen]
Nein. Es ist eine automatische Prüfung bei der Verarbeitung des Builds, bevor ein Mensch die App ansieht. Der Build wird nicht angenommen, App Review bekommt ihn also nie zu sehen; sobald ein korrigierter Build sauber hochgeladen ist, reichst du wie gewohnt ein.
Nein. Jeder Grund ist eine Aussage darüber, wie dein Code die API und die Daten nutzt, und manche Gründe sind SDKs oder bestimmten App-Typen wie der Gesundheitsforschung vorbehalten. Deklariere, was zutrifft, und nichts darüber hinaus.
Nein. Deine Web-App läuft in WebKit, Apples System-Framework. Das Manifest betrifft den nativen Code in deiner Binary und die SDKs, die du mit ihr auslieferst.
In diesem Setup bearbeitest du kein Xcode-Projekt. Schick den vollständigen Text der E-Mail an den WebViewGold-Support, damit die Build-Konfiguration geprüft werden kann, und ändere nichts an deiner Web-App; das Manifest ist Teil des nativen Builds.
Ja. Das Manifest liegt im App-Bundle, es erreicht Apple also nur mit einem neuen Upload. Erhöhe die Build-Nummer, archiviere und lade erneut hoch.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.