ITMS-91053: fixa ”Missing API declaration” med Expo

ITMS-91053 är en automatisk kontroll från Apple som skickas via mejl efter att du har levererat ditt build. Den säger att koden i din app använder ett API som kräver en angiven orsak (inställningar, fildatum, tid sedan uppstart, diskutrymme eller tangentbord) utan att förklara varför i appens integritetsmanifest. Med Expo fixar du det i ios.privacyManifests: kategorin som Apple nämner, koden som beskriver hur du faktiskt använder API:t, och sedan ett nytt build.

I Solys, min väckarklocka med minispel, deklareras de här orsakerna i appens konfiguration. Här är dess riktiga deklaration, kommandot som listar vad dina beroenden använder, och kontrollen du ska göra på den färdiga filen innan du skickar in.

Vad betyder felet ITMS-91053?

Meddelandet heter ”ITMS-91053: Missing API declaration”. Det säger att koden i en viss fil i ditt build refererar till ett eller flera API:er som kräver en orsak. Sedan listar det vilka kategorier det gäller, till exempel NSPrivacyAccessedAPICategoryUserDefaults.

De här API:erna ber inte användaren om någon behörighet. Men de kan användas för att känna igen en enhet, det Apple kallar fingerprinting. Det är förbjudet, även när användaren godkänner spårning. Apple förklarar det på sin sida om API:er som kräver en orsak: varje app och varje SDK måste deklarera varför den använder dem.

Samma sida slår fast regeln: sedan den 1 maj 2024 accepterar App Store Connect inte längre en app som inte beskriver de här användningarna i sitt manifest. Vissa utvecklare har rapporterat att mejlet bara kom som en varning, på ett build som godkändes. Räkna inte med det: behandla det som ett stopp och fixa det före nästa inskick.

Precis som andra ITMS-fel är det inte ett avslag från en granskare. Ingen har öppnat din app: Apple har analyserat binärfilen.

Integritetsmanifestet i iOS: filen PrivacyInfo.xcprivacy

Integritetsmanifestet är en fil som heter PrivacyInfo.xcprivacy och ligger i roten av appens bundle. Enligt Apples dokumentation om privacy manifests beskriver den insamlad data, spårning och API:er som kräver en orsak. De sistnämnda hamnar i arrayen NSPrivacyAccessedAPITypes: en post per kategori, med dess typ och listan över orsaker.

Fällan: ett manifest täcker bara sin egen bundle. Apple skriver det tydligt: varje körbar fil eller dynamiskt bibliotek som använder de här API:erna måste ha ett manifest i sin bundle. Appens manifest täcker inte ett inbäddat framework, och ett SDK kan inte förlita sig på appens manifest.

Blanda inte ihop det med texterna i Info.plist som krävs av ITMS-90683. De visas för användaren i en behörighetsförfrågan. Manifestet läses bara av Apple.

De 5 API-kategorierna och deras orsakskoder

Det fullständiga namnet på en kategori börjar med NSPrivacyAccessedAPICategory. Listan över API:er och orsaker finns på sidan för nyckeln NSPrivacyAccessedAPIType, läst den 15 oktober 2026.

Kategori	Typiskt API	Vanlig orsak
UserDefaults	UserDefaults	CA92.1
FileTimestamp	creationDate	C617.1
SystemBootTime	systemUptime	35F9.1
DiskSpace	volumeAvailableCapacityKey	E174.1
ActiveKeyboards	activeInputModes	54BD.1

Koderna du oftast stöter på:

• CA92.1: appen läser och skriver sina egna inställningar, som andra appar inte kommer åt.
• 1C8F.1: inställningar som delas med en widget eller ett tillägg i samma App Group.
• C617.1: datum eller storlek på filer som ligger i appens container.
• 3B52.1: filer som användaren har valt, till exempel i en dokumentväljare.
• 35F9.1: mäta tiden mellan två händelser i appen, eller köra en timer.
• E174.1: kontrollera ledigt utrymme innan filer skrivs, med en synlig effekt för användaren.
• 85F4.1: visa diskutrymmet för användaren.

