iOS Deployment Target: ما هو، الحد الأدنى لإصدار iOS والإعدادات

ما هو iOS Deployment Target؟

iOS Deployment Target هو معلمة تكوين في Xcode تحدد أقدم إصدار من iOS أو iPadOS أو tvOS أو watchOS أو visionOS يمكن للتطبيق العمل عليه. يحتوي كل مشروع Xcode على هذا الإعداد لكل نظام بشكل منفصل. على سبيل المثال، قد يكون لتطبيق iOS Deployment Target 16.0، بينما امتداد watchOS — 9.0. إذا كان جهاز المستخدم يعمل بنظام iOS 15.0، فلن يظهر التطبيق ذو Target 16.0 في App Store ولن يمكن تثبيته عبر التوزيع المباشر.

تعتمد آلية عمل Deployment Target على التحقق من إصدار نظام التشغيل أثناء التثبيت. يقارن App Store قيمة Deployment Target من Info.plist (المفتاح MinimumOSVersion) مع إصدار نظام التشغيل على جهاز المستخدم. إذا كان إصدار الجهاز أقل — يتم حظر زر "تنزيل"، ولا تعيد API متجر التطبيقات التطبيق في نتائج البحث لذلك الجهاز. ينطبق السلوك نفسه على TestFlight والتوزيع ad-hoc والمؤسسي.

وفقاً لبيانات StatCounter حتى يونيو 2025، iOS 16 يمثل حوالي 48% من أجهزة iPhone النشطة، iOS 17 — 35%، iOS 18 — 12%، الإصدارات الأقدم — حوالي 5%. اختيار Deployment Target 16.0 يغطي 83% من الأجهزة، Target 17.0 — 35% (فقط iOS 17+). هذه الأرقام حاسمة لاتخاذ القرار: كلما زاد Target، قل الجمهور، ولكن زادت إمكانية الوصول إلى أحدث واجهات برمجة تطبيقات SwiftUI و UIKit.

كل إصدار جديد من iOS يضيف ليس فقط ميزات للمستخدمين، بل أيضاً واجهات برمجة تطبيقات للمطورين. معدّلات SwiftUI الجديدة، وطرق UIKit، وأطر مثل SwiftData و Observation متاحة فقط عند Deployment Target محدد. يجب على المطور الموازنة بين مدى وصول الجمهور وتوفر الأدوات الحديثة.

iOS Deployment Target مقابل minSdkVersion: مقارنة مع Android

iOS Deployment Target و minSdkVersion في Android يؤديان نفس الوظيفة — تعيين الحد الأدنى لإصدار نظام التشغيل للتطبيق. ومع ذلك، تختلف آليات التنفيذ والأدوات المرتبطة بها. فهم هذه الاختلافات مفيد للمطورين الذين يعملون على كلا النظامين ويساعد في تجنب الارتباك عند الانتقال بين الأنظمة البيئية.

في iOS، يتم تعيين الحد الأدنى للإصدار عبر إعدادات بناء Xcode (IPHONEOS_DEPLOYMENT_TARGET) ويُخزّن في Info.plist (MinimumOSVersion). في Android — عبر build.gradle (minSdkVersion) و AndroidManifest.xml (<uses-sdk android:minSdkVersion>). لا يحتوي iOS على ما يعادل targetSdkVersion و compileSdkVersion — التغييرات السلوكية في iOS تُدار بواسطة SDK الذي تم تجميع التطبيق به (Base SDK) وإصدار نظام التشغيل على الجهاز.

الفرق الرئيسي هو أن Base SDK في iOS هو دائماً أحدث إصدار مثبت في Xcode. لا يمكن للمطور اختيار compileSdkVersion كما في Android — يتم تجميع التطبيق دائماً مقابل أحدث SDK متاح. التغييرات السلوكية الجديدة في iOS تُطبق على جميع التطبيقات التي تم تجميعها مع Base SDK الجديد، بغض النظر عن Deployment Target. في Android، يوفر targetSdkVersion تحكماً في التغييرات السلوكية؛ iOS ليس لديه هذا الفصل.

التغييرات السلوكية في iOS مقابل Android

