Info.plist Usage Description — یہ کیا ہے، NS*UsageDescription کلیدیں اور ترتیبات

Info.plist Usage Description کیا ہے؟

Info.plist Usage Description NS*UsageDescription سابقہ والی کلیدوں کی سٹرنگ ویلیوز ہیں جو iOS کے محفوظ وسائل تک رسائی کی درخواست کرتے وقت سسٹم ڈائیلاگ کا متن متعین کرتی ہیں۔ جب کوئی ایپ پہلی بار کسی API کو کال کرتی ہے جس کے لیے صارف کی اجازت درکار ہوتی ہے (مثال کے طور پر، کیمرے کے لیے AVCaptureDevice)، iOS اس متن اور اجازت/مسترد کرنے کے بٹنوں کے ساتھ ایک ڈائیلاگ دکھاتا ہے۔

تفصیل کا متن واحد چیز ہے جسے ڈویلپر سسٹم ڈائیلاگ میں کنٹرول کر سکتا ہے۔ ڈائیلاگ کا عنوان “<ایپ کا نام> [وسیلہ] تک رسائی چاہتا ہے” iOS کے ذریعہ درخواست کردہ وسیلہ کی قسم کی بنیاد پر خود بخود تیار کیا جاتا ہے۔ ڈویلپر عنوان، بٹن یا ظاہری شکل تبدیل نہیں کر سکتا — صرف وضاحتی متن۔

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

Apple سختی سے سفارش کرتا ہے کہ تفصیل میں رسائی کی درخواست کی ایک مخصوص وجہ بتائی جائے۔ مثال کے طور پر، “پروفائل تصاویر لینے کے لیے” “کیمرے تک رسائی کے لیے” سے بہتر ہے۔ مخصوص متن صارف کا اعتماد اور اجازت دینے کی شرح بڑھاتے ہیں۔ Localytics (2023) کے مطابق، حسب ضرورت تفصیلات عام الفاظ کے مقابلے میں رضامندی میں 15-25% اضافہ کرتی ہیں۔

Usage Description اور ATT میں فرق

NS*UsageDescription کو ATT (App Tracking Transparency) کے ساتھ الجھائیں نہیں۔ Usage Description سسٹم وسائل (کیمرہ، جغرافیائی محل وقوع، تصاویر) تک رسائی کی درخواست ہے، جبکہ ATT ٹریکنگ (IDFA تک رسائی) کی درخواست ہے۔ ATT ایک علیحدہ فریم ورک AppTrackingTransparency اور NSUserTrackingUsageDescription کلید استعمال کرتا ہے، جو NS*UsageDescription کا حصہ نہیں ہے۔

دونوں میں مشترک بات یہ ہے کہ دونوں سسٹم ڈائیلاگ استعمال کرتے ہیں جس کا متن ایپ تبدیل نہیں کر سکتی۔ فرق یہ ہے کہ Usage Description وسیلہ کی سطح پر کام کرتا ہے، جبکہ ATT ڈیوائس شناخت کنندہ کی سطح پر کام کرتا ہے۔ NS*UsageDescription کلیدیں iOS 6 میں متعارف کرائی گئیں، ATT — iOS 14.5 میں۔

مختلف iOS ورژنز میں کلیدوں کا ارتقاء

ہر iOS ریلیز کے ساتھ، Apple نے نئے محفوظ وسائل اور متعلقہ کلیدیں شامل کیں۔ iOS 6: رابطے، کیلنڈر، یاد دہانیاں، تصاویر۔ iOS 7: مائیکروفون۔ iOS 8: HomeKit، صحت۔ iOS 10: میڈیا لائبریری، Siri۔ iOS 11: NFC۔ iOS 14: ٹریکنگ (ATT)۔ iOS 17: کلپ بورڈ تک رسائی (اضافی تصدیق درکار)۔

