ITMS-90034: Missing or invalid signature -virheen korjaus

ITMS-90034 tulee vastaan, kun lähetät buildin App Store Connectiin. Virhe kertoo, että sovellustasi tai jotain sen osaa ei ole allekirjoitettu Applen lähetysvarmenteella eli voimassa olevalla jakeluvarmenteella. Korjaus: selvitä, mikä bundle on allekirjoitettu väärin ja miksi, ja tee sitten uusi App Storea varten allekirjoitettu build.

Tämä opas keskittyy pelkkään virheeseen. Jos sanat varmenne ja profiili ovat sinulle epäselviä, lue ensin iOS-kehittäjävarmenne ja provisioning profile. Täältä löydät luettavan viestin, päätöspuun, komennot IPA:n tutkimiseen ja korjauksen EAS:n hallinnoimilla tunnuksilla. EAS-osuutta varten luin EAS CLI 24.10.0:n koodin, joka valitsee varmenteen.

Mitä virhe ITMS-90034 tarkoittaa?

Tässä sen tavallinen muoto esimerkkinimillä:

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.

Vuonna 2026 se näkyy Applen foorumilla myös muodossa "Validation failed (409) Missing or invalid signature", jota seuraa sama teksti ja "(ID: 90034)".

"Lähetysvarmenne" on jakeluvarmenne. Applen varmenneohje sanoo sen suoraan: kehitysvarmenteilla ajat sovellusta omilla laitteillasi, jakeluvarmenteilla jaat sen tai lähetät sen App Store Connectiin.

Lue viestissä mainittu polku: se osoittaa vialliseen bundleen. Payload/MyApp.app tarkoittaa itse sovellusta. Polku, joka päättyy .appex, tarkoittaa laajennusta, kuten widgetiä. Polku, joka päättyy .framework, tarkoittaa mukana olevaa kirjastoa.

Kyse ei ole reviewerin hylkäyksestä. Validointi kaatuu lähetyksessä tai buildin käsittelyn aikana, ennen TestFlightia: tämä build ei koskaan päädy testaajillesi.

Päätöspuu: viestistä korjaukseen

Jokainen rivi vastaa vihjettä, jonka luet viestistä, seuraavan osion komennoista tai EAS:n lokeista. Käy ne läpi järjestyksessä: ensimmäinen osuva rivi näyttää suunnan.

Mitä havaitset	Todennäköinen syy	Korjaus
Polku päättyy .appex	Laajennus väärin allekirj.	Ilmoita laajennus
Signature=adhoc	Allekirjoittamaton build	Build store-profiililla
Apple Development	Kehitysbuild	Build store-profiililla
ProvisionedDevices löytyy	Sisäinen build (ad hoc)	Build store-profiililla
sealed resource	IPA:ta muokattu jälkikäteen	Tee build uudelleen
EAS: "no longer valid"	Varmenne mitätöity	Uusi varmenne
Kaikki on kunnossa	Häiriö Applen päässä	Lähetä uudelleen, ilmoita

Tutki IPA:si neljällä komennolla

Lataa IPA buildin sivulta expo.devissä ja avaa pääte Macillasi.

1. Kuka allekirjoitti sovelluksen?

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

codesign kirjoittaa virhetulosteeseen, siksi 2>&1. Applen teknisen muistion TN3161 mukaan jokainen Authority-rivi on luottamusketjun lenkki. Ensimmäisen pitää alkaa Apple Distribution: tai iPhone Distribution: ja jatkua tiimisi nimellä. Jälkimmäinen on vanhan iOS Distribution -tyypin nimi: koodinsa perusteella EAS CLI 24.10.0 luo yhä tämän tyypin varmenteita. Jos näet Apple Development:, kyseessä on kehitysbuild. Jos näet Signature=adhoc ilman yhtään Authority-riviä, binääriä ei ole allekirjoitettu millään varmenteella.

2. Onko sovellusta muokattu allekirjoituksen jälkeen?

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

Haluat nähdä valid on disk ja sen jälkeen satisfies its Designated Requirement. TN3161 kertoo, mitä tarkistus takaa: kaikki odotetut tiedostot ovat paikallaan, yhtään ei ole lisätty eikä yhtään muokattu. Testibundlessa, jonka allekirjoitin ja sitten muokkasin, komento vastasi a sealed resource is missing or invalid ja sen jälkeen file modified: sekä muutetun tiedoston. Valitsin --deep on tässä tarkistusta varten, ei koskaan allekirjoitusta: Applen foorumilla tukitiimin insinööri neuvoo olemaan käyttämättä sitä allekirjoittamiseen.

3. Mikä profiili on mukana?

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