على عكس Android، حيث ترتبط التغييرات السلوكية بـ targetSdkVersion، يطبق iOS التغييرات السلوكية على جميع التطبيقات التي تم تجميعها مع الإصدار الجديد من Xcode و Base SDK. على سبيل المثال، أدخل iOS 13 الوضع الداكن — جميع التطبيقات المبنية مع Xcode 11 و iOS 13 SDK حصلت تلقائياً على دعم السمة الداكنة، بغض النظر عن Deployment Target. في Android، تغيير مماثل (Scoped Storage) يُطبق فقط عندما targetSdk >= 29. يحتاج مطورو iOS إلى الاستعداد للتغييرات السلوكية مع كل Xcode جديد، دون إمكانية التأجيل.

معرفة كلا النظامين تسمح بتوقع عواقب اختيار الحد الأدنى للإصدار وتخطيط تحديثات الكود لواجهات برمجة التطبيقات الجديدة. في IT Sectr، نستخدم كلا النظامين البيئيين منذ 2017 — تظهر الممارسة أنه يجب اختيار iOS Deployment Target أقل بمقدار 2–3 إصدارات من الإصدار الحالي لتحقيق توازن بين التغطية والوظائف.

كيفية إعداد Deployment Target في Xcode

إعداد iOS Deployment Target يتم في عدة أماكن في المشروع: الـ Target الرئيسي، مشروع Pods (إذا تم استخدام CocoaPods)، تبعيات Swift Package Manager، وامتدادات Widget/Extension. إذا اختلفت القيم بين التطبيق الرئيسي والامتدادات، يستخدم AppStore القيمة القصوى منها — أي لا يمكن أن يكون للامتداد Target أقل من التطبيق الرئيسي.

الإعداد في محرر مشروع Xcode

افتح مشروع Xcode → اختر الـ Target → علامة التبويب General → قسم Minimum iOS Deployment. القائمة المنسدلة تظهر جميع إصدارات iOS SDK المتاحة المثبتة في Xcode. التغيير يُطبق على جميع مخططات البناء. بديلاً — علامة التبويب Build Settings → iOS Deployment Target (IPHONEOS_DEPLOYMENT_TARGET). إذا كان المشروع يحتوي على عدة امتدادات (Widget, Watch)، لكل منها Deployment Target خاص به.

الإعداد عبر Swift Package Manager

للمكتبات الموزعة عبر SPM، يتم تحديد Deployment Target في Package.swift في معامل platforms. مكتبة تحتوي على platforms: [.iOS(.v16)] ستكون متاحة فقط للتطبيقات ذات Deployment Target iOS 16.0+. عند إضافة هذه المكتبة إلى مشروع بـ Target 15.0، سيظهر Xcode خطأ عدم التوافق. في CocoaPods، يتم تعيين Deployment Target في Podfile: platform :ios, '16.0'.

// Package.swift — Deployment Target لمكتبة SPM
import PackageDescription

let package = Package(
    name: "MyLibrary",
    platforms: [
        .iOS(.v16),
        .macOS(.v13),
        .watchOS(.v9),
        .tvOS(.v16)
    ],
    products: [
        .library(
            name: "MyLibrary",
            targets: ["MyLibrary"]
        )
    ],
    dependencies: [],
    targets: [
        .target(
            name: "MyLibrary",
            swiftSettings: [
                .enableUpcomingFeature("ConciseMagicFile")
            ]
        )
    ]
)

// التحقق من التوافق في الكود
#if swift(>=5.9)
// ميزات Swift 5.9+ (Xcode 15+)
#endif

في المثال، Package.swift يحدد المنصات iOS 16+، macOS 13+، watchOS 9+، tvOS 16+. أي مشروع بـ Deployment Target أقل من iOS 16.0 لن يتمكن من إضافة هذه المكتبة. معامل swiftSettings يتضمن الميزات القادمة لإصدار Swift محدد. SPM يتحقق تلقائياً من توافق platforms عند إضافة تبعية.

CocoaPods و Podfile

