يحوّل Xcode 27 أهداف النشر القديمة إلى أخطاء بناء. إليك الحدّ الفاصل

تصحيح بتاريخ 19 أكتوبر 2026: صُحّح الادعاء السابق غير المسند بوجود موعد نهائي في أبريل 2027 لتطبيقات Mac App Store. يحدد إعلان Apple متطلبات SDK لمنصات iOS وiPadOS وtvOS وvisionOS وwatchOS، ولا يحدد موعدًا مماثلًا لـ macOS.

افتح مشروع تطبيق Mac كان يُبنى بسلاسة لسنوات، بدّل إلى النسخة التجريبية Xcode 27 beta، اضغط زر البناء، وتوقف:

The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.13, but the range of supported deployment target versions is 12.0 to 27.0.99.

في Xcode 26 كانت هذه الجملة تحذيرًا أصفر يمكنك تجاوزه بالتمرير. في Xcode 27 أصبحت خطأً أحمر يوقف البناء تمامًا. هذا هو التغيير بأكمله، وهو أصغر وأكبر مما يبدو في آن واحد: أصغر لأن توثيق Apple يدّعي منذ سنوات حدًا أدنى هو macOS 11 وiOS 15، وأكبر لأن Xcode لم يفرض هذا الحد فعليًا قط، وعدد كبير من التطبيقات المنشورة يعتمد بصمت على هذه الثغرة.

يوضّح هذا المقال ما يفرضه Xcode 27 فعليًا (استنادًا إلى جداول Apple الرسمية وملاحظات الإصدار)، وما كان Xcode 26 يسمح به فعليًا (استنادًا إلى SDK الموجود على قرصنا)، ومن يتأثر بذلك، والإعداد غير الموثّق الذي يعيد تحويل الخطأ إلى تحذير، والفرق بين أهداف النشر التي يدعمها Xcode ومتطلبات SDK الخاصة بمتجر التطبيقات لكل منصة.

أبرز النقاط

• نطاقات أهداف النشر التي يدعمها Xcode 27 هي macOS 12–27، وiOS/iPadOS/tvOS 15–27، وwatchOS 9–27، وvisionOS 1–27، وDriverKit 21–27، وفقًا لصفحة دعم Xcode من Apple الخاصة بالنسخة التجريبية 6. وما دون هذه الحدود، يفشل البناء.
• وثّق Xcode 26 الإصدار macOS 11 كحدّ أدنى، لكنه كان يقبل فعليًا الإصدار 10.13. تحققنا من ملف إعدادات SDK الخاص بـ macOS 26.0: وجدنا 34 هدف نشر صالحًا، بدءًا من 10.13. يسدّ Xcode 27 هذه الفجوة بجعل النطاق الموثّق هو النطاق المطبَّق فعليًا.
• تغيّر الحد الأدنى لـ macOS خلال فترة النسخة التجريبية. في يونيو، قالت ملاحظة Apple إن النشر العكسي الشامل (Universal) يمتد «حتى macOS 27 وشاملًا له»؛ وفهم المطورون ذلك على أنه يعني Big Sur. أما ملاحظة النسخة التجريبية 6 فتقول «macOS 12 وما بعده». خطّط لـ Monterey، لا لـ Big Sur.
• هناك منفذ خفي غير موثّق، وهو الإعداد __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO، الذي أُفيد أنه يعيد تحويل الخطأ إلى تحذير. هذا الإعداد غير مدعوم رسميًا، وقد يُحذف في أي وقت، ولا يغيّر حقيقة أن Apple لا تختبر تلك الأهداف.
• متطلبات SDK الخاصة بمتجر التطبيقات تختلف باختلاف المنصة. أعلنت Apple أن التطبيقات المرفوعة اعتبارًا من أبريل 2027 للمنصات المذكورة يجب أن تستخدم SDK الخاص بـ iOS 27 أو iPadOS 27 أو tvOS 27 أو visionOS 27 أو watchOS 27، أو إصدارًا أحدث، بحسب المنصة. لا يحدد هذا الإعلان حدًا أدنى لـ SDK الخاص بـ macOS أو موعدًا لإنهاء دعم macOS 11 في Mac App Store.

الأرقام رسميًا

تنشر صفحة دعم Xcode من Apple جدولًا يوضّح ما يمكن لكل إصدار من Xcode البناء من أجله. وهذه هي المقارنة المهمة:

