ITMS-90034: حل خطأ Missing or invalid signature

يظهر ITMS-90034 عندما ترسل الـ build إلى App Store Connect. معناه أن تطبيقك، أو أحد مكوناته، غير موقّع بشهادة إرسال من Apple، أي بشهادة توزيع صالحة. الحل: اعرف أي bundle موقّع بشكل خاطئ ولماذا، ثم أعد بناء نسخة موقّعة للـ App Store.

هذا الدليل يركّز على الخطأ نفسه. إذا كانت كلمتا الشهادة والملف الشخصي (profile) غير واضحتين لك، فاقرأ أولًا شهادة مطوّر iOS والـ provisioning profile. هنا ستجد الرسالة التي يجب قراءتها، وشجرة قرار، والأوامر التي تفحص ملف IPA، والحل باستخدام البيانات التي يديرها 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 حول الشهادات تقول ذلك بوضوح: شهادات التطوير تُستخدم لتشغيل تطبيقك على أجهزتك، وشهادات التوزيع لتوزيعه أو إرساله إلى App Store Connect.

اقرأ المسار المذكور: فهو يحدّد الـ bundle المسبّب للمشكلة. المسار Payload/MyApp.app يشير إلى التطبيق نفسه. المسار الذي ينتهي بـ .appex يشير إلى إضافة (extension) مثل الـ widget. والمسار الذي ينتهي بـ .framework يشير إلى مكتبة مضمّنة.

هذا ليس رفضًا من مراجع. الفحص يفشل عند الإرسال أو أثناء معالجة الـ build، قبل TestFlight: هذا الـ build لن يصل أبدًا إلى المختبرين.

شجرة القرار: من الرسالة إلى الحل

كل سطر يقابل مؤشرًا تقرؤه في الرسالة، أو في أوامر القسم التالي، أو في سجلات EAS. اتبعها بالترتيب: أول سطر ينطبق عليك يعطيك الاتجاه.

ما تلاحظه	السبب المحتمل	الحل
مسار ينتهي بـ .appex	إضافة موقّعة بشكل خاطئ	تعريف الإضافة
Signature=adhoc	build غير موقّع	build بملف store
Apple Development	build تطوير	build بملف store
ظهور ProvisionedDevices	build داخلي (ad hoc)	build بملف store
sealed resource	IPA عُدّل بعد التوقيع	إعادة البناء
EAS: "no longer valid"	شهادة ملغاة	شهادة جديدة
كل شيء صالح	مشكلة من جهة Apple	إعادة الإرسال ثم الإبلاغ

افحص ملف IPA بأربعة أوامر

حمّل ملف IPA من صفحة الـ build على expo.dev، ثم افتح الطرفية على جهاز Mac.

1. من وقّع التطبيق؟

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

الأمر codesign يكتب على مخرج الأخطاء، لذلك نضيف 2>&1. حسب الملاحظة التقنية TN3161 من Apple، كل سطر Authority حلقة في سلسلة الثقة. يجب أن يبدأ أولها بـ Apple Distribution: أو iPhone Distribution:، متبوعًا باسم فريقك. التسمية الثانية تخص النوع القديم iOS Distribution: وحسب كوده، ما زال EAS CLI 24.10.0 ينشئ شهادات من هذا النوع. إذا قرأت Apple Development: فهذا build تطوير. وإذا قرأت Signature=adhoc من دون أي سطر Authority، فالملف التنفيذي غير موقّع بأي شهادة.

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 profile.plist
plutil -extract ProvisionedDevices xml1 -o - profile.plist
plutil -extract ExpirationDate raw profile.plist

هذه أوامر الملاحظة TN3125 حول الـ profiles. الـ profile الخاص بالـ App Store لا يحتوي على أي قائمة أجهزة: يجب أن يجيب السطر الثاني بـ Could not extract value. إذا عرض معرّفات أجهزة، فهو profile من نوع ad hoc، أي profile build داخلي. السطر الثالث يعطيك تاريخ انتهاء الـ profile.

4. هل الإضافات والـ 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 لـ 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، حسب كل سبب

build داخلي أو build تطوير أُرسل إلى Apple

