ITMS-90034: διόρθωση του «Missing or invalid signature»

ΤΟ ITMS-90034 εμφανίζεται όταν στέλνεις το build σου στο App Store Connect. Σου λέει ότι η εφαρμογή σου, ή κάποιο από τα κομμάτια της, δεν έχει υπογραφεί με πιστοποιητικό υποβολής της Apple, δηλαδή με έγκυρο πιστοποιητικό διανομής. Η λύση: βρες ποιο bundle έχει λάθος υπογραφή και γιατί, και μετά φτιάξε νέο build υπογεγραμμένο για το App Store.

Ο οδηγός αυτός μένει στο συγκεκριμένο σφάλμα. Αν οι λέξεις πιστοποιητικό και profile σού είναι θολές, διάβασε πρώτα το πιστοποιητικό developer iOS και provisioning profile. Εδώ θα βρεις το μήνυμα που πρέπει να διαβάσεις, ένα δέντρο αποφάσεων, τις εντολές που ελέγχουν το IPA σου και τη διόρθωση με τα credentials που διαχειρίζεται το EAS. Για το κομμάτι του EAS, διάβασα τον κώδικα του EAS CLI 24.10.0 που επιλέγει το πιστοποιητικό.

Τι σημαίνει το σφάλμα ITMS-90034;

Αυτή είναι η κλασική μορφή του, με ονόματα παραδείγματος:

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.

Το 2026, στο φόρουμ της Apple, εμφανίζεται και ως «Validation failed (409) Missing or invalid signature», ακολουθούμενο από το ίδιο κείμενο και το «(ID: 90034)».

Το «πιστοποιητικό υποβολής» είναι το πιστοποιητικό διανομής. Το λέει καθαρά η βοήθεια της Apple για τα πιστοποιητικά: τα πιστοποιητικά development χρησιμεύουν για να τρέχεις την εφαρμογή στις συσκευές σου, ενώ τα πιστοποιητικά distribution για να τη διανέμεις ή να τη στέλνεις στο App Store Connect.

Διάβασε το path που αναφέρεται: δείχνει το bundle με το πρόβλημα. Το Payload/MyApp.app αφορά την ίδια την εφαρμογή. Ένα path που τελειώνει σε .appex αφορά ένα extension, όπως ένα widget. Ένα path σε .framework αφορά μια ενσωματωμένη βιβλιοθήκη.

Δεν είναι απόρριψη από reviewer. Ο έλεγχος γίνεται κατά την αποστολή ή την επεξεργασία του build, πριν από το TestFlight: αυτό το build δεν θα φτάσει ποτέ στους testers σου.

Το δέντρο αποφάσεων: από το μήνυμα στη διόρθωση

Κάθε γραμμή αντιστοιχεί σε μια ένδειξη που βλέπεις στο μήνυμα, στις εντολές της επόμενης ενότητας ή στα logs του EAS. Πάρε τες με τη σειρά: η πρώτη που ταιριάζει σού δείχνει τον δρόμο.

Τι βλέπεις	Πιθανή αιτία	Διόρθωση
Path σε .appex	Extension με λάθος υπογραφή	Δήλωσε το extension
Signature=adhoc	Build χωρίς υπογραφή	Build με store profile
Apple Development	Development build	Build με store profile
Υπάρχει ProvisionedDevices	Internal build (ad hoc)	Build με store profile
sealed resource	IPA τροποποιημένο μετά	Νέο build
EAS: «no longer valid»	Ανακληθέν πιστοποιητικό	Νέο πιστοποιητικό
Όλα έγκυρα	Πρόβλημα από την Apple	Ξαναστείλε, μετά ανάφερέ το

Έλεγξε το IPA σου με τέσσερις εντολές

Κατέβασε το IPA από τη σελίδα του build στο expo.dev και άνοιξε ένα terminal στο Mac σου.

1. Ποιος υπέγραψε την εφαρμογή;

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

