# ITMS-90683: „Missing purpose string“ mit Expo beheben

> ITMS-90683 Missing purpose string: warum Apple deinen Build ablehnt, welchen Key du in app.json ergänzt und wie du fehlende Keys vor dem Upload findest.

Originalseite: [ITMS-90683: „Missing purpose string“ mit Expo beheben](https://devoria.fr/de/blog/itms-90683-missing-purpose-string-expo)
Autor: [Mehdi Azizi](https://devoria.fr/de/mehdi-azizi)
Veröffentlicht: 2026-10-09
Letzte inhaltliche Überarbeitung: 2026-10-09


ITMS-90683 ist eine automatische Ablehnung durch Apple: Sie kommt kurz nach dem Upload deines Builds per E-Mail, noch vor jeder menschlichen Prüfung. Sie bedeutet, dass in deiner Info.plist der Satz fehlt, der erklärt, warum die App auf sensible Daten zugreift. **Die Lösung besteht aus zwei Schritten: den in der Meldung genannten Key in `ios.infoPlist` ergänzen und dann einen neuen Build erstellen.**

Mich hat es bei Solys erwischt, meinem Wecker mit Minispielen, und zwar wegen Daten, die die App nicht einmal nutzt. Hier erkläre ich, was die Meldung bedeutet, warum sie kommt und wie du sie vermeidest.

## Was bedeutet der Fehler ITMS-90683?

Die vollständige Meldung heißt „ITMS-90683: Missing purpose string in Info.plist“. Sie sagt, dass der Code deiner App eine API referenziert, die sensible Daten betrifft (Fotos, Kamera, Mikrofon, Standort, Kontakte), und dass deine Info.plist den passenden Beschreibungs-Key nicht enthält. Die Meldung nennt diesen Key, zum Beispiel `NSPhotoLibraryUsageDescription`.

Dieser Beschreibungssatz heißt „Purpose String“. Das ist der Text, den iOS im Dialog zur Berechtigungsanfrage anzeigt. Apple schreibt es in seiner Dokumentation zum [Zugriff auf geschützte Ressourcen](https://developer.apple.com/documentation/uikit/requesting-access-to-protected-resources): App Review lehnt Apps ab, deren Code ohne Purpose String auf diese Ressourcen zugreift.

Das ist keine Ablehnung durch einen Reviewer. Die Prüfung läuft automatisch bei der Auslieferung des Builds, vor der Einreichung zur Review, genau wie [ITMS-91053](https://devoria.fr/de/blog/itms-91053-missing-api-declaration-expo-beheben) beim Privacy Manifest. Der Build wird verworfen und du musst einen neuen hochladen.

## Warum Apple ablehnt, obwohl deine App diese Daten nicht nutzt

Das ist der Punkt, der überrascht. **Apple analysiert den Code in deinem Build, nicht das, was deine App tatsächlich tut.** Wenn eine eingebundene Library eine Referenz auf die Fotomediathek enthält, ist der Key Pflicht, selbst wenn kein einziger Screen je Zugriff auf Fotos anfragt. Apples Meldung sagt es selbst: Eine externe Library oder ein SDK kann diese APIs referenzieren, und der Purpose String bleibt trotzdem Pflicht.

Mein Fall, am 26. September 2026. Beim Aufräumen der Konfiguration von Solys hatte ich den Key `NSPhotoLibraryUsageDescription` entfernt, weil die App keine Fotos anfasst. Der nächste Build wurde mit ITMS-90683 abgelehnt. Die Ursache: Zwei Expo-Libraries, die die App nutzt, `expo-image` und `expo-file-system`, enthalten Code, der die Fotomediathek referenziert. Der vorherige Build ging durch, weil der Key noch da war.

**Die Lehre**: Einen Beschreibungs-Key entfernt man nicht, „weil man ihn nicht braucht“. Man entfernt ihn nur, wenn keine Library im Build die API mehr referenziert.

## Die häufigsten Keys

- `NSPhotoLibraryUsageDescription`: Fotos lesen oder schreiben.
- `NSPhotoLibraryAddUsageDescription`: Fotos hinzufügen, ohne Lesezugriff.
- `NSCameraUsageDescription`: Kamera.
- `NSMicrophoneUsageDescription`: Mikrofon.
- `NSLocationWhenInUseUsageDescription`: Standort während der Nutzung.
- `NSContactsUsageDescription`: Kontakte.
- `NSUserTrackingUsageDescription`: Werbe-Tracking ([App Tracking Transparency](https://devoria.fr/de/blog/guideline-5-1-2-drittanbieter-ki-att-datenweitergabe)).

Apple beschreibt jeden Key in seiner Dokumentation, zum Beispiel den für [NSPhotoLibraryUsageDescription](https://developer.apple.com/documentation/bundleresources/information-property-list/nsphotolibraryusagedescription): Er ist Pflicht, sobald die App eine API nutzt, die in der Fotomediathek liest oder schreibt.

## ITMS-90683 in einer Expo-App beheben

1. **Notiere dir den Key aus Apples E-Mail.** Die Meldung nennt seinen genauen Namen.
2. **Füge ihn in deiner Konfiguration hinzu**, unter `ios.infoPlist`, so wie es die [Expo-Dokumentation zu Berechtigungen](https://docs.expo.dev/guides/permissions/) beschreibt:

```json
{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSPhotoLibraryUsageDescription": "Solys greift nicht auf deine Fotos zu. Diese Berechtigung wird nie angefragt."
      }
    }
  }
}
```

3. **Erstelle einen neuen Build.** Expo weist darauf hin: Eine Änderung an der Info.plist geht nicht per Remote-Update, sie braucht ein neues Binary.
4. **Lade den Build** erneut bei Apple hoch und wähle ihn dann in deiner Version aus.

Eine Falle, wenn deine App übersetzt ist: Sprachdateien übersetzen einen Key, sie deklarieren ihn nicht. Der Key muss zuerst in `ios.infoPlist` existieren (oder in der Konfiguration des betreffenden Plugins). Sonst kann die App beim ersten Aufruf abstürzen.

## Welchen Satz schreibst du, wenn deine App die Daten nicht nutzt?

Apple verlangt eine korrekte, hilfreiche und präzise Beschreibung. Wenn deine App die Daten wirklich nutzt, sag in einem Satz, wofür: „Die App nutzt die Kamera, um den Barcode deines Tickets zu scannen.“

Wenn der Key nur wegen einer Library da ist, nennt Apple zwei Lösungen: den Satz schreiben oder den Code entfernen, der auf die Daten zugreift. Kommt dieser Code aus einer Library, kannst du ihn nicht einfach entfernen. Bei Solys habe ich also die Wahrheit geschrieben: „Solys greift nicht auf deine Fotos zu. Diese Berechtigung wird nie angefragt.“ Das ist eine pragmatische Entscheidung: Der nächste Build ging bei der Auslieferung durch, aber ich kann dir nicht versprechen, dass Apple diesen Satz immer akzeptiert.

## Fehlende Keys vor dem Upload finden

Vom Root deines Projekts aus listet dieser Befehl die Library-Dateien, deren iOS-Code die am stärksten überwachten APIs referenziert:

```bash
grep -rlE "PHPhotoLibrary|AVCaptureDevice|CLLocationManager|CNContactStore|EKEventStore|ATTrackingManager" \
  node_modules/*/ios node_modules/@*/*/ios
```

Jeder Name steht für eine Datenart: `PHPhotoLibrary` für Fotos, `AVCaptureDevice` für Kamera und Mikrofon, `CLLocationManager` für den Standort, `CNContactStore` für Kontakte, `EKEventStore` für den Kalender, `ATTrackingManager` für Tracking. Prüfe für jeden Treffer, ob der passende Beschreibungs-Key in deiner Konfiguration existiert.

Dieses Sicherheitsnetz fängt die Fälle ab, die mir begegnet sind. Es ersetzt nicht das Lesen von Apples E-Mail, die die einzige verlässliche Liste bleibt, genau wie bei den nicht öffentlichen APIs von ITMS-90338. Seit dieser Ablehnung läuft diese Prüfung vor jedem Build: Sie dauert ein paar Sekunden, während eine ITMS-90683-Ablehnung einen Build kostet und die Zeit, ihn neu zu erstellen.

## Deinen Build ohne böse Überraschung hochladen

ITMS-90683 ist schnell behoben, wenn man die Meldung zu lesen weiß, genau wie ITMS-90725, bei dem es um die Xcode-Version geht. Die Ablehnungen, die danach kommen, also die von einem Reviewer, brauchen mehr Abstand: Das Vorgehen steht auf der Seite [App von Apple abgelehnt](https://devoria.fr/de/expertise/app-von-apple-abgelehnt), und die häufigsten Gründe findest du unter [warum Apple eine App ablehnt](https://devoria.fr/de/blog/app-store-ablehnung-apple-gruende).

Um deine Einreichung vor dem Upload zu prüfen, bündelt das [Apple Review Kit](https://devoria.fr/de/kits/review-apple) meine Checkliste und Claude-Code-Skills, die dein Projekt durchgehen. Wenn dein Upload hängt und du einen menschlichen Blick willst, [buch eine Stunde mit mir](https://devoria.fr/de/coaching): Wir gehen dein Projekt per Videocall auf deinem Bildschirm durch. Und wenn du deinen ersten Release vorbereitest, [mach deine kostenlose Diagnose](https://devoria.fr/de/diagnostic): Sie bringt die Schritte in die richtige Reihenfolge und schickt dir meine Checkliste gegen Apple-Ablehnungen.

## Häufige Fragen

### Ist ITMS-90683 eine Ablehnung durch App Review?

Nicht im Sinne eines menschlichen Reviewers. Es ist eine automatische Prüfung des Builds bei der Auslieferung, vor der Einreichung zur Review, wie ITMS-90717 beim Icon. Niemand hat deine App geöffnet. Der Build wird verworfen: Du musst die Info.plist korrigieren und einen neuen hochladen.

### Warum verlangt Apple einen Key für Daten, die meine App nicht nutzt?

Weil Apple den Code im Build analysiert, nicht das Verhalten der App. Wenn eine eingebundene Library die Fotomediathek oder die Kamera referenziert, ist der Beschreibungs-Key Pflicht, selbst wenn kein Screen diesen Zugriff je anfragt.

### Kann man ITMS-90683 mit einem Remote-Update beheben?

Nein. Der fehlende Key steht in der Info.plist, die Teil des Binaries ist. Ein Remote-Update ändert diese Datei nicht: Du musst einen neuen Build erstellen und ihn erneut bei Apple hochladen.

### Wo füge ich NSPhotoLibraryUsageDescription in einem Expo-Projekt hinzu?

In deiner App-Konfiguration unter `ios.infoPlist`, mit einem Satz, der die Nutzung beschreibt. Manche Libraries bieten auch eine eigene Einstellung in ihrem Plugin, die weitere Keys hinzufügen kann, etwa einen Hintergrundmodus. In beiden Fällen muss der Key in der Basiskonfiguration existieren, nicht nur in den Übersetzungsdateien.

### Sollte man ungenutzte Beschreibungs-Keys entfernen?

Nur wenn keine Library im Build die betreffende API mehr referenziert. Sonst wird der nächste Upload mit ITMS-90683 abgelehnt. Bevor du einen Key entfernst, such den API-Namen im iOS-Code deiner Abhängigkeiten.


## Dein Projekt

[Apple Review Kit](https://devoria.fr/de/kits/review-apple): Meine Checkliste für die App-Store-Review, meine korrigierten Apple-Ablehnungen, Notizen für den Tester und zwei Claude-Code-Skills, die deine App prüfen. 29 €.

[iOS Kit](https://devoria.fr/de/kits/ios): Bau deine iPhone-App mit Claude Code: der Starter Code meiner Apps, Skills, die seine Arbeit prüfen, plus Apple Review Kit, App Store Screenshots Kit und ASO Kit. 129,99 €.