ITMS-90034: betulkan “Missing or invalid signature”

ITMS-90034 muncul semasa anda menghantar build ke App Store Connect. Ia bermaksud app anda, atau salah satu komponennya, tidak ditandatangani dengan sijil penghantaran Apple, iaitu sijil pengedaran yang sah. Cara membetulkannya: cari bundle mana yang salah tandatangan dan sebabnya, kemudian buat semula build yang ditandatangani untuk App Store.

Panduan ini fokus pada ralat itu sahaja. Kalau istilah sijil dan profil masih kabur bagi anda, baca dulu sijil pembangun iOS dan provisioning profile. Di sini anda akan jumpa mesej yang perlu dibaca, pokok keputusan, arahan untuk memeriksa IPA anda dan cara membetulkannya dengan kelayakan yang diurus oleh EAS. Untuk bahagian EAS, saya sudah baca kod EAS CLI 24.10.0 yang memilih sijil.

Apakah maksud ralat ITMS-90034?

Ini bentuk biasanya, dengan nama contoh:

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.

Pada 2026, di forum Apple, ia juga muncul dalam bentuk "Validation failed (409) Missing or invalid signature", diikuti teks yang sama dan "(ID: 90034)".

"Sijil penghantaran" itu ialah sijil pengedaran. Bantuan Apple tentang sijil menyatakannya: sijil pembangunan digunakan untuk menjalankan app pada peranti anda, sijil pengedaran pula untuk mengedarkannya atau menghantarnya ke App Store Connect.

Baca laluan yang disebut: ia menunjukkan bundle yang bermasalah. Payload/MyApp.app merujuk kepada app itu sendiri. Laluan yang berakhir dengan .appex merujuk kepada sambungan, contohnya widget. Laluan .framework merujuk kepada pustaka terbenam.

Ini bukan penolakan oleh reviewer. Pengesahan ini gagal semasa penghantaran atau semasa build diproses, sebelum TestFlight: build ini tidak akan sampai kepada penguji anda.

Pokok keputusan: daripada mesej kepada pembetulan

Setiap baris mewakili petunjuk yang anda baca dalam mesej, dalam arahan di bahagian seterusnya atau dalam log EAS. Ikut susunannya: baris pertama yang sepadan memberi arah anda.

Apa yang anda lihat	Punca kemungkinan	Pembetulan
Laluan .appex	Sambungan salah tandatangan	Isytiharkan sambungan
Signature=adhoc	Build tidak ditandatangani	Build profil store
Apple Development	Build pembangunan	Build profil store
ProvisionedDevices ada	Build dalaman (ad hoc)	Build profil store
sealed resource	IPA diubah selepas itu	Buat semula build
EAS: "no longer valid"	Sijil dibatalkan	Sijil baharu
Semuanya sah	Masalah di pihak Apple	Hantar semula, kemudian lapor

Periksa IPA anda dengan empat arahan

Muat turun IPA daripada halaman build di expo.dev, kemudian buka terminal pada Mac anda.

1. Siapa yang menandatangani app?

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

codesign menulis ke output ralat, sebab itu ada 2>&1. Menurut nota teknikal TN3161 Apple, setiap baris Authority ialah satu mata rantai dalam rantaian kepercayaan. Baris pertama mesti bermula dengan Apple Distribution: atau iPhone Distribution:, diikuti nama pasukan anda. Label kedua itu ialah label jenis lama iOS Distribution: berdasarkan kodnya, EAS CLI 24.10.0 masih mencipta sijil jenis ini. Kalau anda nampak Apple Development:, itu build pembangunan. Kalau anda nampak Signature=adhoc tanpa sebarang baris Authority, binari itu tidak ditandatangani oleh mana-mana sijil.

2. Adakah app diubah selepas ditandatangani?

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

Anda mahu nampak valid on disk, kemudian satisfies its Designated Requirement. TN3161 menjelaskan apa yang dijamin oleh semakan ini: semua fail yang dijangka ada, tiada fail ditambah, tiada fail diubah. Pada bundle ujian yang saya tandatangani lalu ubah, arahan ini menjawab a sealed resource is missing or invalid, kemudian file modified: diikuti fail yang diubah. Pilihan --deep di sini hanya untuk menyemak, jangan sekali-kali untuk menandatangani: di forum Apple, seorang jurutera pasukan sokongan tidak menggalakkannya untuk menandatangani.

3. Profil mana yang terbenam?

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