المنصة	Xcode 26.6	Xcode 27 beta 6
macOS	11 – 26.5	12 – 27
iOS / iPadOS	15 – 26.5	15 – 27
tvOS	15 – 26.5	15 – 27
watchOS	8 – 26.5	9 – 27
visionOS	1 – 26.5	1 – 27
DriverKit	20 – 25.5	21 – 27

اقرأ الجدول بعناية، لأن العنوان الشائع القائل بأن «Xcode 27 يرفع الحد الأدنى» صحيح جزئيًا فقط. بالنسبة إلى iOS، ظل الحد الأدنى الموثّق 15 طوال فترة Xcode 26 ويبقى 15 في Xcode 27. أما بالنسبة إلى macOS فيتحرك إصدارًا واحدًا، من 11 إلى 12. وبالنسبة إلى watchOS، من 8 إلى 9. على الورق، هذا تشديد متواضع.

أما ما لا يظهر على الورق فهو أن أرقام Xcode 26 لم تُفرض فعليًا قط.

ما كان Xcode 26 يسمح به فعليًا

يحمل كل SDK داخل Xcode ملف إعدادات يحدد أهداف النشر التي يعتبرها صالحة. على جهازنا، حيث تم تثبيت Xcode 26.0.1 (17A400)، يقع هذا الملف في:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json

قراءته تتطلب أمرًا واحدًا:

python3 -c '
import json
d = json.load(open("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json"))
t = d["SupportedTargets"]["macosx"]
print(t["MinimumDeploymentTarget"], "->", t["MaximumDeploymentTarget"])
print(len(t["ValidDeploymentTargets"]), "valid:", t["ValidDeploymentTargets"][:6], "...")
'

المخرجات على Xcode 26.0.1:

10.13 -> 26.0.99
34 valid: ['10.13', '10.14', '10.15', '11.0', '11.1', '11.2'] ...

إذن، بينما كان جدول Apple يقول «macOS 11»، كان الـ SDK يقول «10.13»، وكان Xcode يسمح لك بكتابة 10.13 في حقل هدف النشر، فيحذّرك، ثم يبني المشروع رغم ذلك. يصف Michael Tsai هذه الممارسة بوضوح: كان بإمكان المطورين «إدخال أهداف أقدم يدويًا»، والكثير من برمجيات Mac المستقلة فعلت ذلك بالضبط لإبقاء مستخدمي High Sierra وMojave وCatalina على النسخة الحالية من البناء.

إذا كانت لديك النسخة التجريبية Xcode 27 beta مثبّتة، فشغّل الأمر نفسه على SDK الخاص بها (استبدل المسار بـ Xcode-beta.app) وستشاهد الحد الأدنى الجديد. لا تتوفر النسخة التجريبية لدينا على هذا الجهاز، لذا نعتمد على جدول Apple وتقارير المطورين للرقم 12.0 بدلًا من قراءته من الملف بأنفسنا.

من تحذير إلى خطأ

الرسالة التشخيصية نفسها ليست جديدة. فنظام البناء من Apple يُصدر منذ سنوات عبارة «نطاق إصدارات هدف النشر المدعومة هو من X إلى Y» كتحذير. ما تغيّر في Xcode 27 هو مستوى خطورتها.

مقال على bleepingswift.com يقتبس صيغة iOS منها كما تظهر في Xcode 27:

The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to xx.x, but the range of supported deployment targets versions is 15.0 to 27.0.x

أما صيغة macOS فهي الرسالة نفسها مع MACOSX_DEPLOYMENT_TARGET ونطاق من 12.0 إلى 27.0.99. وتظهر هذه الرسالة لكل هدف على حدة، فتطبيق يحتوي على امتداد (extension) وودجت (widget) وحزمة اختبار (test bundle) تَرث جميعها هدفًا قديمًا سيُظهرها أربع مرات، وإصلاح التطبيق الرئيسي وحده لا يزيل خطأ البناء.

واجه القائمون على صيانة Vienna RSS هذه المشكلة في 10 يونيو، أي بعد يومين فقط من إطلاق النسخة التجريبية: كان هدفهم 10.13، وكان يُبنى دون تحذيرات أو أخطاء على Xcode 26، وعلى Xcode 27 أصبح «متطلبًا صارمًا (خطأ بناء)». أما قلقهم اللاحق فهو ما يشترك فيه كل مطور Mac في هذا الموقف: من غير المتوقع أن يظل Xcode 26 مدعومًا على macOS 27، لذا فإن الحل البديل المتمثل في «الإبقاء على Xcode القديم» له صلاحية محدودة.