اہم: اگر ایپ کسی مخصوص iOS ورژن میں متعارف کرائی گئی API استعمال کرتی ہے لیکن کم از کم تعاون یافتہ ورژن کم ہے، تو کلید پھر بھی لازمی ہے۔ iOS پہلی API کال سے پہلے کلید کی موجودگی چیک کرتا ہے، قطع نظر اس کے کہ ایپ کس ورژن پر چل رہی ہے۔

لازمی NS*UsageDescription کلیدیں

کلیدوں کی مکمل فہرست اس بات پر منحصر ہے کہ ایپ کون سی خصوصیات استعمال کرتی ہے۔ آئیے موبائل ایپس میں سب سے زیادہ درکار 14 اہم کلیدوں کا جائزہ لیتے ہیں۔

میڈیا تک رسائی

NSCameraUsageDescription کلید AVCaptureDevice یا .camera ماخذ کے ساتھ UIImagePickerController کے ذریعے کیمرے تک رسائی کے وقت لازمی ہے۔ NSMicrophoneUsageDescription کلید AVAudioRecorder کے ذریعے آڈیو ریکارڈ کرنے یا آواز کے ساتھ ویڈیو شوٹ کرنے کے وقت ضروری ہے۔ اگر ایپ ویڈیو ریکارڈ کرتی ہے تو اکثر دونوں کلیدیں ایک ساتھ درکار ہوتی ہیں۔

NSPhotoLibraryUsageDescription کلید PHPicker یا UIImagePickerController کے ذریعے صارف کے میڈیا لائبریری سے تصاویر اور ویڈیوز پڑھنے کے وقت استعمال ہوتی ہے۔ NSPhotoLibraryAddUsageDescription کلید اس وقت استعمال ہوتی ہے جب ایپ صرف تصاویر محفوظ کرتی ہے لیکن انہیں نہیں پڑھتی۔ پہلی پڑھنے کی اجازت مانگتی ہے، دوسری — صرف لکھنے کی۔

جغرافیائی محل وقوع اور نیویگیشن

NSLocationWhenInUseUsageDescription کلید ایپ کے فعال ہونے پر (اسکرین پر) جغرافیائی محل وقوع تک رسائی فراہم کرتی ہے۔ NSLocationAlwaysAndWhenInUseUsageDescription ہمیشہ رسائی فراہم کرتی ہے (بیک گراؤنڈ موڈ سمیت)۔ اگر ہمیشہ رسائی درکار ہو تو iOS دونوں کلیدیں چاہتا ہے: پہلے WhenInUse، پھر Always۔

NSLocationTemporaryUsageDescription اور NSLocationPreciseUsageDescription کلیدیں عارضی رسائی یا درست جغرافیائی محل وقوع کی درخواست کے لیے اضافی کلیدیں ہیں۔ درست مقام کے لیے علیحدہ اجازت درکار ہے، اور صارف صرف تخمینی مقام کو فعال کر سکتا ہے۔

رابطے، کیلنڈر اور دیگر ڈیٹا

NSContactsUsageDescription کلید CNContactStore کے ذریعے صارف کے رابطوں تک رسائی فراہم کرتی ہے۔ NSCalendarsUsageDescription واقعات پڑھنے اور بنانے کے لیے کیلنڈر تک رسائی فراہم کرتی ہے۔ NSRemindersUsageDescription یاد دہانیوں تک رسائی فراہم کرتی ہے۔ NSBluetoothAlwaysUsageDescription بیک گراؤنڈ میں Bluetooth تک رسائی فراہم کرتی ہے (مثال کے طور پر، BLE آلات کے لیے)۔

NSHealthShareUsageDescription کلید HealthKit ڈیٹا پڑھنے کی رسائی فراہم کرتی ہے۔ NSHealthUpdateUsageDescription HealthKit میں ڈیٹا لکھنے کی رسائی فراہم کرتی ہے۔ اگر ایپ صحت کے ڈیٹا کے ساتھ کام کرتی ہے تو دونوں لازمی ہیں۔ Apple HealthKit استعمال کرنے والی ایپس کا بغور جائزہ لیتا ہے اور اگر استعمال کی تفصیل فعالیت سے مطابقت نہیں رکھتی تو ایپ کو مسترد کر سکتا ہے۔