Nämä ovat profiileja käsittelevän muistion TN3125 komennot. App Store -profiilissa ei ole laiteluetteloa: toisen rivin pitää vastata Could not extract value. Jos se näyttää laitetunnisteita, kyseessä on ad hoc -profiili eli sisäisen buildin profiili. Kolmas rivi kertoo profiilin vanhenemispäivän.

4. Onko laajennukset ja frameworkit allekirjoitettu samalla tavalla?

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

Jokaisen osan pitää näyttää sama Authority-rivi kuin sovelluksen. Jos jokin poikkeaa, viesti mainitsee juuri sen.

Jos haluat tarkistaa ennen lähetystä, TN3161 suosittelee altoolia, joka tekee saman tarkistuksen kuin Xcoden Validate App -painike. Se vaatii App Store Connect -API-avaimen, jonka tiedosto AuthKey_<KEY_ID>.p8 sijoitetaan kansioon ~/.appstoreconnect/private_keys:

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

Korjaa EAS:llä syy kerrallaan

Sisäinen build tai kehitysbuild lähetetty Applelle

Expon eas.json-dokumentaation mukaan buildeja, joissa on "distribution": "internal", ei allekirjoiteta kauppoja varten: ne käyttävät ad hoc -profiilia. Vain store-jakelun profiili, joka on oletus, tuottaa lähetyskelpoisen buildin. Varminta on lähettää juuri rakentamasi build valitsematta sitä käsin:

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

Jos käytät eas submit --path, tarkista, että tiedosto on varmasti viimeisin store-buildisi. Applen foorumilla eräs tiimi huomasi, että sen lähetystyökalu lähetti joka kerta vanhan, gitiin versioidun IPA:n.

Unohtunut laajennus

Jokainen laajennus on oma bundlensa, jolla on oma tunnisteensa ja oma profiilinsa. Expo-projektissa, jossa natiivikoodi generoidaan, Expon iOS-laajennussivu neuvoo ilmoittamaan ne kohdassa extra.eas.build.experimental.ios.appExtensions. Silloin EAS CLI tuntee ne ennen buildia ja luo tai validoi niiden tunnukset. Useimmat laajennuksen lisäävät kirjastot kirjoittavat tämän määrittelyn puolestasi pluginillaan.

Solys, minigameja sisältävä herätyskelloni, sisältää neljä laajennusta: widgetin ja kolme Ruutuaika-laajennusta. Kaikki neljä on ilmoitettu sen konfiguraatiossa, ja EAS:llä on profiili jokaiselle. Xcodessa käsin lisätty laajennus ilman tätä määrittelyä on ihanteellinen epäilty, kun viestin polku päättyy .appex.

Mitätöity tai vanhentunut varmenne

Applen varmennesivu on selvä: et voi enää lähettää buildia, joka on allekirjoitettu vanhentuneella tai mitätöidyllä varmenteella. Jo lähetetty mutta vielä arvioon lähettämätön build voi jopa siirtyä tilaan Invalid Binary, jos sen varmenne on mitätöity.

EAS CLI 24.10.0:n koodi näyttää, milloin tämä jää huomaamatta:

• Interaktiivinen build, kirjautuneena Appleen: EAS vertaa varmennettaan Applella yhä voimassa oleviin. Jos sitä ei enää löydy, se näyttää "Current distribution certificate is no longer valid in Apple Dev Portal" ja tarjoaa valita tai luoda uuden.
• Interaktiivinen build ilman kirjautumista: EAS tarkistaa vain päivämäärät ja varoittaa ohittavansa validoinnin Applella.
• Ei-interaktiivinen build jatkuvassa integraatiossa: EAS näyttää "Distribution Certificate is not validated for non-interactive builds" ja allekirjoittaa silti.

Jatkuvassa integraatiossa EAS ei tarkista itse varmennetta uudelleen: mitätöinti voi paljastua vasta lähetyksessä. Korjaus: aja interaktiivinen build kirjautuneena Apple-tilillesi tai käytä komentoa eas credentials --platform ios, valikkoa Build Credentials ja sitten "Distribution Certificate: Add a new one to your account". Profiilit, joissa vanha varmenne oli, muuttuvat virheellisiksi: EAS tarkistaa ne seuraavassa buildissa ja tekee ne uudelleen. Applen rajat varmenteiden määrälle on kuvattu iOS-kehittäjävarmenteen oppaassa.

Allekirjoituksen jälkeen muokattu binääri

Allekirjoitus sinetöi koodin, resurssit ja metatiedot tiivisteillä, kuten Applen muistio TN3126 selittää. Jos purat IPA:n muuttaaksesi tiedostoa ja pakkaat sen uudelleen, sinetti rikkoutuu. Tee muutos konfiguraatioon ja tee sitten uusi build. Älä koskaan muokkaa EAS:n tuottamaa IPA:ta.