ما الذي تغيّر بين يونيو والنسخة التجريبية 6

لم يكن الحد الأدنى لـ macOS ثابتًا طوال فترة النسخة التجريبية، ويستحق الأمر معرفة أي نسخة من القصة قرأتها.

في يونيو، جاء نص ملاحظة الإصدار المتعلقة بـ Intel كما اقتُبس في منتديات Apple Developer:

Xcode 27 will only install and run on Apple silicon Macs. The macOS SDK is still Universal for back deployment up to and including macOS 27. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

هذا النص لا يقول شيئًا عن الحد الأدنى. وقد قرأ ملخص Tsai ليوم الإطلاق الوضع على أنه «الحد الأدنى الذي يمكنك استهدافه الآن هو Big Sur (أو Monterey لأجهزة Mac ذات معالج Apple Silicon)»، بينما ذكرت مشكلة ViennaRSS الإصدار macOS 12 صراحةً. أما ملاحظات إصدار النسخة التجريبية 6 الحالية فتحسم الأمر:

Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

رقم المشكلة نفسه، لكن بصياغة أعيدت لتسمية macOS 12 صراحةً. ويشير تحديث Tsai في سبتمبر إلى الأمر نفسه: «توثّق النسخة التجريبية 6 من Xcode 27 الآن macOS 12.0 كحد أدنى لهدف النشر». إذا كانت خطة الترحيل لديك مبنية على Big Sur، فراجعها لتصبح Monterey.

من يتأثر فعليًا بهذا

ثلاث مجموعات، مرتبة تنازليًا حسب حدة التأثر.

تطبيقات Mac التي لا تزال تدعم من High Sierra حتى Big Sur

هذه هي المجموعة التي يتناولها منشور Tsai، وهي المجموعة التي تحظى بأقل قدر من التعاطف من المنصة. عبّر Matthias Gansrigler-Hrad من Eternal Storms عن ذلك مباشرة على Mastodon:

I don't appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It's my decision

بالنسبة إلى هؤلاء المطورين، يفرض Xcode 27 خيارًا لا مفر منه: إما رفع الحد الأدنى وقطع الدعم عن مستخدمي أنظمة 2017-2020، أو البقاء على Xcode 26 والتخلي عن SDK الخاص بـ macOS 27 وكل ما يعتمد عليه.

تطبيقات iOS، وبالأخص مكتبات iOS التي تستهدف إصدارًا أقل من 15

ظل الحد الأدنى الذي تحدده Apple لـ iOS هو 15 منذ Xcode 26، لذا فإن التطبيق الذي يستهدف 15 أصلًا لن يلاحظ شيئًا. لكن النظام البيئي كان مليئًا بالمكتبات التي تعلن حدودًا دنيا أقل، وكل واحدة منها تُصدر الآن الرسالة التشخيصية في كل مشروع يستوردها. امتلأت أدوات تتبّع المشكلات على GitHub في الأسبوع الأول من يونيو بطلبات شبه متطابقة بعنوان «دعم Xcode 27: رفع الحد الأدنى لهدف نشر iOS إلى 15» — ضد Facebook iOS SDK، الذي كان يعلن .iOS(.v12) في ملف Package.swift الخاص به، وضد Adjust، وDataDog، وSDWebImage، وغيرها. إذا كنت تعتمد على حزمة لم يستجب القائم على صيانتها بعد، فأنت محظور حتى يستجيب أو حتى تقوم بعمل fork خاص بك.

أي شخص لديه هدف قديم مدفون داخل تبعية (dependency)

هذه هي الحالة الدقيقة. تطبيقك يستهدف 15. لكن حزمة Swift تبعية غير مباشرة (transitive) تستهدف 13. يقوم Xcode 27 ببناء تلك الحزمة باستخدام سلسلة أدواتك، فيرى 13، ويفشل بناء مشروعك. لا يوجد أي تجاوز (override) من جهة المستهلك في Swift Package Manager: خلاصة bleepingswift، التي تتفق مع خلاصتنا، هي أن «الحزم التي تعلن حدودًا دنيا أقدم في تصريح platforms الخاص بها تتطلب إما الترقية إلى نسخة أحدث من الحزمة، أو عمل fork وتحديث المتطلب بنفسك».

