ITMS-90034 hatası: “Missing or invalid signature” çözümü

ITMS-90034, build'ini App Store Connect'e gönderdiğinde çıkar. Uygulamanın ya da bileşenlerinden birinin bir Apple gönderim sertifikasıyla, yani geçerli bir dağıtım sertifikasıyla imzalanmadığını söyler. Çözüm: hangi bundle'ın hatalı imzalandığını ve nedenini bul, sonra App Store için imzalanmış yeni bir build al.

Bu rehber hataya odaklanıyor. Sertifika ve profil kavramları sana bulanık geliyorsa önce iOS geliştirici sertifikası ve provisioning profile yazısını oku. Burada okunacak mesajı, bir karar ağacını, IPA'nı inceleyen komutları ve EAS'in yönettiği kimlik bilgileriyle çözümü bulacaksın. EAS kısmı için sertifikayı seçen EAS CLI 24.10.0 kodunu okudum.

ITMS-90034 hatası ne anlama geliyor?

Klasik hali şöyle, örnek isimlerle:

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'da Apple forumunda "Validation failed (409) Missing or invalid signature" şeklinde de görünüyor, ardından aynı metin ve "(ID: 90034)" geliyor.

"Gönderim sertifikası" dağıtım sertifikası demek. Apple'ın sertifikalarla ilgili yardım sayfası bunu açıkça yazıyor: geliştirme sertifikaları uygulamanı kendi cihazlarında çalıştırmaya, dağıtım sertifikaları ise uygulamayı dağıtmaya ya da App Store Connect'e göndermeye yarar.

Mesajdaki yolu oku: hatalı bundle'ı o gösteriyor. Payload/MyApp.app uygulamanın kendisini işaret eder. .appex ile biten bir yol, widget gibi bir eklentiyi işaret eder. .framework ile biten bir yol ise gömülü bir kütüphaneyi.

Bu bir reviewer reddi değil. Doğrulama gönderim sırasında ya da build işlenirken, TestFlight'tan önce düşer: bu build test kullanıcılarına asla ulaşmaz.

Karar ağacı: mesajdan çözüme

Her satır, mesajda, bir sonraki bölümdeki komutlarda ya da EAS loglarında okuduğun bir ipucuna karşılık geliyor. Sırayla ilerle: eşleşen ilk satır sana yolu gösterir.

Gördüğün	Olası neden	Çözüm
.appex ile biten yol	Hatalı imzalı eklenti	Eklentiyi tanımla
Signature=adhoc	İmzasız build	Store profiliyle build
Apple Development	Geliştirme build'i	Store profiliyle build
ProvisionedDevices var	Dahili (ad hoc) build	Store profiliyle build
sealed resource	Sonradan değiştirilmiş IPA	Build'i yeniden al
EAS: "no longer valid"	İptal edilmiş sertifika	Yeni sertifika
Her şey geçerli	Apple tarafında sorun	Yeniden gönder, sonra bildir

IPA'nı dört komutla incele

IPA'yı expo.dev'deki build sayfasından indir, sonra Mac'inde bir terminal aç.

1. Uygulamayı kim imzalamış?

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

codesign hata çıktısına yazar, 2>&1 bu yüzden var. Apple'ın TN3161 teknik notuna göre her Authority satırı güven zincirinin bir halkası. İlki Apple Distribution: ya da iPhone Distribution: ile başlamalı, ardından ekibinin adı gelmeli. İkinci etiket eski iOS Distribution tipine ait: koduna göre EAS CLI 24.10.0 hâlâ bu tipte sertifika oluşturuyor. Apple Development: görüyorsan bu bir geliştirme build'i. Hiç Authority satırı olmadan Signature=adhoc görüyorsan, binary hiçbir sertifikayla imzalanmamış.

2. Uygulama imzadan sonra değiştirilmiş mi?

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

Görmek istediğin şey valid on disk, ardından satisfies its Designated Requirement. TN3161 bu kontrolün neyi garanti ettiğini belirtiyor: beklenen tüm dosyalar yerinde, hiçbiri eklenmemiş, hiçbiri değiştirilmemiş. İmzalayıp sonra üzerinde oynadığım bir test bundle'ında komut a sealed resource is missing or invalid, ardından file modified: ve değişen dosyayı yazdı. --deep seçeneği burada sadece doğrulamak için, asla imzalamak için değil: Apple forumunda destek ekibinden bir mühendis imzalarken kullanılmamasını öneriyor.

3. Hangi profil gömülü?

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

