ITMS-90683: jak naprawić „Missing purpose string” w Expo

ITMS-90683 to automatyczne odrzucenie od Apple: przychodzi mailem chwilę po wysłaniu builda, zanim ktokolwiek go przejrzy. Oznacza, że w twoim pliku Info.plist brakuje zdania, które wyjaśnia, po co aplikacja sięga po wrażliwe dane. Naprawa to dwa kroki: dodajesz klucz wymieniony w wiadomości do ios.infoPlist, a potem robisz nowy build.

Dostałem ten błąd przy Solys, moim budziku z minigrami, i to z powodu danych, z których aplikacja w ogóle nie korzysta. Wyjaśniam, co znaczy ta wiadomość, skąd się bierze i jak jej uniknąć.

Co oznacza błąd ITMS-90683?

Pełna wiadomość ma tytuł „ITMS-90683: Missing purpose string in Info.plist”. Mówi, że kod twojej aplikacji odwołuje się do API, które dotyka wrażliwych danych (zdjęcia, aparat, mikrofon, lokalizacja, kontakty), a twój Info.plist nie zawiera odpowiedniego klucza z opisem. Wiadomość podaje nazwę tego klucza, na przykład NSPhotoLibraryUsageDescription.

To zdanie z opisem nazywa się „purpose string”. To tekst, który iOS pokazuje w oknie z prośbą o zgodę. Apple pisze o tym w dokumentacji o dostępie do chronionych zasobów: App Review odrzuca aplikacje, których kod sięga po te zasoby bez purpose string.

To nie jest odrzucenie przez recenzenta. Kontrola jest automatyczna i następuje przy dostarczeniu builda, przed rozpoczęciem przeglądu, tak jak ITMS-91053 przy manifeście prywatności. Build zostaje odrzucony i trzeba wysłać nowy.

Dlaczego Apple odrzuca, choć twoja aplikacja nie korzysta z tych danych

To jest najbardziej zaskakujące. Apple analizuje kod zawarty w twoim buildzie, a nie to, co aplikacja faktycznie robi. Jeśli dołączona biblioteka zawiera odwołanie do biblioteki zdjęć, klucz jest wymagany, nawet jeśli żaden ekran nigdy nie prosi o dostęp do zdjęć. Sama wiadomość od Apple to precyzuje: do tych API może odwoływać się zewnętrzna biblioteka lub SDK, a purpose string i tak jest obowiązkowy.

Mój przypadek, 26 września 2026. Porządkując konfigurację Solys, usunąłem klucz NSPhotoLibraryUsageDescription, bo aplikacja nie dotyka żadnych zdjęć. Kolejny build został odrzucony z ITMS-90683. Przyczyna: dwie biblioteki Expo, których używa aplikacja, expo-image i expo-file-system, zawierają kod odwołujący się do biblioteki zdjęć. Poprzedni build przechodził, bo klucz jeszcze tam był.

Lekcja: klucza z opisem nie usuwa się „bo z niego nie korzystam”. Usuwa się go dopiero wtedy, gdy żadna biblioteka w buildzie nie odwołuje się już do danego API.

Najczęstsze klucze

• NSPhotoLibraryUsageDescription: odczyt lub zapis zdjęć.
• NSPhotoLibraryAddUsageDescription: dodawanie zdjęć, bez odczytu.
• NSCameraUsageDescription: aparat.
• NSMicrophoneUsageDescription: mikrofon.
• NSLocationWhenInUseUsageDescription: lokalizacja podczas używania aplikacji.
• NSContactsUsageDescription: kontakty.
• NSUserTrackingUsageDescription: śledzenie reklamowe (App Tracking Transparency).

Apple opisuje każdy klucz w dokumentacji, na przykład NSPhotoLibraryUsageDescription: jest wymagany, gdy tylko aplikacja używa API, które czyta lub zapisuje w bibliotece zdjęć.

Jak naprawić ITMS-90683 w aplikacji Expo

1. Zanotuj klucz wymieniony w mailu od Apple. Wiadomość podaje jego dokładną nazwę.
2. Dodaj go do konfiguracji w ios.infoPlist, zgodnie z dokumentacją Expo o uprawnieniach:

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSPhotoLibraryUsageDescription": "Solys nie ma dostępu do twoich zdjęć. To uprawnienie nigdy nie jest wymagane."
      }
    }
  }
}

3. Zrób nowy build. Expo to podkreśla: zmiana w Info.plist nie przejdzie przez aktualizację zdalną, wymaga nowego pliku binarnego.
4. Wyślij build do Apple, a potem wybierz go w swojej wersji.

Pułapka, jeśli twoja aplikacja jest przetłumaczona: pliki językowe tłumaczą klucz, ale go nie deklarują. Klucz musi najpierw istnieć w ios.infoPlist (albo w konfiguracji danego pluginu). Inaczej aplikacja może się wysypać przy pierwszym wywołaniu.

