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 کا طریقہ کار انسٹالیشن کے دوران OS ورژن کی جانچ پر مبنی ہے۔ iOS App Store Info.plist (کلید MinimumOSVersion) سے Deployment Target کی قدر کو صارف کے آلے پر OS ورژن کے ساتھ موازنہ کرتا ہے۔ اگر آلہ کا ورژن کم ہے — تو "ڈاؤن لوڈ" بٹن مسدود ہو جاتا ہے، اور App Store API اس آلہ کے لیے تلاش کے نتائج میں ایپلیکیشن واپس نہیں کرتا۔ یہی رویہ TestFlight، ad-hoc اور انٹرپرائز تقسیم پر بھی لاگو ہوتا ہے۔

StatCounter کے جون 2025 کے اعداد و شمار کے مطابق، iOS 16 فعال iPhone آلات کا تقریباً 48% حصہ ہے، iOS 17 — 35%، iOS 18 — 12%، پرانے ورژن — تقریباً 5%۔ Deployment Target 16.0 کا انتخاب 83% آلات کا احاطہ کرتا ہے، Target 17.0 — 35% (صرف iOS 17+)۔ یہ اعداد و شمار فیصلہ سازی کے لیے اہم ہیں: Target جتنا زیادہ ہوگا، سامعین اتنا ہی چھوٹا ہوگا، لیکن جدید ترین SwiftUI اور UIKit APIs تک رسائی اتنی ہی آسان ہوگی۔

iOS کی ہر نئی ریلیز نہ صرف صارف کی خصوصیات بلکہ ڈویلپرز کے لیے APIs بھی شامل کرتی ہے۔ نئے SwiftUI موڈیفائر، UIKit طریقے، SwiftData اور Observation جیسے فریم ورک صرف ایک مخصوص Deployment Target پر دستیاب ہوتے ہیں۔ ڈویلپر کو سامعین کی رسائی اور جدید آلات کی دستیابی کے درمیان توازن برقرار رکھنا ہوتا ہے۔

iOS Deployment Target بمقابلہ minSdkVersion: Android سے موازنہ

iOS Deployment Target اور Android کا minSdkVersion ایک ہی کام کرتے ہیں — ایپلیکیشن کے لیے کم از کم OS ورژن سیٹ کرنا۔ تاہم، نفاذ کے میکانزم اور متعلقہ آلات مختلف ہیں۔ ان فرقوں کو سمجھنا دونوں پلیٹ فارمز پر کام کرنے والے ڈویلپرز کے لیے مفید ہے اور ایکو سسٹم کے درمیان سوئچ کرتے وقت الجھن سے بچنے میں مدد کرتا ہے۔

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) اور آلہ پر OS ورژن۔

بنیادی فرق یہ ہے کہ iOS میں Base SDK ہمیشہ Xcode میں نصب تازہ ترین ورژن ہوتا ہے۔ ڈویلپر Android کی طرح compileSdkVersion کا انتخاب نہیں کر سکتا — ایپلیکیشن ہمیشہ دستیاب تازہ ترین 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 کے ساتھ رویے کی تبدیلیوں کے لیے تیار رہنا ہوتا ہے۔

دونوں پلیٹ فارمز کا علم کم از کم ورژن کے انتخاب کے نتائج کی پیش گوئی کرنے اور نئے APIs کے لیے کوڈ اپ ڈیٹس کی منصوبہ بندی کرنے کی اجازت دیتا ہے۔ IT Sectr میں، ہم 2017 سے دونوں ایکو سسٹم استعمال کر رہے ہیں — مشق سے پتہ چلتا ہے کہ کوریج اور فعالیت کے توازن کے لیے iOS Deployment Target کو موجودہ سے 2–3 ورژن نیچے منتخب کرنا چاہیے۔

Xcode میں Deployment Target کیسے سیٹ کریں

iOS Deployment Target کی ترتیب پروجیکٹ میں کئی جگہوں پر کی جاتی ہے: مرکزی Target، Pods پروجیکٹ (اگر CocoaPods استعمال کیا گیا ہے)، Swift Package Manager انحصار اور Widget/Extension اہداف۔ اگر مرکزی ایپلیکیشن اور ایکسٹینشن کے درمیان قدریں مختلف ہوں، تو App Store ان سب میں سے زیادہ سے زیادہ استعمال کرتا ہے — یعنی ایک ایکسٹینشن کا Target مرکزی ایپلیکیشن سے کم نہیں ہو سکتا۔