Bunlar profillerle ilgili TN3125 notundaki komutlar. Bir App Store profili hiçbir cihaz listesi içermez: ikinci satır Could not extract value demeli. Cihaz kimlikleri gösteriyorsa bu bir ad hoc profil, yani dahili bir build'in profili. Üçüncü satır profilin son kullanma tarihini verir.

4. Eklentiler ve framework'ler aynı şekilde mi imzalanmış?

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

Her bileşen uygulamayla aynı Authority satırını göstermeli. Biri farklıysa mesajın andığı odur.

Göndermeden önce kontrol etmek istersen TN3161 altool'u öneriyor; Xcode'daki Validate App düğmesiyle aynı kontrol. Bir App Store Connect API anahtarı ister, AuthKey_<ID_CLE>.p8 dosyası ~/.appstoreconnect/private_keys içine konur:

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

EAS ile neden neden çözmek

Apple'a gönderilen dahili ya da geliştirme build'i

Expo'nun eas.json dokümantasyonuna göre "distribution": "internal" build'leri store'lar için imzalanmaz: ad hoc profil kullanırlar. Sadece store dağıtımlı bir profil (varsayılan değer) gönderilebilir bir build üretir. En güvenlisi, az önce aldığın build'i elle seçmeden göndermek:

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

eas submit --path kullanıyorsan, dosyanın gerçekten son store build'in olduğunu kontrol et. Apple forumunda bir ekip, gönderim aracının her seferinde git'te versiyonlanmış eski bir IPA gönderdiğini fark etmiş.

Unutulmuş bir eklenti

Her eklenti kendi tanımlayıcısı ve kendi profili olan ayrı bir bundle'dır. Native kodu otomatik üretilen bir Expo projesinde, Expo'nun iOS eklentileri sayfası bunları extra.eas.build.experimental.ios.appExtensions içinde tanımlamanı istiyor. Böylece EAS CLI onları build'den önce tanır, kimlik bilgilerini oluşturur ya da doğrular. Eklenti ekleyen kütüphanelerin çoğu bu tanımı plugin'leri aracılığıyla senin yerine yazar.

Mini oyunlu alarm uygulamam Solys dört eklenti içeriyor: bir widget ve üç Ekran Süresi eklentisi. Dördü de yapılandırmada tanımlı ve EAS'in her biri için bir profili var. Bu tanım olmadan Xcode'da elle eklenmiş bir eklenti, mesajdaki .appex ile biten bir yolun en güçlü şüphelisidir.

İptal edilmiş ya da süresi dolmuş bir sertifika

Apple'ın sertifikalar sayfası net: süresi dolmuş ya da iptal edilmiş bir sertifikayla imzalanmış build'i artık gönderemezsin. Gönderilmiş ama henüz incelemeye sunulmamış bir build, sertifikası iptal edilirse Invalid Binary durumuna bile geçebilir.

EAS CLI 24.10.0 kodu bu durumun ne zaman fark edilmediğini gösteriyor:

• Etkileşimli build, Apple'a bağlı: EAS sertifikasını Apple'da hâlâ geçerli olanlarla karşılaştırır. Orada yoksa "Current distribution certificate is no longer valid in Apple Dev Portal" yazar ve birini seçmeni ya da oluşturmanı önerir.
• Etkileşimli build, bağlantısız: EAS sadece tarihleri kontrol eder ve Apple'daki doğrulamayı atladığını söyler.
• Etkileşimsiz build, sürekli entegrasyonda: EAS "Distribution Certificate is not validated for non-interactive builds" yazar ve yine de imzalar.

Sürekli entegrasyonda EAS sertifikanın kendisini yeniden kontrol etmez: bir iptal ancak gönderimde fark edilebilir. Çözüm: Apple hesabına bağlı etkileşimli bir build başlat ya da eas credentials --platform ios komutuyla Build Credentials menüsüne, sonra "Distribution Certificate: Add a new one to your account" seçeneğine git. Eski sertifikayı içeren profiller geçersiz olur: EAS bir sonraki build'de onları kontrol edip yeniden oluşturur. Apple'ın sertifika sayısı sınırları iOS geliştirici sertifikası rehberinde ayrıntılı anlatılıyor.

İmzadan sonra değiştirilmiş bir binary

Apple'ın TN3126 notunun açıkladığı gibi imza; kodu, kaynakları ve meta verileri hash'lerle mühürler. Bir dosyayı değiştirmek için IPA'yı açıp sonra yeniden sıkıştırmak bu mührü bozar. Değişikliği yapılandırmanda yap, sonra yeni bir build al. EAS'in ürettiği IPA'ya asla dokunma.