Sama pätee koodiin, joka on väärässä paikassa, esimerkiksi .zip-arkistossa: App Store ei voi allekirjoittaa sitä uudelleen. Apple kuvaa sallitut sijainnit sivullaan bundlen sisällöstä.

Paikalliset tunnukset

Jos EAS-profiilisi käyttää asetusta "credentialsSource": "local", credentials.json-tiedostosi osoittaa .p12-varmenteeseen ja .mobileprovision-profiiliin. Tarkista profiili vaiheen 3 komennoilla: sen pitää olla App Store -tyyppinen ja sisältää nykyinen jakeluvarmenteesi. Ja pidä nämä tiedostot poissa repositoriosta, kuten Expo-sovelluksen API-avaimet.

Kun kaikki on kunnossa

Jäljellä on yksi turhauttava tapaus. Applen foorumilla jotkut kehittäjät näkevät virheen katoavan, kun he lähettävät saman buildin uudelleen muuttamatta mitään. Elo- ja syyskuussa 2026 kaksi ketjua kuvasi päinvastaista: uusi varmenne ja profiili, tarkistettu allekirjoitus, silti jatkuva epäonnistuminen. Toisessa niistä Applen insinööri neuvoi tekemään bugiraportin, jossa on IPA, allekirjoitusanalyysi ja Transporterin lokit, ja ottamaan sitten yhteyttä App Store Connectiin.

Lähetä siis kerran uudelleen uudella build-numerolla. Jos virhe palaa, vaikka neljä komentoasi näyttävät puhdasta, ilmoita siitä Applelle näiden tietojen kanssa. Älä mitätöi varmennettasi refleksinä: se ei ratkaise mitään ylimääräistä ja tekee profiileistasi virheellisiä.

Lähetä buildisi ilman ikäviä yllätyksiä

Allekirjoituksen tarkistaa kahdessa minuutissa ennen lähetystä. Muut automaattiset tarkistukset vaativat samaa huolellisuutta, kuten ITMS-90725 Xcoden version osalta tai ITMS-90683 lupatekstien osalta. Koko polku buildista lähetykseen ilman Macia löytyy oppaasta iOS-sovelluksen julkaisu ilman Macia.

Reviewerin hylkäykset vaativat enemmän harkintaa: toimintatapa on sivulla Applen hylkäämä sovellus, ja yleisimmät syyt artikkelissa miksi Apple hylkää sovelluksen.

Jos haluat tarkistaa kokonaisuuden ennen lähetystä, Review Kit sisältää tarkistuslistani ja Claude Code -skillejä, jotka käyvät projektisi läpi. Jos lähetyksesi jumittaa ja haluat ihmisen näkemyksen, varaa tunti kanssani: käymme projektisi läpi videopuhelussa, sinun ruudullasi. Ja jos valmistelet ensimmäistä julkaisuasi, tee ilmainen diagnoosi: se laittaa vaiheet oikeaan järjestykseen ja lähettää sinulle tarkistuslistani Applen hylkäysten välttämiseen.

Usein kysytyt kysymykset

Onko ITMS-90034 App Review -hylkäys?

Ei. Se on automaattinen validointi, joka tehdään buildin lähetyksessä, ennen TestFlightia ja ennen mitään arviointia. Kukaan ei ole avannut sovellustasi: Apple on vain todennut, ettei sen allekirjoitus tule voimassa olevasta jakeluvarmenteesta.

Pitääkö jakeluvarmenne mitätöidä ITMS-90034:n korjaamiseksi?

Vain jos se on vaarantunut tai jo virheellinen. Toimivan varmenteen mitätöinti tekee profiileistasi virheellisiä korjaamatta syytä. Lue ensin IPA:si allekirjoitus codesign-komennolla ja korjaa sitten se, mihin päätöspuu osoittaa.

Voiko ITMS-90034:n korjata etäpäivityksellä?

Ei. Allekirjoitus on osa binääriä, eikä hylättyä buildia voi koskaan käyttää. Sinun pitää tuottaa uusi, oikein allekirjoitettu binääri ja lähettää se uudelleen.

Miksi virhe mainitsee widgetini eikä sovellustani?

Koska widget on oma bundlensa, joka allekirjoitetaan omalla profiilillaan. Jos sitä ei ole ilmoitettu EAS:lle tai se on allekirjoitettu toisin, se kaataa koko lähetyksen. Ilmoita laajennus konfiguraatiossasi ja tee uusi build.

Mitä teen, jos codesign sanoo kaiken olevan kunnossa?

Tarkista myös mukana oleva profiili ja jokainen laajennus. Jos kaikki on puhdasta, lähetä kerran uudelleen uudella build-numerolla. Jos virhe jatkuu, lähetä Applelle raportti, jossa on IPA, codesign-komennon tuloste ja lähetyksen lokit.