ITMS-90034: come risolvere Missing or invalid signature

ITMS-90034 compare quando invii la tua build ad App Store Connect. Dice che la tua app, o uno dei suoi componenti, non è firmata con un certificato di invio Apple, cioè con un certificato di distribuzione valido. La soluzione: capire quale bundle è firmato male e perché, poi rifare una build firmata per l'App Store.

Questa guida resta concentrata sull'errore. Se le parole certificato e profilo non ti sono chiare, leggi prima certificato sviluppatore iOS e provisioning profile. Qui trovi il messaggio da leggere, un albero decisionale, i comandi che ispezionano la tua IPA e la correzione con le credenziali gestite da EAS. Per la parte EAS ho letto il codice di EAS CLI 24.10.0 che sceglie il certificato.

Cosa significa l'errore ITMS-90034?

Ecco la sua forma classica, con nomi di esempio:

ITMS-90034: Missing or invalid signature. The bundle 'com.example.myapp' at bundle path 'Payload/MyApp.app' is not signed using an Apple submission certificate.

Nel 2026, sul forum di Apple, compare anche nella forma "Validation failed (409) Missing or invalid signature", seguita dallo stesso testo e da "(ID: 90034)".

Il "certificato di invio" è il certificato di distribuzione. La guida di Apple sui certificati lo dice chiaramente: i certificati di sviluppo servono a eseguire la tua app sui tuoi dispositivi, quelli di distribuzione a distribuirla o a inviarla ad App Store Connect.

Leggi il percorso citato: indica il bundle colpevole. Payload/MyApp.app si riferisce all'app stessa. Un percorso che finisce con .appex si riferisce a un'estensione, come un widget. Un percorso in .framework si riferisce a una libreria incorporata.

Non è il rifiuto di un reviewer. La validazione scatta all'invio o durante l'elaborazione della build, prima di TestFlight: questa build non arriverà mai ai tuoi tester.

L'albero decisionale: dal messaggio alla correzione

Ogni riga corrisponde a un indizio che leggi nel messaggio, nei comandi della sezione successiva o nei log di EAS. Seguile in ordine: la prima che corrisponde ti dà la pista.

Cosa osservi	Causa probabile	Correzione
Percorso in .appex	Estensione firmata male	Dichiarare l'estensione
Signature=adhoc	Build non firmata	Build con profilo store
Apple Development	Build di sviluppo	Build con profilo store
ProvisionedDevices letto	Build interna (ad hoc)	Build con profilo store
sealed resource	IPA modificata dopo	Rifare la build
EAS: "no longer valid"	Certificato revocato	Nuovo certificato
Tutto è valido	Problema lato Apple	Reinviare, poi segnalare

Ispezionare la tua IPA in quattro comandi

Scarica l'IPA dalla pagina della build su expo.dev, poi apri un terminale sul tuo Mac.

1. Chi ha firmato l'app?