Το codesign γράφει στο standard error, γι' αυτό υπάρχει το 2>&1. Σύμφωνα με το τεχνικό σημείωμα TN3161 της Apple, κάθε γραμμή Authority είναι ένας κρίκος της αλυσίδας εμπιστοσύνης. Η πρώτη πρέπει να ξεκινά με Apple Distribution: ή iPhone Distribution:, ακολουθούμενη από το όνομα της ομάδας σου. Η δεύτερη ετικέτα είναι του παλιού τύπου iOS Distribution: σύμφωνα με τον κώδικά του, το EAS CLI 24.10.0 δημιουργεί ακόμα πιστοποιητικά αυτού του τύπου. Αν δεις Apple Development:, είναι development build. Αν δεις Signature=adhoc χωρίς καμία γραμμή Authority, το binary δεν έχει υπογραφεί από κανένα πιστοποιητικό.

2. Τροποποιήθηκε η εφαρμογή μετά την υπογραφή;

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

Θέλεις να δεις valid on disk και μετά satisfies its Designated Requirement. Το TN3161 εξηγεί τι εγγυάται αυτός ο έλεγχος: όλα τα αναμενόμενα αρχεία υπάρχουν, κανένα δεν προστέθηκε, κανένα δεν άλλαξε. Σε ένα δοκιμαστικό bundle που υπέγραψα και μετά πείραξα, η εντολή απαντά a sealed resource is missing or invalid και μετά file modified: με το αρχείο που άλλαξε. Η επιλογή --deep εδώ χρησιμεύει για έλεγχο, ποτέ για υπογραφή: στο φόρουμ της Apple, ένας μηχανικός της ομάδας υποστήριξης δεν τη συνιστά για υπογραφή.

3. Ποιο profile είναι ενσωματωμένο;

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

Αυτές είναι οι εντολές από το σημείωμα TN3125 για τα profiles. Ένα App Store profile δεν περιέχει λίστα συσκευών: η δεύτερη γραμμή πρέπει να απαντήσει Could not extract value. Αν εμφανίσει αναγνωριστικά συσκευών, είναι ad hoc profile, δηλαδή internal build. Η τρίτη δίνει την ημερομηνία λήξης του profile.

4. Έχουν τα extensions και τα frameworks την ίδια υπογραφή;

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

Κάθε κομμάτι πρέπει να δείχνει την ίδια γραμμή Authority με την εφαρμογή. Αν κάποιο διαφέρει, αυτό είναι που αναφέρει το μήνυμα.

Αν θέλεις να ελέγξεις πριν την αποστολή, το TN3161 προτείνει το altool, τον ίδιο έλεγχο με το κουμπί Validate App του Xcode. Χρειάζεται ένα API key του App Store Connect, του οποίου το αρχείο AuthKey_<KEY_ID>.p8 μπαίνει στο ~/.appstoreconnect/private_keys:

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

Διόρθωση με το EAS, αιτία προς αιτία

Internal ή development build σταλμένο στην Apple

Σύμφωνα με την τεκμηρίωση του Expo για το eas.json, τα builds με "distribution": "internal" δεν υπογράφονται για τα stores: χρησιμοποιούν ad hoc profile. Μόνο ένα profile με distribution store, την προεπιλεγμένη τιμή, παράγει build που μπορεί να σταλεί. Το πιο ασφαλές είναι να στείλεις το build που μόλις έφτιαξες, χωρίς να το διαλέξεις με το χέρι:

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

Αν χρησιμοποιείς eas submit --path, βεβαιώσου ότι το αρχείο είναι όντως το τελευταίο σου store build. Στο φόρουμ της Apple, μια ομάδα ανακάλυψε ότι το εργαλείο αποστολής της έστελνε κάθε φορά ένα παλιό IPA, αποθηκευμένο στο git.

Ένα ξεχασμένο extension

Κάθε extension είναι ξεχωριστό bundle, με δικό του αναγνωριστικό και δικό του profile. Σε ένα project Expo με native generation, η σελίδα του Expo για τα iOS extensions ζητά να τα δηλώνεις στο extra.eas.build.experimental.ios.appExtensions. Έτσι το EAS CLI τα γνωρίζει πριν το build και δημιουργεί ή επικυρώνει τα credentials τους. Οι περισσότερες βιβλιοθήκες που προσθέτουν extension γράφουν αυτή τη δήλωση για σένα, μέσω του plugin τους.

Το Solys, το ξυπνητήρι μου με mini-games, έχει τέσσερα extensions: ένα widget και τρία extensions του Screen Time. Και τα τέσσερα είναι δηλωμένα στη ρύθμισή του, και το EAS έχει profile για το καθένα. Ένα extension που προστέθηκε με το χέρι στο Xcode, χωρίς αυτή τη δήλωση, είναι ο ιδανικός ύποπτος για path σε .appex στο μήνυμα.