يستخدم Podfile التوجيه platform :ios, '16.0'. بعد pod install، يتحقق CocoaPods من Deployment Target لكل مكتبة pod: إذا كان لدى واحدة على الأقل Target أعلى من المشروع، سيفشل التثبيت مع الخطأ "The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 17.0, but the range of supported deployment target versions is 16.0 to 17.0". الحل هو خفض Target للمكتبة المشكلة أو رفع Target المشروع.

# Podfile — مثال مع Deployment Target
platform :ios, '16.0'

# تجاهل تحذيرات Deployment Target
post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '16.0'
        end
    end
end

خطاف post_install في Podfile يحدد بقوة Deployment Target 16.0 لجميع مكتبات pod. هذا مفيد عندما تحدد إحدى الـ pod Target أعلى مما هو مطلوب لوظائفها. استخدم هذا فقط إذا كنت متأكداً من أن الـ pod لا تستخدم واجهات برمجة تطبيقات من إصدار iOS أعلى.

فحوصات @available و #available في كود Swift و Objective-C

@available و #available هما توجيهات Swift و Objective-C للاستدعاء الآمن لواجهات برمجة التطبيقات المتاحة فقط على إصدارات معينة من نظام التشغيل. إذا كان Deployment Target للمشروع هو iOS 16.0 وطريقة تتطلب iOS 17.0، فإن الاستدعاء المباشر سيؤدي إلى تعطل وقت التشغيل على الأجهزة التي تعمل بـ iOS 16.0–16.x. فحوصات التوفر هي أداة إلزامية لدعم إصدارات متعددة من iOS.

@available — فحص تصريحي

التوجيه @available يُطبق على الفئات أو الطرق أو الملفات بأكملها. إذا تم تحديد @available(iOS 17.0, *) قبل فئة، فإن الفئة بأكملها متاحة فقط على iOS 17.0+. محاولة استدعاء الفئة على iOS 16.0 ستؤدي إلى خطأ وقت التشغيل. استخدم @available لعزل وحدات كاملة من الوظائف الخاصة بإصدار معين من نظام التشغيل. للطرق داخل الفئة، @available يسمح بإخفاء وظائف فردية.

#available — تنفيذ شرطي

التوجيه #available (if #available) يتحقق من إصدار نظام التشغيل في وقت التشغيل وينفذ الكود فقط عند تطابقه. يُستخدم داخل الدوال لاختيار بين التطبيقات الجديدة والقديمة. في Objective-C، المكافئ هو @available(iOS 17.0, *) داخل if. لفحوصات أكثر تعقيداً، استخدم ProcessInfo.processInfo.isOperatingSystemAtLeast لمقارنة مكونات الإصدار (major, minor, patch).

import UIKit
import SwiftUI

// 1. @available — الفئة بأكملها فقط لـ iOS 17+
@available(iOS 17.0, *)
class ObservationViewModel: ObservableObject {
    @Published var name: String = "User"

    // يستخدم Observation framework — متاح فقط iOS 17+
    func updateWithObservation() {
        let newName = "Updated via Observation"
        name = newName
    }
}

// 2. #available — استدعاء شرطي داخل الدالة
func configureLiveActivity() {
    if #available(iOS 16.1, *) {
        // واجهة برمجة Live Activities — متاحة منذ iOS 16.1
        let activity = Activity<MyAttributes>(
            attributes: MyAttributes(name: "Live"),
            contentState: MyContentState(value: 42)
        )
        Task {
            await activity.activate()
        }
    } else {
        // البديل: إشعار push أو لا شيء
        print("Live Activities غير متاحة")
    }
}

// 3. ProcessInfo — تحقق دقيق من الإصدار
func checkOSVersion() {
    let osVersion = ProcessInfo.processInfo.operatingSystemVersion
    print("iOS \(osVersion.majorVersion).\(osVersion.minorVersion).\(osVersion.patchVersion)")

    // مقارنة المكونات
    if osVersion.majorVersion >= 17 {
        print("iOS 17+ تم الكشف عنه")
    }
}

// 4. Objective-C @available
// Objective-C يستخدم @available:
// if (@available(iOS 17.0, *)) { }

// 5. @available مع وسيطة unavailable
@available(*, unavailable, message: "Use configureWithSwiftUI instead")
func legacyConfigureMethod() { }