unzip -q MyApp.ipa -d ipa
codesign -dv --verbose=4 ipa/Payload/*.app 2>&1 | grep -E "^(Identifier|Authority|Signature|TeamIdentifier)="

codesign scrive sullo standard error, da qui il 2>&1. Secondo la nota tecnica TN3161 di Apple, ogni riga Authority è un anello della catena di fiducia. La prima deve iniziare con Apple Distribution: o iPhone Distribution:, seguita dal nome del tuo team. La seconda etichetta è quella del vecchio tipo iOS Distribution: in base al suo codice, EAS CLI 24.10.0 crea ancora certificati di questo tipo. Se leggi Apple Development:, è una build di sviluppo. Se leggi Signature=adhoc senza nessuna riga Authority, il binario non è firmato da alcun certificato.

2. L'app è stata modificata dopo la firma?

codesign --verify --deep --strict -vv ipa/Payload/*.app

Vuoi leggere valid on disk, poi satisfies its Designated Requirement. TN3161 precisa cosa garantisce questo controllo: tutti i file attesi ci sono, nessuno è stato aggiunto, nessuno è stato modificato. Su un bundle di test che ho firmato e poi ritoccato, il comando risponde a sealed resource is missing or invalid, poi file modified: seguito dal file cambiato. L'opzione --deep qui serve a verificare, mai a firmare: sul forum di Apple, un ingegnere del team di supporto la sconsiglia per la firma.

3. Quale profilo è incorporato?

security cms -D -i ipa/Payload/*.app/embedded.mobileprovision -o profil.plist
plutil -extract ProvisionedDevices xml1 -o - profil.plist
plutil -extract ExpirationDate raw profil.plist

Sono i comandi della nota TN3125 sui profili. Un profilo App Store non contiene alcuna lista di dispositivi: la seconda riga deve rispondere Could not extract value. Se mostra identificativi di dispositivi, è un profilo ad hoc, quello di una build interna. La terza dà la data di scadenza del profilo.

4. Estensioni e framework sono firmati allo stesso modo?

find ipa/Payload/*.app \( -name "*.appex" -o -name "*.framework" \) \
  -exec sh -c 'echo "$1"; codesign -dvv "$1" 2>&1 | grep -m1 "^Authority="' _ {} \;

Ogni componente deve mostrare la stessa riga Authority dell'app. Se uno se ne discosta, è quello citato dal messaggio.

Se vuoi verificare prima dell'invio, TN3161 consiglia altool, lo stesso controllo del pulsante Validate App di Xcode. Richiede una chiave API di App Store Connect, il cui file AuthKey_<KEY_ID>.p8 va messo in ~/.appstoreconnect/private_keys:

xcrun altool --validate-app -f MyApp.ipa -t ios --api-key <KEY_ID> --api-issuer <ISSUER_ID>

Correggere con EAS, causa per causa

Una build interna o di sviluppo inviata ad Apple

Secondo la documentazione di Expo su eas.json, le build in "distribution": "internal" non sono firmate per gli store: usano un profilo ad hoc. Solo un profilo con distribuzione store, il valore predefinito, produce una build inviabile. La cosa più sicura è inviare la build che hai appena creato, senza sceglierla a mano:

eas build --platform ios --profile production --auto-submit

Se usi eas submit --path, controlla che il file sia davvero la tua ultima build store. Sul forum di Apple, un team ha scoperto che il suo strumento di invio rimandava ogni volta una vecchia IPA, versionata in git.

Un'estensione dimenticata

Ogni estensione è un bundle a sé, con il suo identificativo e il suo profilo. In un progetto Expo con generazione nativa, la pagina di Expo sulle estensioni iOS chiede di dichiararle in extra.eas.build.experimental.ios.appExtensions. EAS CLI le conosce così prima della build, e crea o valida le loro credenziali. La maggior parte delle librerie che aggiungono un'estensione scrive questa dichiarazione per te, tramite il proprio plugin.

Solys, la mia sveglia con minigiochi, incorpora quattro estensioni: un widget e tre estensioni di Screen Time. Tutte e quattro sono dichiarate nella sua configurazione, ed EAS ha un profilo per ognuna. Un'estensione aggiunta a mano in Xcode, senza questa dichiarazione, è la candidata ideale per un percorso in .appex nel messaggio.

Un certificato revocato o scaduto

La pagina di Apple sui certificati è chiara: non puoi più inviare una build firmata con un certificato scaduto o revocato. Una build già inviata ma non ancora sottoposta a revisione può persino passare in Invalid Binary se il suo certificato è stato revocato.

Il codice di EAS CLI 24.10.0 mostra quando questo caso passa inosservato:

• Build interattiva, connessa ad Apple: EAS confronta il suo certificato con quelli ancora validi presso Apple. Se non c'è più, mostra "Current distribution certificate is no longer valid in Apple Dev Portal" e ti propone di sceglierne o crearne uno.
• Build interattiva, senza connessione: EAS verifica solo le date e avvisa che salta la validazione presso Apple.
• Build non interattiva, in integrazione continua: EAS mostra "Distribution Certificate is not validated for non-interactive builds" e firma comunque.

In integrazione continua, EAS non ricontrolla il certificato stesso: una revoca può emergere solo all'invio. La soluzione: lancia una build interattiva connessa al tuo account Apple, oppure usa eas credentials --platform ios, menu Build Credentials, poi "Distribution Certificate: Add a new one to your account". I profili che contenevano il vecchio certificato diventano non validi: EAS li controlla alla build successiva e li rigenera. I limiti di Apple sul numero di certificati sono spiegati nella guida sul certificato sviluppatore iOS.

Un binario modificato dopo la firma

La firma sigilla codice, risorse e metadati tramite hash, come spiega la nota TN3126 di Apple. Decomprimere l'IPA per cambiare un file e poi ricomprimerla rompe questo sigillo. Fai la modifica nella tua configurazione, poi rifai la build. Non ritoccare mai l'IPA prodotta da EAS.

Stessa logica per il codice messo nel posto sbagliato, per esempio in un archivio .zip: l'App Store non può rifirmarlo. Apple descrive le posizioni consentite nella sua pagina su il contenuto di un bundle.

Credenziali locali

Se il tuo profilo EAS usa "credentialsSource": "local", il tuo file credentials.json punta a un certificato .p12 e a un profilo .mobileprovision. Controlla il profilo con i comandi del passo 3: deve essere di tipo App Store e contenere il tuo certificato di distribuzione attuale. E tieni questi file fuori dal repository, come le chiavi API di un'app Expo.

Quando tutto è valido

Resta un caso frustrante. Sul forum di Apple, alcuni sviluppatori vedono l'errore sparire reinviando la stessa build, senza cambiare nulla. Ad agosto e settembre 2026, due thread descrivono il contrario: certificato e profilo nuovi, firma verificata, errore persistente. In uno dei due, un ingegnere di Apple consiglia una segnalazione di bug con l'IPA, l'analisi della firma e i log di Transporter, poi un contatto con App Store Connect.

Quindi reinvia una volta con un nuovo numero di build. Se l'errore torna anche se i tuoi quattro comandi sono puliti, segnalalo ad Apple con questi elementi. Non revocare il certificato per riflesso: non risolve nulla in più e invalida i tuoi profili.

Inviare la tua build senza brutte sorprese

Una firma si verifica in due minuti prima dell'invio. Gli altri controlli automatici richiedono lo stesso rigore, come ITMS-90725 per la versione di Xcode o ITMS-90683 per le frasi di autorizzazione. Il percorso completo dalla build all'invio, senza Mac, è in pubblicare un'app iOS senza Mac.

I rifiuti di un reviewer richiedono più distacco: il procedimento è nella pagina app rifiutata da Apple, e i motivi più frequenti sono in perché Apple rifiuta un'app.

Per controllare tutto prima dell'invio, il Review Kit riunisce la mia checklist e delle skill di Claude Code che rileggono il tuo progetto. Se il tuo invio è bloccato e vuoi uno sguardo umano, prenota un'ora con me: riprendiamo il tuo progetto in videochiamata, sul tuo schermo. E se stai preparando la tua prima uscita, fai la tua diagnosi gratuita: rimette i passaggi in ordine e ti invia la mia checklist anti-rifiuto Apple.

Domande frequenti

ITMS-90034 è un rifiuto di App Review?

No. È una validazione automatica fatta all'invio della build, prima di TestFlight e prima di qualsiasi revisione. Nessuno ha aperto la tua app: Apple ha solo constatato che la sua firma non proviene da un certificato di distribuzione valido.

Devo revocare il mio certificato di distribuzione per risolvere ITMS-90034?

Solo se è compromesso o già non valido. Revocare un certificato che funziona invalida i tuoi profili senza correggere la causa. Inizia leggendo la firma della tua IPA con codesign, poi correggi ciò che indica l'albero decisionale.

Si può risolvere ITMS-90034 con un aggiornamento da remoto?

No. La firma fa parte del binario, e la build rifiutata non sarà mai utilizzabile. Devi produrre un nuovo binario firmato correttamente e reinviarlo.

Perché l'errore cita il mio widget e non la mia app?

Perché il widget è un bundle a sé, firmato con il proprio profilo. Se non è dichiarato a EAS o è stato firmato in altro modo, fa fallire l'intero invio. Dichiara l'estensione nella tua configurazione e rifai la build.

Cosa fare se codesign dice che è tutto valido?

Controlla anche il profilo incorporato e ogni estensione. Se è tutto pulito, reinvia una volta con un nuovo numero di build. Se l'errore persiste, invia una segnalazione ad Apple con l'IPA, l'output di codesign e i log di invio.