المنفذ الخفي

هناك منفذ خفي فعلًا، وينبغي أن تعرف به وأن تتعامل معه بحذر.

كتب Ighor July في 24 يوليو، في مقال اقتبسه Tsai، أنه في النسخة التجريبية Xcode 27 beta «غيّر إعداد خفي تلك الأخطاء لتعود تحذيرات، وظل المترجم (compiler) ينتج الأهداف القديمة التي اختبرتها». ويصف هذا الإعداد بأنه «غير موثّق، وغائب عن واجهة Xcode العادية، ويُختبر حاليًا فقط» في سلسلة أدوات تجريبية. وقد ذكر اسمه أحد قراء منشور Tsai، وهو Harald Striepe:

__DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO

هذا إعداد بناء (build setting)، لذا فمكانه حيث توضع إعدادات البناء عادة: ملف .xcconfig مرتبط بالتكوين (configuration)، أو إعداد من نوع User-Defined يُضاف في أسفل لوحة Build Settings الخاصة بالهدف. اضبطه، وسيعود فحص هدف النشر إلى سلوك Xcode 26.

والآن التحفظات، وهي ليست بسيطة.

إنه غير مدعوم رسميًا. الشرطتان السفليتان في بداية الاسم هما اصطلاح Apple للإعدادات الداخلية. يمكن إعادة تسميته أو حذفه في أي نسخة تجريبية، بما في ذلك النسخة التالية مباشرة لبدء اعتمادك عليه.

إنه يعيد التحذير، لا الاختبار. يستحق تقييم Tsai للتغيير بأكمله أن يُقتبس كاملًا، لأنه الإطار الأكثر صدقًا:

I'm frustrated, too, but it's more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn't tested that it actually worked.

إيقاف الخطأ يعيدك إلى البناء لهدف لم تكن Apple تختبره من قبل، وهي الآن لا تدعمه صراحةً. وأي شيء كان معطوبًا على Catalina في Xcode 26 سيبقى معطوبًا.

الإعداد الخفي لا يثبت أن متجر التطبيقات سيقبل البناء. يجب التحقق من متطلبات SDK والرفع الخاصة بكل منصة على حدة.

متطلبات SDK الخاصة بمتجر التطبيقات تختلف باختلاف المنصة

في إعلانها بتاريخ 9 سبتمبر 2026، حدّدت Apple أبريل 2027 موعدًا لبدء اشتراط استخدام SDK الخاص بـ iOS 27 أو iPadOS 27 أو tvOS 27 أو visionOS 27 أو watchOS 27، أو إصدار أحدث، لرفع التطبيقات الخاصة بكل منصة. لم يحدد الإعلان يومًا بعينه في أبريل، ولم يذكر حدًا أدنى لـ SDK الخاص بـ macOS.

تسجّل صفحة المتطلبات القادمة من Apple متطلبات SDK التي بدأ تطبيقها في 28 أبريل 2026 على المنصات غير التابعة لـ Mac نفسها. وتتضمن الصفحة أيضًا متطلبات منفصلة لتطبيقات Mac؛ لذا فإن غياب macOS عن إعلان أبريل 2027 لا يعني إعفاء تطبيقات Mac من جميع متطلبات المتجر.

هناك فرق بين SDK المستخدم لبناء التطبيق والحد الأدنى لإصدار نظام التشغيل الذي يمكن نشره عليه. تدرج متطلبات نظام Xcode نطاقات أهداف النشر المدعومة في Xcode 27، ومنها macOS 12–27 وiOS/iPadOS 15–27. هذه حدود تدعمها أداة البناء، وليست بحد ذاتها مواعيد نهائية يفرضها المتجر.

وعليه، لا يثبت إعلان Apple وجود موعد نهائي في أبريل 2027 لتحديث تطبيقات Mac App Store التي تدعم macOS 11 أو أقدم. كان استنتاج هذا الموعد من الحد الأدنى لأهداف النشر في Xcode 27 غير مسند، وقد صُحّح هنا.