Xcode پروجیکٹ ایڈیٹر میں ترتیب

Xcode پروجیکٹ کھولیں → Target منتخب کریں → General ٹیب → Minimum iOS Deployment سیکشن۔ ڈراپ ڈاؤن Xcode میں نصب تمام دستیاب iOS SDK ورژن دکھاتا ہے۔ تبدیلی تمام بلڈ اسکیموں پر لاگو ہوتی ہے۔ متبادل — Build Settings ٹیب → iOS Deployment Target (IPHONEOS_DEPLOYMENT_TARGET)۔ اگر پروجیکٹ میں متعدد 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 — SPM لائبریری کے لیے Deployment Target
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+ سیٹ کرتا ہے۔ iOS 16.0 سے کم Deployment Target والا کوئی بھی پروجیکٹ اس لائبریری کو شامل نہیں کر سکے گا۔ swiftSettings پیرامیٹر میں ایک مخصوص Swift ورژن کے لیے آنے والی خصوصیات شامل ہیں۔ SPM انحصار شامل کرتے ہوئے خود بخود platforms مطابقت کی جانچ کرتا ہے۔

CocoaPods اور Podfile

Podfile ہدایت platform :ios, '16.0' استعمال کرتا ہے۔ pod install کے بعد، CocoaPods ہر pod لائبریری کے Deployment Target کی جانچ کرتا ہے: اگر کم از کم ایک کا 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" کی غلطی کے ساتھ ناکام ہو جائے گی۔ حل مسئلہ والے pod کا 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

Podfile میں post_install ہک تمام pod لائبریریوں کے لیے زبردستی Deployment Target 16.0 سیٹ کرتا ہے۔ یہ اس وقت مفید ہے جب کوئی pod اپنی فعالیت کے لیے ضرورت سے زیادہ Target بتاتا ہے۔ اسے صرف اس صورت میں استعمال کریں جب آپ کو یقین ہو کہ pod کسی اعلی iOS ورژن کے APIs استعمال نہیں کرتا۔

Swift اور Objective-C کوڈ میں @available اور #available چیک

@available اور #available Swift اور Objective-C ہدایات ہیں جو صرف مخصوص OS ورژن پر دستیاب APIs کو محفوظ طریقے سے کال کرنے کے لیے ہیں۔ اگر پروجیکٹ کا 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 پر کلاس کو کال کرنے کی کوشش رن ٹائم غلطی کا سبب بنے گی۔ کسی مخصوص OS ورژن کے لیے مخصوص فعالیت کے پورے ماڈیولز کو الگ کرنے کے لیے @available استعمال کریں۔ کلاس کے اندر طریقوں کے لیے، @available انفرادی افعال کو چھپانے کی اجازت دیتا ہے۔

#available — مشروط عملدرآمد

#available ہدایت (if #available) رن ٹائم پر OS ورژن کی جانچ کرتی ہے اور صرف مماثل ہونے پر کوڈ پر عمل کرتی ہے۔ نئے اور پرانے نفاذ کے درمیان انتخاب کرنے کے لیے افعال کے اندر استعمال ہوتی ہے۔ Objective-C میں، if کے اندر @available(iOS 17.0, *) برابر ہے۔ مزید پیچیدہ جانچوں کے لیے، ورژن اجزاء (major, minor, patch) کا موازنہ کرنے کے لیے ProcessInfo.processInfo.isOperatingSystemAtLeast استعمال کریں۔

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 API — 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 کلاس iOS 17 فعالیت کو الگ کرنے کے لیے @available استعمال کرتی ہے۔ configureLiveActivity فنکشن فال بیک نفاذ کے ساتھ Live Activities (iOS 16.1+) کی جانچ کرنے کے لیے #available استعمال کرتا ہے۔ ProcessInfo درست OS ورژن کی جانچ کرتا ہے۔ @available(*, unavailable) ایک طریقہ کو تمام ورژنز پر غیر دستیاب کے طور پر نشان زد کرتا ہے — نئے API میں منتقلی کے لیے۔ ان جانچوں کے بغیر، Deployment Target 16.0 والی ایپلیکیشن iOS 17 APIs کو کال کرتے ہوئے iOS 16.0 والے آلات پر کریش ہو جائے گی۔