حسب توثيق Expo حول eas.json، الـ builds ذات "distribution": "internal" غير موقّعة للمتاجر: فهي تستخدم profile من نوع ad hoc. وحده الـ profile بتوزيع store، وهي القيمة الافتراضية، ينتج build قابلًا للإرسال. الأضمن أن ترسل الـ build الذي بنيته للتو، من دون أن تختاره يدويًا:

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

إذا كنت تستخدم eas submit --path، فتأكد أن الملف هو فعلًا آخر build للمتجر. على منتدى Apple، اكتشف فريق أن أداة الإرسال لديه كانت ترسل في كل مرة ملف IPA قديمًا محفوظًا في git.

إضافة منسيّة

كل إضافة bundle مستقل، له معرّفه والـ profile الخاص به. في مشروع Expo بتوليد native، تطلب صفحة Expo حول إضافات iOS تعريفها في extra.eas.build.experimental.ios.appExtensions. عندها يعرفها EAS CLI قبل البناء، وينشئ بياناتها أو يتحقق منها. أغلب المكتبات التي تضيف إضافة تكتب هذا التعريف نيابةً عنك عبر الـ plugin الخاص بها.

Solys، المنبّه الذي صنعته بألعاب صغيرة، يضم أربع إضافات: widget وثلاث إضافات Screen Time. الأربع معرّفة في إعداداته، ولدى EAS profile لكل واحدة منها. الإضافة التي أُضيفت يدويًا في Xcode من دون هذا التعريف هي المشتبه الأول عندما يظهر مسار ينتهي بـ .appex في الرسالة.

شهادة ملغاة أو منتهية

صفحة Apple حول الشهادات واضحة: لا يمكنك إرسال build موقّع بشهادة منتهية أو ملغاة. بل إن build أُرسل ولم يُقدَّم للمراجعة بعد قد يتحول إلى Invalid Binary إذا أُلغيت شهادته.

كود EAS CLI 24.10.0 يوضح متى تمر هذه الحالة دون أن تلاحظها:

• build تفاعلي، متصل بـ Apple: يقارن EAS شهادته بالشهادات التي ما زالت صالحة لدى Apple. إذا لم تعد موجودة، يعرض "Current distribution certificate is no longer valid in Apple Dev Portal" ويقترح عليك اختيار شهادة أو إنشاء واحدة.
• build تفاعلي، من دون اتصال: لا يتحقق EAS إلا من التواريخ، وينبّهك إلى أنه يتخطى التحقق لدى Apple.
• build غير تفاعلي، في التكامل المستمر (CI): يعرض EAS "Distribution Certificate is not validated for non-interactive builds" ويوقّع رغم ذلك.

في التكامل المستمر، لا يعيد EAS التحقق من الشهادة نفسها: قد لا يظهر الإلغاء إلا عند الإرسال. الحل: شغّل build تفاعليًا متصلًا بحساب Apple، أو استخدم eas credentials --platform ios، ثم قائمة Build Credentials، ثم "Distribution Certificate: Add a new one to your account". الـ profiles التي كانت تحتوي على الشهادة القديمة تصبح غير صالحة: يتحقق منها EAS في الـ build التالي ويعيد إنشاءها. حدود Apple على عدد الشهادات مشروحة في دليل شهادة مطوّر iOS.

ملف تنفيذي عُدّل بعد التوقيع

التوقيع يختم الكود والموارد والبيانات الوصفية ببصمات (hashes)، كما تشرح الملاحظة TN3126 من Apple. فك ضغط ملف IPA لتغيير ملف ثم إعادة ضغطه يكسر هذا الختم. أجرِ التعديل في إعداداتك، ثم أعد البناء. لا تعدّل أبدًا ملف IPA الذي ينتجه EAS.

المنطق نفسه ينطبق على كود موضوع في مكان خاطئ، مثل أرشيف .zip: لا يستطيع الـ App Store إعادة توقيعه. تصف Apple الأماكن المسموح بها في صفحتها حول محتوى الـ bundle.

بيانات اعتماد محلية