Ini arahan daripada nota TN3125 tentang profil. Profil App Store tidak mengandungi senarai peranti: baris kedua mesti menjawab Could not extract value. Kalau ia memaparkan pengecam peranti, itu profil ad hoc, iaitu profil build dalaman. Baris ketiga memberi tarikh luput profil.

4. Adakah sambungan dan framework ditandatangani dengan cara yang sama?

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

Setiap komponen mesti memaparkan baris Authority yang sama dengan app. Kalau ada yang berbeza, itulah yang disebut dalam mesej.

Kalau anda mahu menyemak sebelum menghantar, TN3161 mengesyorkan altool, semakan yang sama dengan butang Validate App dalam Xcode. Ia memerlukan kunci API App Store Connect, dan fail AuthKey_<ID_CLE>.p8 disimpan dalam ~/.appstoreconnect/private_keys:

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

Betulkan dengan EAS, mengikut punca

Build dalaman atau pembangunan dihantar ke Apple

Menurut dokumentasi Expo tentang eas.json, build dengan "distribution": "internal" tidak ditandatangani untuk store: ia menggunakan profil ad hoc. Hanya profil dengan pengedaran store, nilai lalai, yang menghasilkan build boleh dihantar. Cara paling selamat ialah menghantar build yang baru anda bina, tanpa memilihnya secara manual:

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

Kalau anda guna eas submit --path, pastikan fail itu memang build store terbaharu anda. Di forum Apple, satu pasukan mendapati alat penghantaran mereka asyik menghantar IPA lama yang disimpan dalam git.

Sambungan yang terlupa

Setiap sambungan ialah bundle tersendiri, dengan pengecam dan profilnya sendiri. Dalam projek Expo yang menjana kod natif, halaman Expo tentang sambungan iOS meminta anda mengisytiharkannya dalam extra.eas.build.experimental.ios.appExtensions. EAS CLI kemudian mengenalinya sebelum build, dan mencipta atau mengesahkan kelayakannya. Kebanyakan pustaka yang menambah sambungan menulis pengisytiharan ini untuk anda melalui plugin mereka.

Solys, jam loceng saya dengan permainan mini, mengandungi empat sambungan: satu widget dan tiga sambungan Masa Skrin. Keempat-empatnya diisytiharkan dalam konfigurasinya, dan EAS ada profil untuk setiap satu. Sambungan yang ditambah secara manual dalam Xcode, tanpa pengisytiharan ini, ialah calon utama untuk laluan .appex dalam mesej.

Sijil yang dibatalkan atau luput

Halaman Apple tentang sijil jelas: anda tidak boleh lagi menghantar build yang ditandatangani dengan sijil yang luput atau dibatalkan. Build yang sudah dihantar tetapi belum diserahkan malah boleh bertukar menjadi Invalid Binary jika sijilnya dibatalkan.

Kod EAS CLI 24.10.0 menunjukkan bila kes ini terlepas pandang:

• Build interaktif, disambungkan ke Apple: EAS membandingkan sijilnya dengan sijil yang masih sah di Apple. Kalau sudah tiada, ia memaparkan "Current distribution certificate is no longer valid in Apple Dev Portal" dan mencadangkan anda memilih atau mencipta satu.
• Build interaktif, tanpa sambungan: EAS hanya menyemak tarikh dan memberi amaran bahawa ia melangkau pengesahan di Apple.
• Build tidak interaktif, dalam integrasi berterusan: EAS memaparkan "Distribution Certificate is not validated for non-interactive builds" dan tetap menandatangani.

Dalam integrasi berterusan, EAS tidak menyemak semula sijil itu sendiri: pembatalan mungkin hanya kelihatan semasa penghantaran. Pembetulannya: jalankan build interaktif yang disambungkan ke akaun Apple anda, atau guna eas credentials --platform ios, menu Build Credentials, kemudian "Distribution Certificate: Add a new one to your account". Profil yang mengandungi sijil lama menjadi tidak sah: EAS menyemaknya pada build seterusnya dan membuatnya semula. Had Apple tentang bilangan sijil diterangkan dalam panduan sijil pembangun iOS.

Binari diubah selepas ditandatangani

Tandatangan memeterai kod, sumber dan metadata menggunakan cincangan, seperti yang dijelaskan dalam nota TN3126 Apple. Menyahmampat IPA untuk mengubah fail, kemudian memampatnya semula, akan memecahkan meterai ini. Buat perubahan dalam konfigurasi anda, kemudian buat semula build. Jangan sekali-kali mengubah IPA yang dihasilkan oleh EAS.