تفصیل صحیح طریقے سے کیسے لکھیں

Usage Description میں متن مخصوص، سچا اور مختصر ہونا چاہیے۔ Apple الفاظ کے انتخاب پر سفارشات فراہم کرتا ہے، اور جائزہ لینے والے فعالیت سے مطابقت کی جانچ کرتے ہیں۔

اچھی تفصیل کا ڈھانچہ

ایک اچھی تفصیل تین حصوں پر مشتمل ہوتی ہے: ایپ وسیلہ کے ساتھ بالکل کیا کرتی ہے، صارف کو اس کی ضرورت کیوں ہے، اور رسائی دینے سے صارف کو کیا فائدہ ہوتا ہے۔ مثال: “پروفائل تصاویر لینے اور اپنے پروفائل پر اپ لوڈ کرنے کے لیے۔” عام فقروں سے پرہیز کریں: “ایپ کی کارکردگی بہتر بنانے کے لیے” یہ نہیں بتاتا کہ کیمرے کی ضرورت کیوں ہے۔

Apple گمراہ کن تفصیلات کو منع کرتا ہے۔ اگر “تصاویر لینے کے لیے” لکھا ہو لیکن ایپ ویڈیو بھی ریکارڈ کرتی ہو، تو اسے دھوکہ دہی سمجھا جا سکتا ہے۔ جائزہ لینے والا ایپ کو مسترد کر سکتا ہے یا وضاحت طلب کر سکتا ہے۔ iOS 17 میں، Apple نے خودکار تصدیق شامل کی: تفصیل میں درخواست کردہ وسیلہ سے مطابقت رکھنے والے کلیدی الفاظ ہونے چاہئیں۔

مقامی کاری: تفصیل کا ایپ کے تعاون یافتہ تمام زبانوں میں ترجمہ ہونا چاہیے۔ اگر ایپ 10 زبانوں میں دستیاب ہے، تو ہر Usage Description کلید کے Localizable.strings یا InfoPlist.strings فائلوں میں ترجمے ہونے چاہئیں۔ Apple Info.plist کلیدوں کی مقامی کاری کے لیے InfoPlist.strings استعمال کرنے کی سفارش کرتا ہے۔

بری اور اچھی مثالیں

• بری: “کیمرہ تک رسائی درکار ہے” — وجہ نہیں بتاتی
• اچھی: “ادائیگی کے وقت QR کوڈ اسکین کرنے کے لیے” — مخصوص اور واضح
• بری: “مقام کا تعین کرنے کے لیے” — مبہم
• اچھی: “نقشے پر قریبی ریستوران تلاش کرنے کے لیے” — قدر دکھاتی ہے
• بری: “خدمت بہتر بنانے کے لیے” — غیر معلوماتی
• اچھی: “مصنوعات کے جائزے میں تصاویر اپ لوڈ کرنے کے لیے” — مخصوص عمل

InfoPlist.strings کے ذریعے مقامی کاری

Usage Description کو مقامی بنانے کے لیے، ہر زبان کے لیے Info.plist کو نقل کرنے کی ضرورت نہیں ہے۔ ہر زبان کی ڈائریکٹری میں InfoPlist.strings فائل بنائیں اور کلید کی قدریں متعین کریں۔ iOS ڈائیلاگ دکھاتے وقت خود بخود درست زبان استعمال کرے گا۔ Xcode ورژن 14 سے Info.plist کے لیے بنیادی مقامی کاری کو سپورٹ کرتا ہے۔

<!-- InfoPlist.strings (Russian) -->
"NSCameraUsageDescription" =
    "QR کوڈز اسکین کرنے کے لیے";
"NSPhotoLibraryUsageDescription" =
    "پروفائل میں تصاویر اپ لوڈ کرنے کے لیے";