Jakie zdanie napisać, jeśli aplikacja nie korzysta z tych danych?

Apple wymaga opisu dokładnego, użytecznego i konkretnego. Jeśli aplikacja naprawdę korzysta z danych, napisz w jednym zdaniu, do czego: „Aplikacja używa aparatu do skanowania kodu kreskowego z twojego biletu.”

Jeśli klucz jest tam tylko przez bibliotekę, Apple podaje dwa rozwiązania: napisać zdanie albo usunąć kod, który sięga po dane. Gdy ten kod pochodzi z biblioteki, nie usuniesz go tak po prostu. W Solys napisałem więc prawdę: „Solys nie ma dostępu do twoich zdjęć. To uprawnienie nigdy nie jest wymagane.” To pragmatyczny wybór: kolejny build przeszedł przy dostarczeniu, ale nie mogę ci obiecać, że Apple zawsze zaakceptuje takie zdanie.

Jak wykryć brakujące klucze przed wysyłką

Z katalogu głównego projektu ta komenda wypisze pliki bibliotek, których kod iOS odwołuje się do najbardziej pilnowanych API:

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

Każda nazwa odpowiada rodzajowi danych: PHPhotoLibrary to zdjęcia, AVCaptureDevice aparat i mikrofon, CLLocationManager lokalizacja, CNContactStore kontakty, EKEventStore kalendarz, ATTrackingManager śledzenie. Dla każdego wyniku sprawdź, czy odpowiedni klucz z opisem istnieje w twojej konfiguracji.

Ta siatka łapie przypadki, na które trafiłem. Nie zastępuje przeczytania maila od Apple, który pozostaje jedyną pewną listą, tak jak przy niepublicznych API z ITMS-90338. Od tamtego odrzucenia robię tę kontrolę przed każdym buildem: zajmuje kilka sekund, a odrzucenie ITMS-90683 kosztuje build i czas na zrobienie nowego.

Wyślij build bez przykrych niespodzianek

ITMS-90683 naprawia się szybko, jeśli wiesz, jak go czytać, podobnie jak ITMS-90725, który dotyczy wersji Xcode. Odrzucenia, które przychodzą później, od recenzenta, wymagają więcej dystansu: sposób postępowania znajdziesz na stronie aplikacja odrzucona przez Apple, a najczęstsze powody w artykule dlaczego Apple odrzuca aplikację.

Żeby sprawdzić wszystko przed wysyłką, Apple Review Kit zawiera moją checklistę i skille Claude Code, które przeglądają twój projekt. Jeśli wysyłka utknęła i chcesz, żeby spojrzał na to człowiek, zarezerwuj ze mną godzinę: przejdziemy przez twój projekt na wideo, na twoim ekranie. A jeśli szykujesz swoje pierwsze wydanie, zrób darmową diagnozę: ułoży kroki we właściwej kolejności i wyśle ci moją checklistę przeciw odrzuceniom przez Apple.

Najczęściej zadawane pytania

Czy ITMS-90683 to odrzucenie przez App Review?

Nie w sensie recenzenta-człowieka. To automatyczna kontrola builda przy dostarczeniu, przed rozpoczęciem przeglądu, tak jak ITMS-90717 przy ikonie. Nikt nie otwierał twojej aplikacji. Build zostaje odrzucony: trzeba poprawić Info.plist i wysłać nowy.

Dlaczego Apple wymaga klucza dla danych, z których moja aplikacja nie korzysta?

Bo Apple analizuje kod obecny w buildzie, a nie zachowanie aplikacji. Jeśli dołączona biblioteka odwołuje się do biblioteki zdjęć albo aparatu, klucz z opisem jest wymagany, nawet jeśli żaden ekran nigdy nie prosi o taki dostęp.

Czy da się naprawić ITMS-90683 aktualizacją zdalną?

Nie. Brakujący klucz jest w Info.plist, który jest częścią pliku binarnego. Aktualizacja zdalna nie zmienia tego pliku: trzeba zrobić nowy build i wysłać go do Apple.

Gdzie dodać NSPhotoLibraryUsageDescription w projekcie Expo?

W konfiguracji aplikacji, w ios.infoPlist, ze zdaniem opisującym użycie. Niektóre biblioteki mają też osobne ustawienie w swoim pluginie, które może dodawać inne klucze, na przykład tryb działania w tle. W obu przypadkach klucz musi istnieć w podstawowej konfiguracji, a nie tylko w plikach tłumaczeń.

Czy trzeba usuwać nieużywane klucze z opisem?

Tylko jeśli żadna biblioteka w buildzie nie odwołuje się już do danego API. Inaczej następna wysyłka zostanie odrzucona z ITMS-90683. Zanim usuniesz klucz, poszukaj nazwy API w kodzie iOS swoich zależności.