Ανακληθέν ή ληγμένο πιστοποιητικό

Η σελίδα της Apple για τα πιστοποιητικά είναι σαφής: δεν μπορείς πια να στείλεις build υπογεγραμμένο με ληγμένο ή ανακληθέν πιστοποιητικό. Ένα build που έχει ήδη σταλεί αλλά δεν έχει υποβληθεί ακόμα μπορεί μάλιστα να γίνει Invalid Binary αν το πιστοποιητικό του ανακληθεί.

Ο κώδικας του EAS CLI 24.10.0 δείχνει πότε αυτό περνά απαρατήρητο:

• Interactive build, συνδεδεμένο στην Apple: το EAS συγκρίνει το πιστοποιητικό του με όσα είναι ακόμα έγκυρα στην Apple. Αν δεν υπάρχει πια, εμφανίζει «Current distribution certificate is no longer valid in Apple Dev Portal» και σου προτείνει να διαλέξεις ή να δημιουργήσεις άλλο.
• Interactive build, χωρίς σύνδεση: το EAS ελέγχει μόνο τις ημερομηνίες και σε ειδοποιεί ότι παραλείπει τον έλεγχο στην Apple.
• Non-interactive build, σε continuous integration: το EAS εμφανίζει «Distribution Certificate is not validated for non-interactive builds» και υπογράφει κανονικά.

Σε continuous integration, το EAS δεν ξαναελέγχει το ίδιο το πιστοποιητικό: μια ανάκληση μπορεί να φανεί μόνο στην αποστολή. Η διόρθωση: τρέξε interactive build συνδεδεμένο στον λογαριασμό σου στην Apple, ή χρησιμοποίησε το eas credentials --platform ios, μενού Build Credentials, και μετά «Distribution Certificate: Add a new one to your account». Τα profiles που περιείχαν το παλιό πιστοποιητικό γίνονται άκυρα: το EAS τα ελέγχει στο επόμενο build και τα ξαναφτιάχνει. Τα όρια της Apple στον αριθμό πιστοποιητικών εξηγούνται στον οδηγό για το πιστοποιητικό developer iOS.

Binary τροποποιημένο μετά την υπογραφή

Η υπογραφή σφραγίζει τον κώδικα, τους πόρους και τα metadata με hashes, όπως εξηγεί το σημείωμα TN3126 της Apple. Αν αποσυμπιέσεις το IPA για να αλλάξεις ένα αρχείο και μετά το συμπιέσεις ξανά, σπας αυτή τη σφραγίδα. Κάνε την αλλαγή στη ρύθμισή σου και φτιάξε νέο build. Μην πειράζεις ποτέ το IPA που παράγει το EAS.

Ίδια λογική για κώδικα σε λάθος σημείο, για παράδειγμα μέσα σε αρχείο .zip: το App Store δεν μπορεί να τον ξαναυπογράψει. Η Apple περιγράφει τα επιτρεπτά σημεία στη σελίδα της για το περιεχόμενο ενός bundle.

Τοπικά credentials

Αν το EAS profile σου χρησιμοποιεί "credentialsSource": "local", το αρχείο σου credentials.json δείχνει σε ένα πιστοποιητικό .p12 και ένα profile .mobileprovision. Έλεγξε το profile με τις εντολές του βήματος 3: πρέπει να είναι τύπου App Store και να περιέχει το τρέχον πιστοποιητικό διανομής σου. Και κράτα αυτά τα αρχεία έξω από το repository, όπως τα API keys μιας εφαρμογής Expo.

Όταν όλα είναι έγκυρα

Μένει μια εκνευριστική περίπτωση. Στο φόρουμ της Apple, κάποιοι developers βλέπουν το σφάλμα να εξαφανίζεται όταν ξαναστέλνουν το ίδιο build, χωρίς καμία αλλαγή. Τον Αύγουστο και τον Σεπτέμβριο του 2026, δύο νήματα περιγράφουν το αντίθετο: καινούργιο πιστοποιητικό και profile, ελεγμένη υπογραφή, και η αποτυχία επιμένει. Σε ένα από αυτά, ένας μηχανικός της Apple προτείνει bug report με το IPA, την ανάλυση της υπογραφής και τα logs του Transporter, και μετά επικοινωνία με το App Store Connect.

