Slicing هي آلية من App Thinning يقوم من خلالها App Store بإنشاء متغيرات متعددة للملف الثنائي تلقائياً، يحتوي كل منها على موارد لطراز جهاز محدد فقط. وفقاً لـ Apple Developer Documentation, 2026، يستبعد Slicing موارد التكوينات غير المدعومة من التوزيع، مما يقلل حجم التثبيت. سنستعرض مبدأ العمل، وأنواع التقسيم، والتحقق من النتائج.
الخلاصة
Slicing هو مكون من App Thinning مسؤول عن إنشاء متغيرات (شرائح) للملف الثنائي للتطبيق على جانب App Store. عندما يرفع المطور ملفاً ثنائياً شاملاً (fat binary) يحتوي على كود وموارد لجميع التكوينات المدعومة، يقوم App Store بتحليله وإنشاء شرائح متعددة: بشكل منفصل لـ iPhone بمعالج A17، وبشكل منفصل لـ iPad مع M4، وبشكل منفصل لـ Apple Watch. تحتوي كل شريحة فقط على أجزاء الكود والموارد الضرورية لهذا المزيج المحدد من المعمارية والدقة.
قبل iOS 9، كان المطورون ينشئون يدوياً ملفات ثنائية منفصلة لأجهزة مختلفة أو يوزعون ملفاً ثنائياً شاملاً (fat binary) يحتوي على كل شيء دفعة واحدة. Slicing أتمت هذه العملية بالكامل: يجهز المطور مشروعاً واحداً في Xcode، ويرفع أرشيفاً واحداً إلى App Store Connect، ويقوم Slicing على جانب الخادم بإنشاء العدد الأمثل من المتغيرات. لا يرى المستخدم أبداً عملية التقسيم — فهو يتلقى ملف .app جاهزاً، محسناً لجهازه.
لا يطبق Slicing على الكود والصور فقط، بل أيضاً على تظليلات Metal. تستخدم GPU من Apple مجموعة تعليماتها الخاصة (Metal Shading Language)، والتي تختلف عن تعليمات PowerVR أو ARM Mali. يتضمن Slicing في الشريحة فقط التظليلات الخاصة بعائلة GPU للجهاز المستهدف. هذا مهم بشكل خاص للألعاب التي تحتوي على تظليلات مخصصة — على سبيل المثال، يتم تجميع تأثيرات ما بعد المعالجة عالية التفاصيل فقط للأجهزة ذات GPU القوية (iPad Pro M4, iPhone 16 Pro Max).
يقوم مترجم Xcode بإنشاء ملف ثنائي شامل (fat binary) بمعماريات متعددة (armv7, arm64, arm64e)، لكنه لا يزيل الموارد — تبقى جميع الصور بجميع الدقات داخل ملف .app. Slicing يذهب أبعد من ذلك: فهو يحلل Asset Catalogs وتظليلات Metal ومكتبات Swift، ويزيل من كل شريحة ما ليس ضرورياً للهدف المحدد. على سبيل المثال، رسومات @3x لا تصل إلى شريحة iPhone SE، ووحدات التحكم الخاصة بـ iPhone (إذا تم استخراجها في موارد منفصلة) لا تصل إلى شريحة iPad Air.
تبدأ عملية Slicing بعد رفع البناء إلى App Store Connect وتتكون من ثلاث مراحل: التحليل والتقسيم والتعبئة. في مرحلة التحليل، يقوم خادم App Store بتحليل الملف الثنائي، واستخراج معلومات حول المعماريات والأجهزة ودقات الشاشات وإصدارات iOS المدعومة. يستخدم App Store تعييناً لجميع الطرازات التجارية لـ Apple إلى مواصفاتها الفنية — يتم تحديث قاعدة بيانات الأجهزة مع كل إصدار من iOS.
في مرحلة التقسيم، يقوم الخادم بإنشاء نسخ منفصلة من الملف الثنائي لكل مجموعة فريدة. للقيام بذلك، يستخرج App Store الصور من Asset Catalogs بعلامات محددة (idiom, subtype, scale)، ويختار فقط تلك التي تطابق الجهاز المستهدف، ويجمع حزمة موارد جديدة. المكتبة المعيارية لـ Swift تخضع أيضاً للتقسيم — تتم إزالة الرموز والطرق غير المستخدمة منها (dead code stripping).
في مرحلة التعبئة، توضع كل شريحة في حزمة توزيع منفصلة وترتبط ببيانات وصفية — قائمة طرازات الأجهزة التي صُممت هذه الشريحة من أجلها. عندما يقوم المستخدم بتنزيل التطبيق، يختار App Store الشريحة المناسبة حسب طراز الجهاز وإصدار iOS ونوع الاتصال. إذا لم يكن هناك تطابق دقيق، يستخدم الخادم أقرب شريحة من حيث الخصائص. تخزن Apple جميع المتغيرات في شبكة CDN الخاصة بـ CloudKit للتوصيل السريع في جميع أنحاء العالم.
Slicing هي إحدى آليات App Thinning الثلاث، لكنها تساهم بشكل أكبر في تقليل حجم التنزيل. Bitcode مسؤول عن تحسين الكود الآلي، و On-Demand Resources مسؤول عن إدارة الموارد على الجهاز، و Slicing مسؤول عن إزالة الموارد الزائدة في مرحلة التوزيع. بدون Slicing، تعمل الآليتان الأوليان، لكن المستخدمين يتلقون موارد لجميع الأجهزة، مما يزيد الحجم بنسبة 20–40% حسب عدد Asset Catalogs.
الفرق بين Slicing و Bitcode يكمن في نقطة التطبيق: Slicing يعمل على مستوى الموارد (الصور، التظليلات، ملفات NIB)، و Bitcode يعمل على مستوى الكود الآلي. يقسم Slicing الكود حسب المعماريات (arm64 vs arm64e)، ويسمح Bitcode لـ Apple بإعادة ترجمة الكود لمعماريات جديدة. Bitcode + Slicing معاً يوفران أقصى تحسين: Bitcode يولد كوداً لمعمارية محددة، و Slicing يزيل الموارد الزائدة لتلك المعمارية.
العلاقة مع On-Demand Resources — Slicing و ODR لا يتداخلان. يقرر Slicing أي الموارد ستصل إلى توزيع الجهاز أصلاً، بينما يدير ODR متى يتم تحميل هذه الموارد وتفريغها. يمكن للمطور وضع علامة ODR على مورد، وسيقوم Slicing بتضمينه في الشريحة إذا كان مطابقاً للجهاز. Apple توصي باستخدام الآليات الثلاث معاً للحصول على أقل حجم تثبيت.
| الآلية | هدف التحسين | متى تطبق | التأثير على الحجم |
|---|---|---|---|
| Slicing | الموارد (الصور، التظليلات) | على جانب App Store | تزيل ~30% من الموارد الزائدة |
| Bitcode | الكود الآلي | عند تنزيل المستخدم | تحسين الكود للمعمارية |
| ODR | الموارد على الجهاز | بعد التثبيت | يقلل الحجم الأولي بنسبة 40–60% |
ينشئ Slicing شرائح منفصلة وفقاً لعدة أبعاد: معمارية المعالج، وحجم الشاشة (الدقة)، وإصدار iOS، وعائلة GPU (لـ Metal). المعمارية تحدد مجموعة تعليمات CPU: arm64 — مجموعة أساسية 64 بت (iPhone 5s — iPhone X)، arm64e — مجموعة موسعة مع دعم Pointer Authentication و PAC (iPhone XS والأحدث، iPad Pro مع A12X+). تتضمن الشريحة لـ arm64e كوداً مع تعليمات حماية الذاكرة غير المتوفرة على أجهزة arm64.
دقة الشاشة — البعد الرئيسي الثاني لـ Slicing. تستخدم Apple مقاييس @1x (iPhone 3GS)، @2x (iPhone 4 — iPhone SE 3)، @3x (iPhone 6 Plus والأحدث) ومقاييس خاصة بـ iPad (2x و 3x مع مقاييس إضافية). يتضمن Slicing في الشريحة فقط الصور بالمقياس المطابق للجهاز المستهدف. مع التنظيم الصحيح لـ Asset Catalogs في Xcode، يلغي هذا الحاجة إلى إدارة مجموعات الموارد يدوياً — يكفي إضافة صورة إلى الكتالوج مع تحديد أنواع الأجهزة المدعومة.
عائلة GPU — البعد الثالث، ذو أهمية حيوية لتطبيقات Metal. تصنف Apple GPUs حسب الأجيال: Apple GPU family 1 (A7)، family 2 (A8)، ... family 8 (M4). يتم تجميع تظليلات Metal لكل عائلة على حدة، حيث أن مجموعة تعليمات Metal Shading Language تتوسع مع كل جيل من GPU. يتضمن Slicing في الشريحة فقط التظليلات الخاصة بعائلة GPU للجهاز المستهدف، مما يقلل بشكل كبير حجم الألعاب والتطبيقات التي تستخدم Metal للعرض.
معمارية CPU تؤثر مباشرة على حجم الشريحة: كود arm64e يحتوي على تعليمات إضافية لـ Pointer Authentication (PAC) و Signed Return Address، مما يزيد الملف الثنائي بنسبة 5–10% مقارنة بـ arm64. لكن هذه الزيادة يتم تعويضها بحقيقة أن Slicing يتضمن كود arm64e فقط في الشرائح المخصصة للأجهزة ذات معالجات A12+. بالنسبة لـ iPhone SE (الجيل الثالث) مع A15 Bionic، ينشئ Slicing شريحة منفصلة محسنة لقدرات هذه الشريحة.
تكوين Slicing في Xcode ضئيل — يتم التكوين الرئيسي عبر Asset Catalogs و Build Settings. يجب أن يحتوي Asset Catalog على موارد منظمة حسب نوع الجهاز (Any, iPhone, iPad, Apple Watch, Apple TV) مع تحديد المقياس ووضع العرض بشكل صحيح. يقوم Xcode تلقائياً بتضمين في البناء فقط الموارد التي تطابق الأجهزة المستهدفة المحددة في إعدادات Deployment Target.
الإعداد الرئيسي لـ Slicing في Xcode هو Build Setting App Thinning. القيم المتاحة:
Targeted Device Families في General → Deployment Info يحدد أنواع الأجهزة التي يتم بناء التطبيق من أجلها (iPhone / iPad / Universal). يعتمد Slicing على هذه المعلمة عند التقسيم — إذا كان التطبيق يدعم iPhone فقط، لا يتم إنشاء شريحة لـ iPad. Deployment Target (الحد الأدنى لإصدار iOS) يؤثر أيضاً على Slicing: إصدارات iOS القديمة قد تتطلب شرائح armv7 غير ضرورية لـ iOS 13+. توصي Apple بتعيين Deployment Target على أحدث إصدار ثابت من iOS — هذا يقلل عدد الشرائح وحجم الملف الثنائي.
لأقصى كفاءة لـ Slicing، يجب أن تستخدم Asset Catalogs علامات محددة لكل مورد. Xcode يوفر في Attributes Inspector للصور: Width Class (Any, Compact, Regular)، Height Class (Any, Compact, Regular)، Gamut (sRGB, Display P3)، Memory (Any, Low, High)، Graphics (Any, Low, High). بدمج هذه العلامات، يتحكم المطور في أي الشرائح تظهر فيها كل صورة. على سبيل المثال، صورة لـ iPad بعلامات Regular Width + Regular Height ستظهر فقط في شرائح iPad في الوضع الأفقي.
# تصدير الشريحة لجهاز محدد
xcodebuild -exportArchive \
-archivePath "App.xcarchive" \
-exportPath "sliced/" \
-exportOptionsPlist "export.plist" \
-thinning "iPhone17,2" # iPhone 16 Pro Max
Xcodebuild مع المعامل -thinning ومعرف الطراز ينشئ شريحة فقط لهذا الطراز. يمكن العثور على قائمة المعرفات في قاعدة بيانات أجهزة Apple (التنسيق: iPhone17,2 — iPhone 16 Pro Max، iPad14,1 — iPad Pro 11 M4). هذه الطريقة مفيدة للتحقق من حجم الشريحة قبل الإرسال إلى App Store Connect. يمكن لـ CI/CD استخدام هذا الأمر للتحقق التلقائي — إذا تجاوز حجم الشريحة الحد (مثلاً 100 ميجابايت للتنزيل عبر الهاتف المحمول)، يصدر خط الأنابيب تحذيراً.
بعد رفع الأرشيف إلى App Store Connect، توفر Apple إحصائيات مفصلة عن أحجام الشرائح. App Store Connect → Activity → اختر البناء → App Thinning — يعرض Estimated App Store Size لكل فئة جهاز: iPhone، iPad، Apple Watch، tvOS. الأحجام مقسمة حسب إصدارات iOS وأنواع المعالجات. إذا تجاوزت أي شريحة الحجم المتوقع، يضع App Store Connect علامة تحذير صفراء عليها.
التحقق المحلي عبر Xcode Organizer: بعد الأرشفة، افتح Window → Organizer، اختر الأرشيف وانقر على App Thinning Profiles. سيعرض Xcode الأحجام لكل شريحة محتملة بناءً على تكوين المشروع الحالي. تتوفر أيضاً خيار Export لإنشاء IPA مع ملف Slicing محدد. Xcode ينشئ ملف .app-thinning.plist يحتوي على معلومات حول الموارد المضمنة في كل شريحة.
لأتمتة التحقق من Slicing في CI/CD، استخدم xcodebuild مع -thinning وحلل حجم ملفات .app المنشأة. توفر Apple الأداة المساعدة app-size (يتم تثبيتها عبر Xcode Command Line Tools)، والتي تنتج تقريراً مفصلاً: حجم الكود، وحجم الموارد حسب الفئات (الصور، التظليلات، NIB)، وحجم مكتبات Swift. تساعد مقارنة أحجام الشرائح قبل وبعد تحسين Asset Catalogs في تحديد الموارد غير المشاركة في Slicing بسبب تكوين غير صحيح.
# تحليل حجم الشريحة
app-size -m "sliced/App.app" \
--format json
App-size ينتج تقرير JSON مقسماً حسب فئات الموارد. إذا تم تكوين Slicing بشكل صحيح، سيظهر في قسم "images" مجموعة مقياس واحدة فقط (@2x أو @3x)، وليس كل المتغيرات. يظهر خطأ تكوين Asset Catalog عندما تكون جميع المقاييس (@1x, @2x, @3x) موجودة في الشريحة — هذا يعني أن Xcode لم يتمكن من تحديد الجهاز المستهدف لهذه الصور، ولم يعمل Slicing.
الأسئلة الشائعة
نعم، TestFlight يدعم أيضاً Slicing. عندما يقوم المختبر بتنزيل التطبيق عبر TestFlight، يقوم خادم Apple بتوصيل شريحة محسنة لجهاز المختبر. App Store Connect يعالج Slicing تلقائياً لجميع التوزيعات، بما في ذلك TestFlight، باستثناء بنيات Enterprise و Ad Hoc.
نعم، في Asset Catalogs يمكن إلغاء تحديد أنواع أجهزة معينة لكل صورة. Xcode يسمح في Attributes Inspector بتحديد Idiom (iPhone, iPad, Apple Watch, Mac) والمقاييس التي يجب تضمين المورد لها. إذا كان المورد مطلوباً لجميع الأجهزة، استخدم Universal بأي مقياس.
الأطر المخصصة (.framework) تشارك أيضاً في Slicing إذا تم بناؤها كـ XCFramework (بمعماريات متعددة). App Store يتضمن في الشريحة فقط معمارية الإطار التي تطابق الجهاز المستهدف. المكتبات الثابتة (.a) لا تخضع لـ Slicing — يتم تضمينها بالكامل في الملف الثنائي.
Xcode Organizer يظهر estimated size — حجماً متوقعاً دون مراعاة التقسيم الفعلي على خوادم Apple. يعرض App Store Connect الحجم الفعلي بعد Slicing، والذي قد يكون أقل بنسبة 10–15% من التقدير، حيث يطبق الخادم تحسينات إضافية (خوارزميات LZFSE، ضغط Zstandard للموارد) غير متوفرة محلياً.
نعم، Slicing متوافق تماماً مع SwiftUI. Asset Catalogs تستخدم بواسطة SwiftUI عبر أنواع Image و Color و SymbolImage. ينطبق Slicing على الصور المتجهة والنقطية ورموز SF Symbols وتظليلات Metal بغض النظر عما إذا كان SwiftUI أو UIKit مستخدماً لبناء الواجهة.
الملخص
سنقوم بتطوير تطبيق جوال جاهز
تقدم IT Sectr تطبيقات iOS وAndroid للشركات الناشئة والشركات منذ عام 2017. سوف نقدم لك النصح ونقترح أفضل حل.