تطبيقك لا يعمل على iOS الجديد: الأسباب الشائعة وخطة الإصلاح

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

النسخة المنشورة من تطبيقك بُنيت بأدوات وقت بنائها، وتعمل على نظام يتغيّر كل عام. معظم الأعطال تأتي من خمسة مصادر:

1. مكتبات طرف ثالث لم تُحدّث

تطبيق الأعمال المعتاد يعتمد على مكتبات للدفع والخرائط والتحليلات والإشعارات وتسجيل الدخول. كل منها مبني على افتراضات عن النظام، ومزودها يصدر تحديثًا يتوافق مع iOS الجديد. إن لم يُحدَّث تطبيقك منذ مدة، فهو يحمل نسخًا قديمة منها، وأي تغيير في النظام يظهر فيها أولًا.

2. تغيّر الأذونات والخصوصية

تشدد Apple ضوابط الخصوصية مع الإصدارات: نصوص طلب الإذن، ومستوى الوصول إلى الموقع والصور، والوصول إلى الشبكة المحلية، وتتبع المستخدم. الميزة التي كانت تعمل لأن الإذن كان يُمنح ضمنيًا قد تتوقف دون رسالة خطأ، فيبدو الأمر كأن التطبيق «لا يستجيب».

3. واجهات برمجية مهملة أو تغيّر سلوكها

تعلن Apple إهمال بعض الواجهات قبل سنوات من إزالتها، وتغيّر سلوك بعضها حين يُبنى التطبيق بالإصدار الجديد من SDK. الكود الذي تجاهل تحذيرات الإهمال في كل بناء سابق يدفع الثمن دفعة واحدة.

4. تغيّر التصميم وأحجام الشاشات

جاءت iOS 26 بتصميم جديد لعناصر النظام، وأتاحت Apple مفتاح توافق مؤقتًا (UIDesignRequiresCompatibility) لإبقاء المظهر القديم أثناء المراجعة. لكن توثيق Apple لهذا المفتاح ينص على أن النظام يتجاهله عند البناء لـ iOS 27 أو أحدث؛ أي أن التطبيق الذي أجّل التكيف سيظهر بالتصميم الجديد في أول بناء بأدوات iOS 27. ومع كل جهاز بمقاس أو شكل جديد، كالجهاز القابل للطي الذي أعلنت عنه Apple في أخبار المطورين بنظام iOS 27.1، تنكشف الشاشات المبنية بمقاسات ثابتة.

5. إطار متعدد المنصات بإصدار قديم

إن كان التطبيق مبنيًا بـ Flutter أو إطار مشابه، فبين الكود ونظام iOS طبقة إضافية: الإطار نفسه وإضافاته. الإصدار القديم من الإطار قد لا يُبنى بإصدار Xcode الحالي، والإضافات المهجورة لا تُحدَّث أبدًا. هنا يتحول «إصلاح iOS» إلى ترقية للإطار، كما تشرح مقالة تحديث تطبيق Flutter قديم.

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