الفئة ObservationViewModel تستخدم @available لعزل وظائف iOS 17. الدالة configureLiveActivity تستخدم #available للتحقق من Live Activities (iOS 16.1+) مع تطبيق احتياطي. ProcessInfo تتحقق من الإصدار الدقيق لنظام التشغيل. @available(*, unavailable) يسمي طريقة كغير متاحة على جميع الإصدارات — للترحيل إلى واجهة برمجة تطبيقات جديدة. بدون هذه الفحوصات، التطبيق ذو Deployment Target 16.0 سيتعطل على الأجهزة التي تعمل بـ iOS 16.0 عند استدعاء واجهات برمجة تطبيقات iOS 17.

Objective-C و @available

يستخدم Objective-C @available(iOS 17.0, *) بنفس دلالات Swift #available. الفرق: Objective-C يتحقق في وقت التشغيل، Swift #available أيضاً في وقت التشغيل لكن مع تلميحات للمُحسّن لتحسين التفرع. لكود Objective-C المتفاعل مع Swift، فحوصات التوفر ضرورية على جانب Objective-C — الجسر (bridging) في Swift لا يضيف فحوصات تلقائية.

كيفية اختيار Deployment Target المناسب لمشروعك

اختيار iOS Deployment Target هو قرار استراتيجي يؤثر على ثلاثة جوانب: مدى وصول الجمهور، واجهات برمجة التطبيقات المتاحة، وتعقيد صيانة الكود. لا توجد قيمة صحيحة واحدة — يعتمد الاختيار على الجمهور المستهدف للتطبيق، والوظائف المطلوبة الدنيا، وموارد الفريق لدعم التوافق العكسي.

العامل الأول — إحصائيات استخدام إصدارات iOS. تنشر Apple بيانات تثبيت iOS في WWDC وفي Apple Developer Dashboard. حتى يونيو 2025، التوزيع هو: iOS 15 — ~7%، iOS 16 — ~48%، iOS 17 — ~35%، iOS 18 — ~10%. اختيار Target 16.0 يوفر تغطية 83%، Target 17.0 — 35%. للتطبيقات الجماهيرية (الشبكات الاجتماعية، التراسل، التجارة الإلكترونية)، يُوصى بـ Target 16.0. لتطبيقات B2B المتخصصة ذات واجهات برمجة تطبيقات محددة — Target 17.0.

العامل الثاني — واجهات برمجة التطبيقات المطلوبة. إذا كانت الميزة الرئيسية للتطبيق تتطلب SwiftData (iOS 17+) أو Observation (iOS 17+) أو Live Activities (iOS 16.1+)، لا يمكن أن يكون Target أقل من الإصدار المطلوب. تحليل واجهات برمجة التطبيقات المطلوبة في مرحلة التصميم يمنع الموقف الذي يكتشف فيه في منتصف التطوير الحاجة إلى Target أعلى. استخدم فحوصات التوفر كخطة احتياطية، وليس كاستراتيجية أساسية.

العامل الثالث — موارد الاختبار. دعم إصدارات iOS القديمة يتطلب اختباراً على المحاكيات والأجهزة الحقيقية بتلك الإصدارات. iOS 15 يُختبر على iPhone 6s/7، iOS 16 — على iPhone 8/X، iOS 17 — على iPhone XS/XR. كل إصدار إضافي للتوافق العكسي يزيد من وقت ضمان الجودة. إذا كان الفريق صغيراً، من المعقول اختيار Target أقل بمقدار 2–3 إصدارات من الإصدار الحالي (16.0) — توازن بين التغطية والجهد.

يجب أن يكون للمكتبات و SDK أقل Deployment Target ممكن (15.0 أو حتى 14.0) — قد يكون لدى مستهلكي المكتبة أي Target أعلى من مكتبتك. إذا كانت المكتبة تتطلب iOS 17.0، فلن يتمكن نصف المشاريع من استخدامها. للتطبيقات، على العكس، يمكنك السماح بـ Target أعلى للوصول إلى واجهات برمجة تطبيقات جديدة.

كيفية خفض Deployment Target بعد رفعه