تحقق من متطلبات الرفع الحالية للمنصة وسلسلة الأدوات ومسار التوزيع المعني قبل اختيار موعد لإنهاء الدعم. كما أن نجاح البناء باستخدام الإعداد الخفي لا يثبت قبوله في متجر التطبيقات.

يتطلب التوزيع المباشر عبر Developer ID أيضًا التحقق من توافق سلسلة الأدوات ونظام التشغيل والتوقيع والتوثيق لدى Apple (notarization). لا يضمن غياب موعد نهائي لـ macOS في هذا الإعلان استمرار صلاحية Xcode 26 أو البُنى ذات أهداف النشر القديمة أو مسار التوزيع هذا إلى أجل غير مسمى.

الإبقاء على Xcode 26، ولماذا يتوقف هذا الحل عن الجدوى

الحل التخفيفي الواضح هو تثبيت الإصدارين معًا. تُسهّل أدوات مثل xcodes الإبقاء على Xcode 26.6 جنبًا إلى جنب مع النسخة التجريبية 27 والتبديل بينهما باستخدام xcode-select. بالنسبة إلى مشروع يستهدف 10.13 وما زلت بحاجة إلى إصداره هذا العام، فهذا هو القرار الصحيح.

لكن لهذا الحل تاريخ انتهاء صلاحية. يُدرج جدول دعم Apple أن Xcode 26.6 يتطلب «macOS Tahoe 26.2 – macOS Tahoe 26.x». لا شيء يقول إنه يعمل على macOS 27، وقراءة Tsai هي أن «استخدام نسخ قديمة من Xcode ليس حلًا رائعًا لأنها غير مدعومة على Golden Gate». قد يعمل، وقد لا تصلحه Apple إن لم يعمل. ويضيف تكلفة أدق:

Swift also makes it more difficult to call newer APIs when using an older SDK.

البقاء على Xcode 26 يعني البقاء على SDK الخاص بـ macOS 26، ما يعني أن واجهات برمجة تطبيقات (APIs) macOS 27 لا يمكن الوصول إليها إلا عبر البحث الديناميكي (dynamic lookup) أو لا يمكن الوصول إليها إطلاقًا. بالنسبة إلى تطبيق في وضع الصيانة فقط، هذا مقبول. أما بالنسبة إلى أي شيء تطوّره بفعالية، فهذا اختناق بطيء.

Xcode 27 نفسه مقتصر على Apple Silicon

هذا تغيير منفصل يصل في الإصدار نفسه ويتشابك مع قصة هدف النشر، لذا لنكن واضحين بشأن الفرق بينهما.

ملاحظات الإصدار لا لبس فيها: «سيُثبَّت Xcode 27 ويعمل فقط على أجهزة Mac ذات معالج Apple Silicon». الملف الثنائي مقتصر على arm64 فقط، كما أكّد على المنتديات أحد مالكي MacBook Pro بمعالج Intel بعدما دفعته عبارة «يتطلب macOS Tahoe 26.4 أو أحدث» في الملاحظات إلى توقّع خلاف ذلك — فـ Tahoe يعمل على حفنة من أجهزة Mac بمعالج Intel، أما Xcode 27 فلا.

لا يزال SDK شاملًا (Universal). يمكنك بناء شرائح x86_64 وملفات ثنائية شاملة من Xcode 27؛ ما عليك سوى القيام بذلك على جهاز بمعالج Apple Silicon. هذا متطلب خاص بعتاد المطوّر، وليس قيدًا على توزيع التطبيق.

تغيير آخر يخص Intel: لم يعد Universal الخيار الافتراضي عند 27.0

بند آخر متعلق بـ Intel في ملاحظات النسخة التجريبية 6، مُدرج تحت عنوان «إهمال Intel» (Intel Deprecation)، وقد تجاهلته معظم التغطيات الإعلامية:

Build targets with a min deployment target set to macOS 27.0 or DriverKit 27.0 will not build Universal by default. The ARCHS_STANDARD build setting will no longer include x86_64 when MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. The x86_64 architecture can be added to the ARCHS build setting if this is needed. (161837535)