1. إعادة إنتاج العطل: على جهاز بإصدار iOS الجديد، وبالخطوات التي يصفها المستخدمون، مع تقارير الانهيار من أداة المراقبة أو من Xcode. العطل الذي لا يُعاد إنتاجه لا يُصلح بثقة.
2. إثبات القدرة على البناء: هل الكود في المستودع هو نفسه المنشور؟ هل يُبنى على جهاز بإصدار Xcode الحالي؟ هل شهادات التوقيع وحساب المطور في يد منشأتك؟ إن كانت الإجابة «لا» عن أي منها، فهذه أول مهمة، قبل أي إصلاح.
3. ترقية أدوات البناء: Xcode، والحد الأدنى المستهدف من iOS، وأداة إدارة الحزم، وإطار العمل إن وُجد. هذه ترقية تُختبر وحدها قبل أي تعديل وظيفي، حتى يُعرف أن ما يظهر بعدها من أعطال سببه الترقية لا الإصلاح.
4. تحديث المكتبات بالأولوية: ابدأ بالمكتبات المرتبطة بالعطل، ثم بالحساسة (الدفع، والدخول، والإشعارات)، ثم الباقي. المكتبة المهجورة تُستبدل، وقرار استبدالها يُكتب لأنه يغيّر جزءًا من التطبيق.
5. إصلاح الكود: الواجهات المهملة، ومسارات الأذونات ومعالجة الرفض، والشاشات التي تكسرها المقاسات أو التصميم الجديد.
6. الاختبار: على iOS الجديد، وعلى أقدم إصدار يدعمه التطبيق، وعلى أجهزة بمقاسات مختلفة، مع اختبار المسارات الحرجة كاملة (الدخول، والدفع، والإشعارات). ثم نسخة TestFlight لفريقك قبل الرفع.
7. النشر التدريجي والمراقبة: تتيح Apple إطلاق التحديث على مراحل خلال سبعة أيام لمستخدمي التحديث التلقائي، مع إمكانية إيقافه مؤقتًا. راقب معدل الانهيار في الأيام الأولى قبل أن يصل التحديث إلى الجميع.

هذا الترتيب هو نفسه منطق خدمة إصلاح أخطاء التطبيق: تشخيص قبل الإصلاح، وترتيب الأخطاء بأثرها، وإصلاح السبب لا العَرَض، واختبار يمنع عودة الخطأ، ومراقبة للأعطال بعد النشر.

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

• اختبار التطبيق على النسخ التجريبية من iOS الجديد قبل صدوره، وتجهيز التحديث ليكون جاهزًا يوم الإطلاق.
• تحديث أدوات البناء والمكتبات مرة على الأقل كل عام، لا عند الأزمة فقط.
• متابعة صفحة متطلبات Apple وإدراج مواعيدها في خطة الصيانة.
• مراقبة للأعطال مصنفة بإصدار النظام، حتى يظهر العطل الجديد في يومه الأول.
• اختبارات آلية للمسارات الحرجة تكشف ما تكسره الترقية.

هذا ما يغطيه عقد صيانة التطبيقات والدعم الفني عندنا: التوافق مع إصدارات iOS وAndroid الجديدة، ومتطلبات المتجرين، وتحديث أدوات التطوير والمكتبات. وتذكر صفحة تطوير تطبيقات iPhone أننا نختبر على النسخ التجريبية من iOS قبل صدورها، ونجهز التحديث ضمن عقد الدعم. وتطبيق Android يواجه المسألة نفسها بمتطلبات مختلفة، تفصلها مقالة توافق التطبيق مع Android الجديد.

جهّز قبل التواصل مع المطور الحالي أو مع جهة جديدة:

• وصف العَرَض بدقة، وإصدارات iOS والأجهزة المتأثرة، وتاريخ بدء الشكاوى، ولقطة أو تسجيل شاشة.
• رابط التطبيق في App Store، ورقم آخر إصدار منشور وتاريخه.
• الوصول إلى المستودع وحساب Apple Developer، أو معرفة باسم من هما.
• أداة مراقبة الأعطال إن وجدت، وصلاحية لقراءة تقاريرها.
• التقنية المبني بها التطبيق (Swift أو Flutter أو غيرها) إن كنت تعرفها.

واطلب من المطور كتابيًا:

• تشخيصًا مكتوبًا للسبب، لا وصفًا للعَرَض.
• إجابة صريحة: هل يُبنى المشروع الآن بإصدار Xcode الذي تشترطه Apple؟ وإن لم يكن، فما الذي يلزم ترقيته؟
• قائمة المكتبات التي ستُحدَّث أو تُستبدل، وسبب كل منها.
• فصل الإصلاح العاجل عن خطة الترقية في التقدير والجدول.
• أجهزة وإصدارات iOS التي سيُختبر عليها، ونسخة TestFlight قبل الرفع.
• خطة نشر تدريجي، وما يفعله إن ظهر عطل بعد النشر.