إذا كان profile EAS لديك يستخدم "credentialsSource": "local"، فملف credentials.json يشير إلى شهادة .p12 وprofile .mobileprovision. تحقق من الـ profile بأوامر الخطوة 3: يجب أن يكون من نوع App Store وأن يحتوي على شهادة التوزيع الحالية. واحفظ هذه الملفات خارج المستودع، مثل مفاتيح API في تطبيق Expo.

عندما يكون كل شيء صالحًا

تبقى حالة محبطة. على منتدى Apple، يرى بعض المطوّرين الخطأ يختفي بإعادة إرسال الـ build نفسه من دون أي تغيير. في أغسطس وسبتمبر 2026، وصف موضوعان العكس: شهادة وprofile جديدان، وتوقيع تم التحقق منه، والفشل مستمر. في أحدهما، نصح مهندس من Apple بإرسال تقرير خطأ مع ملف IPA وتحليل التوقيع وسجلات Transporter، ثم التواصل مع App Store Connect.

لذا أعد الإرسال مرة واحدة برقم build جديد. إذا عاد الخطأ بينما أوامرك الأربعة نظيفة، فأبلغ Apple بهذه العناصر. لا تلغِ شهادتك كردّ فعل تلقائي: لن يحل ذلك شيئًا إضافيًا، وسيُبطل الـ profiles لديك.

أرسل الـ build من دون مفاجآت

التحقق من التوقيع يستغرق دقيقتين قبل الإرسال. والفحوص التلقائية الأخرى تتطلب الدقة نفسها، مثل ITMS-90725 لإصدار Xcode أو ITMS-90683 لعبارات طلب الأذونات. المسار الكامل من البناء إلى الإرسال، من دون Mac، موجود في نشر تطبيق iOS بدون Mac.

أما رفض المراجع فيحتاج إلى تأنٍّ أكبر: الطريقة موجودة في صفحة تطبيق رفضته Apple، وأكثر الأسباب شيوعًا في لماذا ترفض Apple تطبيقك.

للتحقق من ملفك قبل الإرسال، يجمع Review Kit قائمة التحقق الخاصة بي وskills لـ Claude Code تراجع مشروعك. وإذا تعطّل الإرسال وأردت رأيًا بشريًا، احجز ساعة معي: نراجع مشروعك عبر مكالمة فيديو، على شاشتك. وإذا كنت تحضّر إطلاقك الأول، أجرِ التشخيص المجاني: يرتّب لك الخطوات ويرسل لك قائمة التحقق الخاصة بي لتجنّب رفض Apple.

الأسئلة الشائعة

هل ITMS-90034 رفض من App Review؟

لا. إنه فحص تلقائي يتم عند إرسال الـ build، قبل TestFlight وقبل أي مراجعة. لم يفتح أحد تطبيقك: لاحظت Apple فقط أن توقيعه لا يأتي من شهادة توزيع صالحة.

هل يجب أن ألغي شهادة التوزيع لحل ITMS-90034؟

فقط إذا كانت مخترقة أو غير صالحة أصلًا. إلغاء شهادة تعمل يُبطل الـ profiles من دون أن يعالج السبب. ابدأ بقراءة توقيع ملف IPA بأمر codesign، ثم صحّح ما تشير إليه شجرة القرار.

هل يمكن حل ITMS-90034 بتحديث عن بُعد؟

لا. التوقيع جزء من الملف التنفيذي، والـ build المرفوض لن يكون قابلًا للاستخدام أبدًا. يجب إنتاج ملف تنفيذي جديد موقّع بشكل صحيح وإرساله من جديد.

لماذا يذكر الخطأ الـ widget وليس التطبيق؟

لأن الـ widget هو bundle مستقل، موقّع بالـ profile الخاص به. إذا لم يكن معرّفًا لدى EAS أو وُقّع بطريقة أخرى، فإنه يُفشل الإرسال كله. عرّف الإضافة في إعداداتك وأعد البناء.

ماذا أفعل إذا قال codesign إن كل شيء صالح؟

تحقق أيضًا من الـ profile المضمّن ومن كل إضافة. إذا كان كل شيء نظيفًا، فأعد الإرسال مرة واحدة برقم build جديد. وإذا استمر الخطأ، فأرسل تقريرًا إلى Apple مع ملف IPA ومخرجات codesign وسجلات الإرسال.