# ITMS-90034: betulkan “Missing or invalid signature”

> ITMS-90034: build anda tidak ditandatangani dengan sijil pengedaran yang sah. Semak dengan codesign, kemudian buat semula build store dengan EAS.

Halaman asal: [ITMS-90034: betulkan “Missing or invalid signature”](https://devoria.fr/ms/blog/itms-90034-missing-invalid-signature)
Pengarang: [Mehdi Azizi](https://devoria.fr/ms/mehdi-azizi)
Diterbitkan: 2026-11-04
Semakan kandungan terakhir: 2026-11-04


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](https://devoria.fr/ms/blog/sijil-pembangun-ios-provisioning-profile-expo). 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](https://developer.apple.com/help/account/certificates/certificates-overview) 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?**

```bash
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](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates), 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?**

```bash
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?**

```bash
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](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles). 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?**

```bash
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`:

```bash
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](https://docs.expo.dev/build/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**:

```bash
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](https://docs.expo.dev/build-reference/app-extensions/) 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](https://developer.apple.com/support/certificates/) 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](https://devoria.fr/ms/blog/sijil-pembangun-ios-provisioning-profile-expo).

### Binari diubah selepas ditandatangani

Tandatangan memeterai kod, sumber dan metadata menggunakan cincangan, seperti yang dijelaskan dalam [nota TN3126 Apple](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes). 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](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-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](https://devoria.fr/ms/blog/kunci-api-rahsia-aplikasi-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](https://devoria.fr/ms/blog/itms-90725-sdk-version-issue-expo) untuk versi Xcode atau [ITMS-90683](https://devoria.fr/ms/blog/itms-90683-missing-purpose-string-expo) untuk ayat kebenaran. Proses lengkap daripada build hingga penghantaran, tanpa Mac, ada dalam [terbitkan app iOS tanpa Mac](https://devoria.fr/ms/blog/terbitkan-aplikasi-ios-tanpa-mac-expo-eas).

Penolakan oleh reviewer memerlukan pendekatan yang lebih teliti: caranya ada di halaman [app ditolak oleh Apple](https://devoria.fr/ms/expertise/aplikasi-ditolak-apple), dan sebab paling biasa ada dalam [kenapa Apple menolak app](https://devoria.fr/ms/blog/aplikasi-ditolak-apple-5-kes-sebenar).

Untuk menyemak fail anda sebelum menghantar, [Review Kit](https://devoria.fr/ms/kits/app-review) 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](https://devoria.fr/ms/coaching): kita semak projek anda melalui panggilan video, pada skrin anda. Dan kalau anda sedang bersedia untuk pelancaran pertama, [buat diagnostik percuma anda](https://devoria.fr/ms/diagnostic): 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.


## Projek anda

[Review Kit](https://devoria.fr/ms/kits/app-review): Senarai semak review App Store saya, penolakan Apple yang telah saya betulkan, senarai semak Google Play dan tiga skill Claude Code. RM 219.

[iOS & Android Kit](https://devoria.fr/ms/kits/ios): Bina app iPhone dan Android anda dengan Claude Code: kod permulaan app saya, laluan hingga ke store dan semua kit. RM 449.

[Diagnostik: apa yang memisahkan anda daripada app iPhone anda](https://devoria.fr/ms/diagnostic): 7 soalan, 60 saat: anda tahu apa yang benar-benar menghalang anda menerbitkan app iPhone, laluan 4 langkah anda dan kit yang sesuai dengan anda.