Deklarera den orsak som motsvarar din faktiska användning, inte den som verkar bredast. Apple påpekar att de här API:erna och deras data bara får användas för de deklarerade orsakerna, och aldrig för spårning. Två koder är reserverade för tredjeparts-SDK:er: C56D.1 och 0A2A.1. De hör inte hemma i din apps manifest.

Deklarera integritetsmanifestet i Expo

Med Expo skriver du inte filen själv. Du beskriver den under expo.ios.privacyManifests, i app.json eller app.config, och prebuild genererar PrivacyInfo.xcprivacy. Det är metoden i Expos dokumentation om privacy manifests.

Här är det riktiga utdraget ur Solys konfiguration. Nyckeln innehåller också spårning och insamlad data, som jag har tagit bort här:

{
  "expo": {
    "ios": {
      "privacyManifests": {
        "NSPrivacyAccessedAPITypes": [
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
            "NSPrivacyAccessedAPITypeReasons": ["CA92.1", "1C8F.1"]
          },
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryFileTimestamp",
            "NSPrivacyAccessedAPITypeReasons": ["C617.1"]
          },
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategorySystemBootTime",
            "NSPrivacyAccessedAPITypeReasons": ["35F9.1"]
          }
        ]
      }
    }
  }
}

CA92.1, C617.1 och 35F9.1 speglar det som React Native och appens Expo-moduler deklarerar. 1C8F.1 kommer från Solys själv: appen delar inställningar med sin widget via en App Group.

En fälla att känna till: om din ios-mapp genereras och ignoreras av git, hamnar en handskriven PrivacyInfo.xcprivacy i den mappen aldrig i buildet. EAS kör prebuild igen och genererar om mappen. Jag såg det i ett av mina projekt den 9 september 2026: det handskrivna manifestet hade försvunnit efter en prebuild. Deklarationen måste ligga i konfigurationen.

Sista punkten: manifestet är en del av binärfilen. En fjärruppdatering ändrar det inte. Du måste bygga om och skicka in igen.

Tredjeparts-SDK:er som har sitt eget manifest

De flesta nyare bibliotek levererar sitt eget manifest. Expo-paketen som använder de här API:erna har en PrivacyInfo.xcprivacy i sin ios-mapp, precis som React Native. Problemet ligger i hur de länkas till din app.

Expos dokumentation varnar: Apple läser inte alla manifest korrekt från CocoaPods-beroenden som länkas statiskt, vilket Expo-paketen gör. Du kan alltså behöva kopiera in deras orsaker i din apps konfiguration.

För att minska det jobbet slår inställningen ios.privacyManifestAggregationEnabled i expo-build-properties ihop manifesten från CocoaPods-beroenden till en enda fil. I den Podfile som Expo genererar i mina projekt (SDK 57) är sammanslagningen aktiv, om du inte stänger av den.

Sammanslagningen har en begränsning: den ser bara beroenden som har ett manifest. Ett äldre bibliotek utan manifest förblir osynligt. Läs därför sökvägen till filen som nämns i mejlet: den säger var du ska rätta.

Fil som nämns	Var du rättar
Appens körbara fil	ios.privacyManifests
Ett .framework	Uppdatera SDK:t
Ett tillägg .appex	Tilläggets manifest

Kontrollera innan du skickar in

Expo föreslår att du väntar på Apples mejl efter ett inskick. Det fungerar, men varje vända kostar ett build. Här är de fyra kontrollerna jag gör innan.

1. Lista vad dina beroenden deklarerar. Från projektets rot:

find node_modules -name PrivacyInfo.xcprivacy -not -path '*/example/*' \
  -exec grep -ho "NSPrivacyAccessedAPICategory[A-Za-z]*" {} + | sort | uniq -c

I Solys hittade kommandot den 15 oktober 2026 13 manifest och fyra kategorier: fildatum, inställningar, tid sedan uppstart och diskutrymme. Varje listad kategori måste finnas i appens slutliga manifest, eller i manifestet för det framework som använder den.