Objective-C اور @available

Objective-C Swift #available کی طرح ایک ہی معنوں میں @available(iOS 17.0, *) استعمال کرتا ہے۔ فرق: Objective-C رن ٹائم پر جانچ کرتا ہے، Swift #available بھی رن ٹائم پر ہے لیکن شاخ کی اصلاح کے لیے کمپائلر اشاروں کے ساتھ۔ Swift کے ساتھ بات چیت کرنے والے Objective-C کوڈ کے لیے، Objective-C طرف دستیابی کی جانچ ضروری ہے — Swift بریجنگ خودکار جانچیں شامل نہیں کرتا۔

اپنے پروجیکٹ کے لیے صحیح Deployment Target کیسے منتخب کریں

iOS Deployment Target کا انتخاب ایک تزویراتی فیصلہ ہے جو تین پہلوؤں کو متاثر کرتا ہے: سامعین کی رسائی، دستیاب APIs اور کوڈ کی دیکھ بھال کی پیچیدگی۔ کوئی ایک صحیح قدر نہیں ہے — انتخاب کا انحصار ایپلیکیشن کے ہدف سامعین، کم از کم مطلوبہ خصوصیات اور پسماندہ مطابقت کی حمایت کے لیے ٹیم کے وسائل پر ہے۔

پہلا عنصر — iOS ورژن کے استعمال کے اعدادوشمار۔ Apple WWDC اور Apple Developer Dashboard میں iOS انسٹالیشن ڈیٹا شائع کرتا ہے۔ جون 2025 تک، تقسیم یہ ہے: iOS 15 — ~7%، iOS 16 — ~48%، iOS 17 — ~35%، iOS 18 — ~10%۔ Target 16.0 کا انتخاب 83% کوریج فراہم کرتا ہے، Target 17.0 — 35%۔ بڑے پیمانے کی ایپلیکیشنز (سوشل نیٹ ورکس، میسنجر، ای کامرس) کے لیے Target 16.0 تجویز کیا جاتا ہے۔ مخصوص API ضروریات والی B2B ایپلیکیشنز کے لیے — Target 17.0۔

دوسرا عنصر — مطلوبہ APIs۔ اگر ایپلیکیشن کی اہم خصوصیت کو SwiftData (iOS 17+)، Observation (iOS 17+) یا Live Activities (iOS 16.1+) کی ضرورت ہے، تو Target مطلوبہ ورژن سے کم نہیں ہو سکتا۔ ڈیزائن کے مرحلے میں مطلوبہ APIs کا تجزیہ اس صورت حال کو روکتا ہے جہاں ترقی کے درمیان میں پتہ چلتا ہے کہ زیادہ Target کی ضرورت ہے۔ دستیابی کی جانچوں کو بیک اپ پلان کے طور پر استعمال کریں، بنیادی حکمت عملی کے طور پر نہیں۔

تیسرا عنصر — جانچ کے وسائل۔ پرانے iOS ورژنز کی حمایت کے لیے ان ورژنز کے سمیلیٹرز اور حقیقی آلات پر جانچ کی ضرورت ہوتی ہے۔ iOS 15 کا تجربہ iPhone 6s/7 پر، iOS 16 — iPhone 8/X پر، iOS 17 — iPhone XS/XR پر کیا جاتا ہے۔ پسماندہ مطابقت کا ہر اضافی ورژن QA وقت بڑھاتا ہے۔ اگر ٹیم چھوٹی ہے، تو موجودہ سے 2–3 ورژن کم Target (16.0) منتخب کرنا معقول ہے — کوریج اور کوشش کے درمیان توازن۔