"NSLocationWhenInUseUsageDescription" =
    "نقشے پر قریبی اسٹورز دکھانے کے لیے";

نفاذ: کوڈ اور ترتیبات

Usage Description کے صحیح نفاذ میں Info.plist میں کلیدیں شامل کرنا، کوڈ میں اجازت کی حیثیت چیک کرنا اور مستردی کو سنبھالنا شامل ہے۔

Xcode کے ذریعے کلیدیں شامل کرنا

Xcode میں، Info.plist کھولیں، ایک قطار پر ہوور کریں اور “+” پر کلک کریں۔ کلید کا نام درج کریں (مثال کے طور پر، NSCameraUsageDescription) اور تفصیل کا سٹرنگ متعین کریں۔ Xcode کلید کے نام خود بخود مکمل کرتا ہے، جس سے ٹائپو کا خطرہ کم ہوتا ہے۔ شامل کرنے کے بعد، پروجیکٹ کو دوبارہ بنائیں اور تصدیق کریں کہ کلید حتمی بائنری میں نظر آتی ہے۔

اہم: کلیدیں کیس حساس ہوتی ہیں۔ NSCameraUsageDescription درست ہے، NSCamerausagedescription غلطی ہے۔ غلط کلید کو نظر انداز کیا جاتا ہے، اور API کال کرنے پر ایپ کریش ہو جائے گی۔ ٹائپو سے بچنے کے لیے Apple کی دستاویزات سے کاپی کریں یا Xcode آٹو کمپلیٹ استعمال کریں۔

import AVFoundation
import Photos

final class PermissionManager {
    static func checkCameraPermission() {
        let status = AVCaptureDevice.authorizationStatus(for: .video)
        switch status {
        case .notDetermined:
            AVCaptureDevice.requestAccess(for: .video) { granted in
                print("Camera access: \(granted)")
            }
        case .denied:
            print("Camera access denied")
        case .authorized:
            print("Camera access authorized")
        @unknown default:
            break
        }
    }

    static func requestPhotoLibraryAccess() {
        PHPhotoLibrary.requestAuthorization { status in
            print("Photo library status: \(status.rawValue)")
        }
    }
}

رسائی سے انکار کو سنبھالنا

اگر صارف رسائی سے انکار کرتا ہے، تو ایپ کو سسٹم ڈائیلاگ دوبارہ نہیں بلانا چاہیے — یہ ممکن نہیں ہے۔ اس کے بجائے، ایک معلوماتی اسکرین دکھائیں جو بتائے کہ ترتیبات کے ذریعے رسائی کو کیسے فعال کیا جائے، “ترتیبات کھولیں” بٹن (UIApplicationOpenSettingsURLString) کے ساتھ۔ یہ عمل صارف کے تجربے اور صارف کے رسائی کو فعال کرنے کے امکان کو بہتر بناتا ہے۔

انکار کے فوراً بعد رسائی کو فعال کرنے کے لیے کہنے والا الرٹ نہ دکھائیں — صارف کو یہ سمجھنے کا وقت دیں کہ انہیں اس خصوصیت کی ضرورت کیوں ہو سکتی ہے۔ اس فعالیت کو استعمال کرنے کی کوشش کرتے وقت وضاحت دکھانا بہتر ہے جس کے لیے اس اجازت کی ضرورت ہے۔ UX Movement (2023) انکار کے 2-3 سیشن کے بعد وضاحت والی اسکرین دکھانے کی سفارش کرتا ہے۔

func showSettingsAlert(for feature: String) {
    let alert = UIAlertController(
        title: "رسائی \(feature)",
        message: "Allow access in Settings, "
            + "to use this feature",
        preferredStyle: .alert
    )
    alert.addAction(UIAlertAction(
        title: "Open Settings",
        style: .default
    ) { _ in
        if let url = URL(string: UIApplication.openSettingsURLString) {
            UIApplication.shared.open(url)
        }
    })
    alert.addAction(UIAlertAction(
        title: "Not now", style: .cancel
    ))
    UIApplication.shared.keyWindow?.rootViewController?.present(alert, animated: true)
}