Logik yang sama untuk kod yang diletakkan di tempat yang salah, contohnya dalam arkib .zip: App Store tidak boleh menandatanganinya semula. Apple menerangkan lokasi yang dibenarkan dalam halamannya tentang kandungan bundle.

Kelayakan tempatan

Kalau profil EAS anda menggunakan "credentialsSource": "local", fail credentials.json anda menunjuk kepada sijil .p12 dan profil .mobileprovision. Semak profil itu dengan arahan langkah 3: ia mesti jenis App Store dan mengandungi sijil pengedaran semasa anda. Dan simpan fail ini di luar repositori, sama seperti kunci API app Expo.

Apabila semuanya sah

Ada satu kes yang mengecewakan. Di forum Apple, ada pembangun yang melihat ralat hilang selepas menghantar semula build yang sama, tanpa mengubah apa-apa. Pada Ogos dan September 2026, dua bebenang menerangkan sebaliknya: sijil dan profil baharu, tandatangan disahkan, tetapi kegagalan berterusan. Dalam salah satunya, seorang jurutera Apple mencadangkan laporan pepijat bersama IPA, analisis tandatangan dan log Transporter, kemudian menghubungi App Store Connect.

Jadi, hantar semula sekali dengan nombor build baharu. Kalau ralat kembali sedangkan empat arahan anda bersih, laporkan kepada Apple dengan bahan-bahan ini. Jangan batalkan sijil anda secara refleks: ia tidak menyelesaikan apa-apa dan menjadikan profil anda tidak sah.

Hantar build anda tanpa kejutan

Tandatangan boleh disemak dalam dua minit sebelum penghantaran. Semakan automatik lain memerlukan ketelitian yang sama, seperti ITMS-90725 untuk versi Xcode atau ITMS-90683 untuk ayat kebenaran. Proses lengkap daripada build hingga penghantaran, tanpa Mac, ada dalam terbitkan app iOS tanpa Mac.

Penolakan oleh reviewer memerlukan pendekatan yang lebih teliti: caranya ada di halaman app ditolak oleh Apple, dan sebab paling biasa ada dalam kenapa Apple menolak app.

Untuk menyemak fail anda sebelum menghantar, Review Kit menghimpunkan senarai semak saya dan skill Claude Code yang menyemak projek anda. Kalau penghantaran anda tersekat dan anda mahukan pandangan manusia, tempah satu jam dengan saya: kita semak projek anda melalui panggilan video, pada skrin anda. Dan kalau anda sedang bersedia untuk pelancaran pertama, buat diagnostik percuma anda: ia menyusun langkah-langkah mengikut urutan dan menghantar senarai semak anti-penolakan Apple saya kepada anda.

Soalan lazim

Adakah ITMS-90034 penolakan App Review?

Tidak. Ia pengesahan automatik yang dibuat semasa build dihantar, sebelum TestFlight dan sebelum sebarang semakan. Tiada sesiapa yang membuka app anda: Apple hanya mendapati tandatangannya bukan daripada sijil pengedaran yang sah.

Perlukah saya membatalkan sijil pengedaran untuk membetulkan ITMS-90034?

Hanya jika ia terjejas atau sudah tidak sah. Membatalkan sijil yang berfungsi akan menjadikan profil anda tidak sah tanpa membetulkan punca. Mulakan dengan membaca tandatangan IPA anda menggunakan codesign, kemudian betulkan apa yang ditunjukkan oleh pokok keputusan.

Bolehkah ITMS-90034 dibetulkan dengan kemas kini jarak jauh?

Tidak. Tandatangan ialah sebahagian daripada binari, dan build yang ditolak tidak akan boleh digunakan. Anda perlu menghasilkan binari baharu yang ditandatangani dengan betul dan menghantarnya semula.

Kenapa ralat menyebut widget saya dan bukan app saya?

Kerana widget ialah bundle tersendiri, ditandatangani dengan profilnya sendiri. Kalau ia tidak diisytiharkan kepada EAS atau ditandatangani dengan cara lain, ia menggagalkan keseluruhan penghantaran. Isytiharkan sambungan dalam konfigurasi anda dan buat semula build.

Apa perlu dibuat jika codesign mengatakan semuanya sah?

Semak juga profil terbenam dan setiap sambungan. Kalau semuanya bersih, hantar semula sekali dengan nombor build baharu. Kalau ralat berterusan, hantar laporan kepada Apple bersama IPA, output codesign dan log penghantaran.