2. Sök i din egen native-kod. Egna moduler, plugins, targets som en widget: den koden deklarerar inget SDK åt dig.

grep -rlE "UserDefaults|systemUptime|mach_absolute_time|creationDate|modificationDate|volumeAvailableCapacity|activeInputModes" \
  --include='*.swift' --include='*.m' --include='*.mm' modules plugins targets

Anpassa mapparna efter ditt projekt. I Solys är det den här sökningen som visar inställningarna som delas via App Group, därav koden 1C8F.1.

3. Läs det genererade manifestet. Kör npx expo prebuild -p ios och öppna sedan ios/<NomDeTonApp>/PrivacyInfo.xcprivacy. Obs: kommandot kan radera och återskapa ios-mappen. Om du har gjort ändringar för hand där, jobba på en kopia av projektet.

4. Kontrollera det slutliga buildet. Det är det enda beviset som räknas. Ladda ner IPA-filen från buildets sida på expo.dev och kör sedan på din Mac:

unzip -q MonApp.ipa -d ipa
find ipa/Payload -name PrivacyInfo.xcprivacy
plutil -p ipa/Payload/*.app/PrivacyInfo.xcprivacy

Andra raden listar alla inbäddade manifest, appens och de från frameworks. Tredje raden visar appens manifest, som du jämför med listan från steg 1.

Vad manifestet måste säga i samklang med din produktsida

Manifestet lever inte ensamt. Om det deklarerar spårning eller insamlad data måste din App Store-sida och din integritetspolicy säga samma sak. En skillnad mellan de tre kan sedan kosta ett manuellt avslag enligt guideline 5.1.1. Vad som ska stämma överens beskrivs i integritetspolicy för en app.

Skicka in ditt build utan obehagliga överraskningar

ITMS-fel går snabbt att fixa när man vet hur man läser dem. Avslagen som kommer efteråt kräver mer eftertanke: tillvägagångssättet finns på sidan app avvisad av Apple, och de vanligaste orsakerna finns i varför Apple avvisar en app.

För att kontrollera ditt projekt innan inskick samlar Apple Review Kit min checklista och Claude Code-skills som går igenom ditt projekt. Om ditt inskick fastnar och du vill ha ett mänskligt öga, boka en timme med mig: vi går igenom ditt projekt via videosamtal, på din skärm. Och om du förbereder din första release, gör din gratis diagnos: den sätter stegen i rätt ordning och skickar dig min checklista mot avslag från Apple.

Vanliga frågor

Blockerar ITMS-91053 inskicket av mitt build?

Apple skriver att App Store Connect sedan den 1 maj 2024 inte längre accepterar appar som inte beskriver hur de använder de här API:erna. Ändå har vissa utvecklare fått mejlet på ett build som godkändes, som en varning. I båda fallen: rätta manifestet före nästa build.

Vilken orsakskod ska jag välja för UserDefaults?

CA92.1 om appen bara läser och skriver sina egna inställningar. Lägg till 1C8F.1 om den delar dem med en widget eller ett tillägg via en App Group. C56D.1 är reserverad för tredjeparts-SDK:er: lägg inte in den i din apps manifest.

Måste jag kopiera varje SDK:s manifest till app.json?

Inte nödvändigtvis. Om sammanslagningen av manifest är aktiv slås CocoaPods-beroendenas manifest ihop när poddarna installeras. Kopiera bara in en kategori om den saknas i det slutliga manifestet, med den orsak som beskriver den faktiska användningen.

Behöver min widget eller mitt tillägg ett eget manifest?

Enligt Apple måste varje bundle som innehåller en körbar fil som använder de här API:erna ha ett eget manifest. Ett tillägg är en separat körbar fil i en egen bundle: appens manifest täcker det inte.

Går det att fixa ITMS-91053 utan att bygga om?

Nej. Integritetsmanifestet är en del av binärfilen. Rätta konfigurationen, bygg om och testa sedan i TestFlight innan du skickar in för granskning.