اگر Usage Description متعین نہ کیا جائے تو کیا ہوتا ہے

لازمی Usage Description کلید کی عدم موجودگی متعلقہ API کی پہلی کال پر ایپ کو فوری طور پر کریش کر دیتی ہے۔ یہ Xcode کی وارننگ نہیں ہے، بلکہ NSInvalidArgumentException اور کنسول میں پیغام کے ساتھ ایک رن ٹائم کریش ہے: “یہ ایپ کریش ہو گئی کیونکہ اس نے استعمال کی تفصیل کے بغیر پرائیویسی کے لحاظ سے حساس ڈیٹا تک رسائی حاصل کرنے کی کوشش کی۔”

کلید کے بغیر رن ٹائم رویہ

iOS ایک محفوظ وسیلہ کے لیے پہلی API کال پر Info.plist میں NS*UsageDescription کلید کی موجودگی چیک کرتا ہے۔ اگر کلید غائب ہے، تو OS SIGABRT سگنل کے ساتھ ایپ کو فوری طور پر ختم کر دیتا ہے۔ یہ ڈیبگ ڈیوائس پر بھی ہوتا ہے — Xcode لاگ میں استثنا دکھاتا ہے، لیکن ڈیبگر اسے بریک پوائنٹ کے طور پر نہیں پکڑتا۔

کریش حقیقی آلات اور سمیولیٹر پر دوبارہ پیدا ہوتا ہے۔ اس سے بچنے کا واحد طریقہ API کال کرنے سے پہلے کلید شامل کرنا ہے۔ Xcode کا جامد تجزیہ کار ہمیشہ غائب کلید کے بارے میں خبردار نہیں کرتا، خاص طور پر اگر API تیسرے فریق کے SDK کے ذریعے کال کی جائے۔ TestFlight ٹیسٹر بھی کریش دیکھیں گے، جو منفی جائزوں کا باعث بن سکتا ہے۔

iOS 17+ کے ساتھ خاص صورتحال: Apple نے کلپ بورڈ تک رسائی (UIPasteboard) کے لیے اضافی جانچ متعارف کرائی۔ اگر ایپ صارف کے واضح عمل کے بغیر کلپ بورڈ پڑھتی ہے، تو iOS ایک وارننگ بینر دکھاتا ہے، چاہے Usage Description کلید موجود ہو۔ کلپ بورڈ کے لیے علیحدہ کلید کی ضرورت نہیں ہے، لیکن Apple خودکار پڑھنے کو کم سے کم کرنے کی سفارش کرتا ہے۔

App Store جائزہ میں غلطیاں

رن ٹائم کریش کے علاوہ، کلید کی عدم موجودگی جائزہ کے دوران ایپ مستردی کا سبب بن سکتی ہے۔ Apple جائزہ کے مرحلے میں Info.plist چیک کرتا ہے اور اگر متعلقہ کلیدوں کے بغیر API کالز کا پتہ چلتا ہے تو بلڈ کو مسترد کر سکتا ہے۔ Xcode آرکائیونگ کو بلاک نہیں کرتا، لیکن App Store Connect بائنری پر کارروائی کرتے وقت غلطی واپس کر سکتا ہے۔

اگر ایپ براہ راست وسیلہ استعمال نہیں کرتی لیکن تیسرے فریق کا SDK کرتا ہے (مثال کے طور پر، ایک تجزیاتی SDK IDFA کی درخواست کرتا ہے)، تو ڈویلپر کو پھر بھی متعلقہ کلید شامل کرنی ہوگی۔ Apple جامد اور متحرک لائبریریوں کے کوڈ سمیت بائنری میں تمام API کالز چیک کرتا ہے۔ “Info.plist کلید غائب” کی غلطی اپ ڈیٹ مستردی کی سب سے عام وجوہات میں سے ایک ہے۔