Yanlış yere konmuş kod için de aynı mantık geçerli, örneğin bir .zip arşivinin içine: App Store onu yeniden imzalayamaz. Apple izin verilen konumları bundle içeriği sayfasında anlatıyor.

Yerel kimlik bilgileri

EAS profilin "credentialsSource": "local" kullanıyorsa, credentials.json dosyan bir .p12 sertifikasına ve bir .mobileprovision profiline işaret eder. Profili 3. adımdaki komutlarla kontrol et: App Store tipinde olmalı ve güncel dağıtım sertifikanı içermeli. Bu dosyaları da bir Expo uygulamasının API anahtarları gibi depo dışında tut.

Her şey geçerli olduğunda

Can sıkıcı bir durum daha kalıyor. Apple forumunda bazı geliştiriciler aynı build'i hiçbir şey değiştirmeden yeniden gönderince hatanın kaybolduğunu görüyor. Ağustos ve Eylül 2026'da iki başlık tersini anlatıyor: yeni sertifika ve profil, doğrulanmış imza, ama hata sürüyor. Bunlardan birinde bir Apple mühendisi IPA, imza analizi ve Transporter loglarıyla bir hata raporu açmayı, sonra App Store Connect ile iletişime geçmeyi öneriyor.

Yani yeni bir build numarasıyla bir kez yeniden gönder. Dört komutun temiz çıkmasına rağmen hata geri gelirse bu bilgilerle Apple'a bildir. Sertifikanı refleksle iptal etme: hiçbir şeyi çözmez ve profillerini geçersiz kılar.

Build'ini sürprizsiz gönder

Bir imza göndermeden önce iki dakikada kontrol edilir. Diğer otomatik kontroller de aynı titizliği ister; örneğin Xcode sürümü için ITMS-90725 ya da izin açıklamaları için ITMS-90683. Build'den gönderime kadar Mac olmadan tüm süreç Mac olmadan iOS uygulaması yayınlamak yazısında.

Reviewer retleri daha fazla soğukkanlılık ister: izlenecek yol Apple tarafından reddedilen uygulama sayfasında, en sık nedenler de Apple neden bir uygulamayı reddeder yazısında.

Göndermeden önce dosyanı kontrol etmek için Review Kit, kontrol listemi ve projeni gözden geçiren Claude Code skill'lerini bir araya getiriyor. Gönderimin takıldıysa ve bir insan gözü istiyorsan benimle bir saatlik görüşme ayarla: projeni görüntülü görüşmede, senin ekranında birlikte ele alırız. İlk yayınına hazırlanıyorsan da ücretsiz diagnostiğini yap: adımları sıraya koyar ve sana Apple retlerine karşı kontrol listemi gönderir.

Sık sorulan sorular

ITMS-90034 bir App Review reddi mi?

Hayır. Build gönderilirken, TestFlight'tan ve herhangi bir incelemeden önce yapılan otomatik bir doğrulama. Kimse uygulamanı açmadı: Apple sadece imzasının geçerli bir dağıtım sertifikasından gelmediğini tespit etti.

ITMS-90034'ü düzeltmek için dağıtım sertifikamı iptal etmem gerekir mi?

Sadece ele geçirilmişse ya da zaten geçersizse. Çalışan bir sertifikayı iptal etmek, nedeni düzeltmeden profillerini geçersiz kılar. Önce IPA'nın imzasını codesign ile oku, sonra karar ağacının gösterdiği şeyi düzelt.

ITMS-90034 uzaktan bir güncellemeyle düzeltilebilir mi?

Hayır. İmza binary'nin bir parçası ve reddedilen build asla kullanılamayacak. Doğru imzalanmış yeni bir binary üretip yeniden göndermen gerekiyor.

Hata neden uygulamamı değil de widget'ımı gösteriyor?

Çünkü widget kendi profiliyle imzalanmış ayrı bir bundle. EAS'e tanımlanmamışsa ya da farklı şekilde imzalanmışsa tüm gönderimi başarısız kılar. Eklentiyi yapılandırmanda tanımla ve yeni bir build al.

codesign her şeyin geçerli olduğunu söylüyorsa ne yapmalıyım?

Gömülü profili ve her eklentiyi de kontrol et. Her şey temizse yeni bir build numarasıyla bir kez yeniden gönder. Hata sürerse IPA, codesign çıktısı ve gönderim loglarıyla Apple'a bir rapor gönder.