خفض iOS Deployment Target هي مهمة تظهر عند الحاجة لتوسيع الجمهور أو عند نشر مكتبة بتوافق مع المشاريع القديمة. على عكس الرفع، يتطلب الخفض عملاً نشطاً مع الكود: تحتاج إلى استبدال جميع الاستدعاءات المباشرة لواجهات برمجة التطبيقات غير المتاحة في الـ Target الجديد (الأقل) بفحوصات #available وتطبيقات احتياطية.

الخطوة الأولى — جرد واجهات برمجة التطبيقات. لا يصدر Xcode أخطاء تجميع عند خفض الـ Target — إنه يحذر فقط بتحذيرات صفراء. تحتاج إلى العثور على جميع الطرق والفئات الموسومة بـ @available(iOS N+, *) حيث N أعلى من الـ Target الجديد. استخدم البحث في المشروع (Cmd+Shift+F) بالنمط "available(iOS". كل استدعاء من هذا القبيل هو مرشح لإعادة الهيكلة.

الخطوة الثانية — الاستبدال بفحوصات #available. كل استدعاء لواجهة برمجة تطبيقات من إصدار أعلى يُلف في if #available(iOS N+, *) { } else { }. للفئات بأكملها، استخدم #if os(iOS) مع @available على مستوى النوع. إذا لم يكن لواجهة برمجة التطبيقات بديل معقول (مثل Live Activities)، يتم تعطيل الوظيفة للإصدارات القديمة مع إشعار المستخدم.

import UIKit
import SwiftUI

// خفض Deployment Target من 17.0 إلى 16.0

// قبل (@available iOS 17.0):
@available(iOS 17.0, *)
func setupObservation() {
    // Observation framework — فقط iOS 17+
    let model = ObservationViewModel()
    // ...
}

// بعد (فحص #available):
func setupObservationCompatible() {
    if #available(iOS 17.0, *) {
        // iOS 17+: Observation framework
        let model = ObservationViewModel()
        // ...
    } else {
        // iOS 16.x: ObservableObject مع @Published
        let model = LegacyObservableViewModel()
        // ...
    }
}

// لواجهة برمجة UIKit iOS 17+:
@available(iOS 17.0, *)
class ModernViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        // يستخدم UIKit TraitChanges (iOS 17+)
        registerForTraitChanges([UITraitVerticalSizeClass.self]) { _, _ in }
    }
}

// البديل لـ iOS 16:
class LegacyViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        // لا يوجد registerForTraitChanges — استخدام traitCollectionDidChange
    }

    override func traitCollectionDidChange(_: UITraitCollection?) {
        super.traitCollectionDidChange(nil)
        // معالجة تغييرات traits لـ iOS 16
    }
}

// مصنع لاختيار التطبيق حسب إصدار iOS
func makeViewController() -> UIViewController {
    if #available(iOS 17.0, *) {
        return ModernViewController()
    } else {
        return LegacyViewController()
    }
}

الكود يوضح خفض الـ Target من iOS 17.0 إلى 16.0. الدالة setupObservation تم استبدالها بـ setupObservationCompatible مع فحص #available. تم تقسيم ViewController إلى Modern (iOS 17+) و Legacy (iOS 16) مع مصنع makeViewController يختار التطبيق حسب إصدار نظام التشغيل. هذه البنية تسمح بدعم اثنين من Deployment Target دون تكرار قاعدة الكود بأكملها — فقط وحدات مرقمة الإصدارات.

تحذيرات Xcode وحلها

بعد خفض Deployment Target، سيبرز Xcode باللون الأصفر جميع استدعاءات واجهات برمجة التطبيقات غير المتاحة في الـ Target الجديد. التحذير "In iOS 16.0 and later" يعني أن الطريقة تتطلب إصداراً أعلى. الحلول: إضافة @available أو if #available (موصى به)، أو القمع عبر @available(*, deprecated) للترحيل التدريجي، أو إزالة الاستدعاء. تفعيل "Treat Warnings as Errors" في المشروع سيحول هذه التحذيرات إلى أخطاء تجميع — قم بتفعيل هذا الخيار للتحكم.