لائبریریوں اور SDKs کا Deployment Target ممکنہ حد تک کم ہونا چاہیے (15.0 یا 14.0 بھی) — لائبریری استعمال کرنے والوں کا آپ سے زیادہ کوئی بھی Target ہو سکتا ہے۔ اگر کسی لائبریری کو iOS 17.0 کی ضرورت ہے، تو آدھے پروجیکٹ اسے استعمال نہیں کر سکیں گے۔ ایپلیکیشنز کے لیے، دوسری طرف، آپ نئے APIs تک رسائی کے لیے زیادہ Target برداشت کر سکتے ہیں۔

Deployment Target بڑھانے کے بعد اسے کیسے کم کریں

iOS Deployment Target کم کرنا ایک کام ہے جو سامعین کو بڑھانے کی ضرورت ہونے پر یا پرانے پروجیکٹوں کے ساتھ مطابقت رکھنے والی لائبریری شائع کرتے وقت پیدا ہوتا ہے۔ بڑھانے کے برعکس، کم کرنے کے لیے کوڈ کے ساتھ فعال کام کی ضرورت ہوتی ہے: آپ کو نئے (کم) Target میں غیر دستیاب تمام APIs کی براہ راست کالوں کو #available جانچوں اور فال بیک نفاذ سے بدلنا ہوگا۔

پہلا قدم — API انوینٹری۔ Target کم کرتے وقت Xcode کمپائلیشن کی غلطیاں نہیں دکھاتا — یہ صرف پیلے انتباہات سے آگاہ کرتا ہے۔ آپ کو @available(iOS N+, *) سے نشان زد تمام طریقوں اور کلاسز کو تلاش کرنا ہوگا جہاں N نئے Target سے زیادہ ہے۔ پیٹرن "available(iOS" کے ساتھ پروجیکٹ تلاش (Cmd+Shift+F) استعمال کریں۔ ایسی ہر کال ری فیکٹرنگ کے لیے امیدوار ہے۔

دوسرا قدم — #available جانچوں سے تبدیل کرنا۔ اعلی ورژن سے ہر API کال if #available(iOS N+, *) { } else { } میں لپیٹی جاتی ہے۔ پوری کلاسز کے لیے، قسم کی سطح پر @available کے ساتھ #if os(iOS) استعمال کریں۔ اگر کسی API کے پاس معقول فال بیک نہیں ہے (مثال کے طور پر، 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: @Published کے ساتھ ObservableObject
        let model = LegacyObservableViewModel()
        // ...
    }
}

// UIKit iOS 17+ API کے لیے:
@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)
        // iOS 16 کے لیے traits تبدیلیوں کو ہینڈل کرنا
    }
}

// iOS ورژن کے مطابق نفاذ منتخب کرنے کے لیے فیکٹری
func makeViewController() -> UIViewController {
    if #available(iOS 17.0, *) {
        return ModernViewController()
    } else {
        return LegacyViewController()
    }
}

کوڈ Target کو iOS 17.0 سے 16.0 تک کم کرنے کا مظاہرہ کرتا ہے۔ setupObservation فنکشن کو #available جانچ کے ساتھ setupObservationCompatible سے بدل دیا گیا ہے۔ ViewController کو Modern (iOS 17+) اور Legacy (iOS 16) میں تقسیم کیا گیا ہے جس میں makeViewController فیکٹری OS ورژن کے مطابق نفاذ کا انتخاب کرتی ہے۔ یہ فن تعمیر پورے کوڈبیس کو نقل کیے بغیر دو Deployment Target کی حمایت کرنے کی اجازت دیتا ہے — صرف ورژن شدہ ماڈیول۔

Xcode انتباہات اور ان کا حل

Deployment Target کم کرنے کے بعد، Xcode نئے Target میں غیر دستیاب تمام API کالوں کو پیلے رنگ میں نمایاں کرے گا۔ انتباہ "In iOS 16.0 and later" کا مطلب ہے کہ طریقہ کو اعلی ورژن کی ضرورت ہے۔ حل: @available یا if #available شامل کریں (تجویز کردہ)، بتدریج منتقلی کے لیے @available(*, deprecated) کے ذریعے دبائیں، یا کال ہٹا دیں۔ پروجیکٹ میں "Treat Warnings as Errors" کو فعال کرنے سے یہ انتباہات کمپائلیشن کی غلطیوں میں بدل جائیں گے — کنٹرول کے لیے اس آپشن کو فعال کریں۔