هذا منطقي — فـ macOS 27 لا يعمل على أي جهاز Mac بمعالج Intel، لذا فإن هدفًا يقتصر على 27.0 ليس لديه أي جهاز Intel ليعمل عليه — لكن لهذا أثرًا جانبيًا. لا يزال Rosetta موجودًا في macOS 27، وقد أكّدت ملاحظة Apple للمطورين بتاريخ 1 سبتمبر مجددًا أن 27 هو إصدارها الأخير. تطبيق يقتصر على 27.0 ويسقط x86_64 افتراضيًا لن يعود قابلًا للتشغيل تحت Rosetta على Apple Silicon أيضًا، وهذا لا يهم إلا إذا كنت تصدر مضيف إضافات (plug-in host) مقتصرًا على Intel أو ما شابه. أضف x86_64 إلى ARCHS صراحةً إذا احتجت إلى ذلك.

حد ثالث لا يذكره أحد: libc++ عند 11.0

مدفون في قائمة الإهمالات (Deprecations) نفسها: «رُفع الحد الأدنى المدعوم لهدف النشر على macOS الخاص بمكتبة C++ القياسية إلى 11.0». هذا حد أدنى مختلف، وأقل من حد نظام البناء البالغ 12.0، وينطبق على بيئة تشغيل C++ (runtime) التي تربط بها مشروعك، لا على هدف النشر الذي تعلنه. عمليًا، لا يظهر هذا الحد إلا إذا تجاوزت فحص نظام البناء — باستخدام الإعداد الخفي مثلًا — وما زلت تستهدف 10.15 أو أقدم بكود C++. عندئذ يصبح libc++ نفسه العائق التالي الذي يوقفك.

إصلاح المشكلة: التبعيات

بالنسبة إلى أهدافك الخاصة، الإصلاح مجرد رقم في حقل نصي. أما بالنسبة إلى التبعيات:

CocoaPods. أضف خطاف (hook) من نوع post_install يعيد كتابة هدف النشر لكل هدف pod ليطابق الحد الأدنى، ثم نفّذ pod install ونظّف مجلد البناء. نسخة bleepingswift من هذا الخطاف هي الشكل القياسي المعتمد؛ والنقطة المهمة أنه يطبَّق على جميع أهداف pods، لا فقط تلك التي تشتكي اليوم.

Swift Package Manager. لا يوجد أي تجاوز (override) متاح. خياراتك هي: الترقية إلى نسخة من الحزمة رفعت قيمة platforms الخاصة بها؛ أو فتح مشكلة (issue) جديدة أو التصويت لمشكلة موجودة؛ أو عمل fork وتعديل Package.swift وتوجيه مشروعك إلى الـ fork إلى أن يلحق المصدر الأصلي بالتحديث. تحقق من متتبع المشكلات أولًا — بالنسبة إلى SDKs الرئيسية، قدّم أحدهم الطلب في الأسبوع الأول من يونيو وعادةً ما يكون طلب سحب (pull request) مرفقًا به.

الأطر (frameworks) المدمجة وXCFrameworks. تحمل هذه حدها الأدنى الخاص بها داخل Info.plist وأوامر تحميل Mach-O. لا يرفض Xcode 27 ربط (link) إطار ثنائي قديم، لكن الرابط (linker) سيحذّر من عدم تطابق الإصدارات، والسلوك على الهدف القديم يبقى كما جرى اختباره، أي غير مختبر إطلاقًا.

ماذا يعني «الصدق» هنا

يستحق الأمر التوقف عند صياغة Tsai للحظة، لأنها تغيّر ما ينبغي أن تغضب منه فعليًا.

لم يدعم Xcode 26 macOS 10.13. بل سمح لك بكتابة 10.13، وأصدر كودًا، ولم تختبر Apple أن الأطر الموجودة في SDK إصدار 26 تتصرف بشكل صحيح على نظام تشغيل من عام 2017. كان المطورون الذين أصدروا تلك البُنى يقومون بضمان الجودة (QA) الخاص بهم مقابل نظام تشغيل تركته Apple خلفها، وفي معظم الأحيان كان الأمر ينجح، لأن الأطر متوافقة رجعيًا بالتصميم. لكن كلمة «معظم» كانت تحمل عبئًا حقيقيًا في تلك الجملة، وكانت الفجوة بين SDK والهدف تتسع عامًا بعد عام.

يجعل Xcode 27 النطاق الموثّق هو النطاق الحقيقي فعلًا. وهذه خسارة لمستخدمي أجهزة Mac القديمة وللمطورين الذين خدموهم. لكنها ليست خسارة لشيء وعدت به Apple يومًا.