Ξαναστείλε λοιπόν μία φορά με νέο build number. Αν το σφάλμα επιστρέψει ενώ οι τέσσερις εντολές σου είναι καθαρές, ανάφερέ το στην Apple με αυτά τα στοιχεία. Μην ανακαλείς το πιστοποιητικό σου από αντανακλαστικό: δεν λύνει τίποτα παραπάνω και ακυρώνει τα profiles σου.

Στείλε το build σου χωρίς δυσάρεστες εκπλήξεις

Μια υπογραφή ελέγχεται σε δύο λεπτά πριν την αποστολή. Οι υπόλοιποι αυτόματοι έλεγχοι θέλουν την ίδια προσοχή, όπως το ITMS-90725 για την έκδοση του Xcode ή το ITMS-90683 για τα κείμενα αδειών. Όλη η διαδρομή από το build ως την αποστολή, χωρίς Mac, είναι στο δημοσίευση εφαρμογής iOS χωρίς Mac.

Οι απορρίψεις από reviewer θέλουν περισσότερη ψυχραιμία: η διαδικασία είναι στη σελίδα εφαρμογή απορρίφθηκε από την Apple, και οι πιο συχνοί λόγοι στο γιατί η Apple απορρίπτει μια εφαρμογή.

Για να ελέγξεις τον φάκελό σου πριν την αποστολή, το Review Kit συγκεντρώνει τη checklist μου και skills του Claude Code που ξαναδιαβάζουν το project σου. Αν η αποστολή σου κολλάει και θέλεις ανθρώπινη ματιά, κλείσε μια ώρα μαζί μου: δουλεύουμε το project σου σε βιντεοκλήση, στην οθόνη σου. Κι αν ετοιμάζεις την πρώτη σου κυκλοφορία, κάνε τη δωρεάν διάγνωση: βάζει τα βήματα σε σειρά και σου στέλνει τη checklist μου κατά των απορρίψεων της Apple.

Συχνές ερωτήσεις

Είναι το ITMS-90034 απόρριψη από το App Review;

Όχι. Είναι αυτόματος έλεγχος κατά την αποστολή του build, πριν από το TestFlight και πριν από οποιαδήποτε αξιολόγηση. Κανείς δεν άνοιξε την εφαρμογή σου: η Apple απλώς διαπίστωσε ότι η υπογραφή της δεν προέρχεται από έγκυρο πιστοποιητικό διανομής.

Πρέπει να ανακαλέσω το πιστοποιητικό διανομής μου για να διορθώσω το ITMS-90034;

Μόνο αν έχει διαρρεύσει ή είναι ήδη άκυρο. Αν ανακαλέσεις ένα πιστοποιητικό που λειτουργεί, ακυρώνεις τα profiles σου χωρίς να διορθώσεις την αιτία. Ξεκίνα διαβάζοντας την υπογραφή του IPA σου με το codesign και μετά διόρθωσε ό,τι δείχνει το δέντρο αποφάσεων.

Μπορώ να διορθώσω το ITMS-90034 με απομακρυσμένη ενημέρωση;

Όχι. Η υπογραφή είναι μέρος του binary, και το build που απορρίφθηκε δεν θα είναι ποτέ χρησιμοποιήσιμο. Πρέπει να φτιάξεις νέο binary σωστά υπογεγραμμένο και να το ξαναστείλεις.

Γιατί το σφάλμα αναφέρει το widget μου και όχι την εφαρμογή;

Επειδή το widget είναι ξεχωριστό bundle, υπογεγραμμένο με δικό του profile. Αν δεν είναι δηλωμένο στο EAS ή υπογράφηκε αλλιώς, αποτυγχάνει όλη η αποστολή. Δήλωσε το extension στη ρύθμισή σου και φτιάξε νέο build.

Τι κάνω αν το codesign λέει ότι όλα είναι έγκυρα;

Έλεγξε επίσης το ενσωματωμένο profile και κάθε extension. Αν όλα είναι καθαρά, ξαναστείλε μία φορά με νέο build number. Αν το σφάλμα επιμένει, στείλε αναφορά στην Apple με το IPA, την έξοδο του codesign και τα logs της αποστολής.