التعقيد التنظيمي

خيط إضافي واحد. في 26 أغسطس، جمع Tsai تعليقات حول قانون المرونة السيبرانية للاتحاد الأوروبي (EU Cyber Resilience Act)، الذي تدخل التزاماته الرئيسية حيز التنفيذ في 11 ديسمبر 2027 والذي يشترط تحديثات أمنية لمدة خمس سنوات على الأقل. أثار قارئ يُعرف باسم Frederik تفاعل هذا القانون مع متجر التطبيقات:

Once you update the minimum supported OS version of your app (which you might be forced to by newer Xcode versions… you can no longer provide updates for your older app versions on the App Store.

قد تتأثر خطة تقديم التحديثات الأمنية بالقرارات المتعلقة بهدف النشر وسلسلة الأدوات وطريقة التوزيع. لكن إعلان متطلبات SDK لأبريل 2027 لا يفرض بحد ذاته إنهاء دعم macOS 11 في ذلك الشهر. تحقق من خيارات الصيانة المتاحة فعليًا لتطبيقك وفق المتطلبات الحالية، واستشر مختصًا قانونيًا بشأن الالتزامات التي قد تنطبق عليك.

قائمة تحقق للترحيل

بالنسبة إلى تطبيق Mac بهدف قديم، بالترتيب:

1. احصِ مستخدميك الفعليين. إذا كانت تحليلاتك تشير إلى عدم وجود أي مستخدم دون macOS 12، فهذا تغيير من سطر واحد وملاحظة إصدار. معظم التطبيقات في هذا الموضع.
2. اضبط هدف النشر على 12.0 (macOS) أو 15.0 (iOS) في كل هدف، بما في ذلك الامتدادات (extensions) والمساعدات (helpers) والاختبارات. ابنِ باستخدام Xcode 27 beta وأزل كل ظهور للرسالة التشخيصية.
3. دقّق التبعيات بحثًا عن تصريحات platforms وملفات podspec دون الحد الأدنى. اعمل fork لما يلزم.
4. احسم خطة دعم الأنظمة القديمة. إذا كنت بحاجة إلى الاستمرار في الإصدار لمستخدمي macOS 10.13–11، فتحقق من متطلبات سلسلة الأدوات وبيئة التشغيل والتوزيع، واختر خطة دعم واختبرها، ثم أبلغ المستخدمين بالقرار الفعلي. لا تفترض وجود موعد نهائي لبناء أخير في أبريل 2027 لتطبيقات Mac.
5. لا تُصدر الإعداد الخفي إلى الإنتاج إلا إذا اختبرت النتيجة بنفسك على نظام التشغيل القديم وقبلت باحتمال اختفاء الإعداد في النسخة التجريبية التالية.
6. إذا كنت تستهدف 27.0 فقط، تحقق من ARCHS. قد تكون أسقطت x86_64 للتو دون أن تلاحظ.

استكشاف المشكلات الشائعة وإصلاحها

الخطأ مستمر بعد رفع هدف التطبيق

هناك هدف آخر في المشروع لا يزال يحمل القيمة القديمة. اختر المشروع (وليس أحد الأهداف) في شريط التنقل (navigator)، وتحقق من هدف النشر على مستوى المشروع، ثم كل هدف وكل حزمة اختبار على حدة. الودجت وامتدادات التطبيق هي المتسببة عادةً.

الخطأ يذكر حزمة لا أعتمد عليها مباشرة

هذه تبعية غير مباشرة (transitive). استخدم الأمر swift package show-dependencies (أو رسم بيان الحزم في Xcode) لمعرفة من يجرّها إلى مشروعك، ثم إما حدّث تلك الحزمة الوسيطة أو اعمل fork للحزمة الطرفية.

أمر xcodebuild من سطر الأوامر يفشل بينما واجهة Xcode الرسومية تبني بنجاح

تحقق من سلسلة الأدوات التي يستخدمها سطر الأوامر: xcode-select -p. قد تكون الواجهة الرسومية على 26 وسطر الأوامر على 27، أو العكس.

ضبطت العلامة الخفية ولم يحدث أي فرق

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

عوامل تشغيل CI لدي (CI runners) تعمل بمعالج Intel

لن يُثبَّت Xcode 27 عليها. هذه مسألة ترحيل عتاد، لا مشكلة تهيئة إعدادات. انتقل مزودو الاستضافة إلى عوامل تشغيل بمعالج Apple Silicon منذ فترة؛ أما أجهزة Mac mini بمعالج Intel ذاتية الاستضافة فقد وصلت الآن إلى نهاية خط دعمها بالنسبة إلى بُنى سلسلة الأدوات الحالية.

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

هل يرفع Xcode 27 الحد الأدنى لـ iOS؟

ليس على الورق — فجدول Apple يذكر iOS 15 منذ Xcode 26. ما يتغيّر هو الفرض الفعلي: الأهداف الأقل من 15 التي كانت تُبنى مع تحذير في Xcode 26 تفشل في Xcode 27.

ما الحد الأدنى لـ macOS في Xcode 27؟

macOS 12 Monterey، وفقًا لصفحة دعم Xcode من Apple وملاحظات إصدار النسخة التجريبية 6. في وقت سابق من دورة النسخة التجريبية، فُهمت الملاحظة على أنها تعني Big Sur؛ وهذا الفهم لم يعد صحيحًا.

هل يمكنني الاستمرار في بناء تطبيقات شاملة (Universal) بمعالج Intel وApple Silicon؟

نعم، من جهاز Mac بمعالج Apple Silicon. يدعم SDK الخاص بـ macOS 27 النشر العكسي الشامل (Universal) إلى macOS 12 وما بعده. الحالة الوحيدة التي يسقط فيها x86_64 افتراضيًا هي عندما يكون الهدف مضبوطًا على 27.0 أو أحدث.

متى يجب عليّ الانتقال إلى Xcode 27؟

يعتمد ذلك على المنصة وطريقة التوزيع. يحدد إعلان Apple بتاريخ 9 سبتمبر 2026 متطلبات SDK لأبريل 2027 للمنصات iOS وiPadOS وtvOS وvisionOS وwatchOS، باستخدام SDK الإصدار 27 أو أحدث لكل منها، لكنه لا يحدد موعدًا نهائيًا مماثلًا لـ macOS. أما التوزيع المباشر فيظل بحاجة إلى التحقق من توافق سلسلة الأدوات ونظام التشغيل ومتطلبات التوقيع والتوثيق لدى Apple (notarization)؛ وليس ضمانًا لإمكان البقاء على Xcode 26 إلى أجل غير مسمى.

هل الإعداد الخفي آمن لبُنى (builds) متجر التطبيقات؟

غير معروف. لم يُبلغ أحد عن عملية رفع بُنيت باستخدامه، وهو علامة داخلية غير موثّقة. تعامل معه كأداة للبُنى المحلية والفروع القديمة، لا كجزء من مسار الإصدار (release pipeline) الخاص بك.

الخلاصة

تغيير هدف النشر في Xcode 27 هو تعديل صغير بذيل طويل الأثر. لم ترفع Apple الحد الأدنى كثيرًا — إصدار واحد فقط على macOS، ولا شيء على iOS — لكنها توقفت عن التظاهر بأن الحد الأدنى اختياري، وقد بُني عقد كامل من برمجيات Mac المستقلة على هذا التظاهر. خطأ البناء الذي تحصل عليه اليوم سهل الإصلاح إذا كان مستخدموك على أنظمة حديثة، ومستحيل إصلاحه بشكل صحيح إن لم يكونوا كذلك.

اعرف أيًّا منهما أنت. إذا كنت لا تزال تصدر لـ macOS 11 أو أقدم، فقيّم احتياجات مستخدميك وخيارات سلسلة الأدوات والتوزيع القابلة للاستمرار، واختبر خطة الدعم قبل إعلان أي موعد لإنهائه. لا يبدأ إعلان أبريل 2027 عدًا تنازليًا مدته سبعة أشهر لتطبيقات Mac App Store. وإذا لم تعد بحاجة إلى دعم تلك الأنظمة، فارفع هدف النشر، وأصلح التبعيات، وتحقق من ARCHS إذا كنت تستهدف 27 فقط، وامضِ قدمًا.

قراءات ذات صلة: دقّق تطبيقاتك المعتمدة على Intel قبل انتهاء Rosetta، والموعد النهائي لتوافق macOS 27 مع Intel، وإصلاح بيئة تطوير macOS Tahoe، وأفضل أدوات مطوري Mac هذا العام.