موبائل ڈویلپمنٹ میں رسائی کے اجازت نامے اور رازداری: یہ کیا ہے، کون سے میکانزم اور کیسے ترتیب دیں

iOS اور Android پر اجازت ناموں کے ماڈلز

اجازت ناموں کے ماڈلز iOS اور Android پر ایک مشترکہ خیال رکھتے ہیں: صارف کو حساس ڈیٹا (کیمرہ، مائیکروفون، مقام، رابطے) تک رسائی کے لیے رضامندی دینی ہوگی۔ تاہم، نفاذ نمایاں طور پر مختلف ہے۔ Android استعمال کے وقت (runtime) اجازتیں مانگتا ہے، iOS کو Info.plist میں مقصد کی وضاحت درکار ہے اور پہلی رسائی پر درخواست کرتا ہے۔ موبائل ایپلیکیشن میں رسائی کے اجازت ناموں کا صحیح نفاذ سلامتی اور اعتماد کی بنیاد ہے۔

Android 6.0 (API 23) سے پہلے، تمام اجازت نامے انسٹالیشن کے وقت مانگے جاتے تھے — صارف یا تو سب قبول کرتا تھا یا ایپلیکیشن انسٹال نہیں کرتا تھا۔ Android 6.0 کے ساتھ Runtime Permissions آئے: ایپلیکیشن پہلی ضرورت کے وقت اجازت مانگتی ہے، اور صارف انکار کر سکتا ہے۔ iOS iOS 8.0 سے اسی طریقہ کار کو استعمال کرتا ہے۔ موبائل ڈویلپمنٹ میں رسائی کے اجازت ناموں کے ارتقاء کو سمجھنا بدیہی UX ڈیزائن کرنے میں مدد کرتا ہے۔

IT Sectr میں ہم «کم سے کم اجازت ناموں» کے اصول پر عمل کرتے ہیں: ہم صرف وہی مانگتے ہیں جو واقعی ضروری ہے، اور صرف اس وقت جب ضرورت ہو۔ اس سے صارفین کا اعتماد بڑھتا ہے: Google (2025) کے مطابق، پہلی لانچ پر 5 سے زیادہ اجازت نامے مانگنے والی ایپس کی رجسٹریشن تبدیلی کی شرح 30% کم ہوتی ہے۔ موبائل ایپس میں رسائی کے اجازت ناموں کا یہ ماڈل ہمارے عمل سے تصدیق شدہ ہے۔

جدول 4. iOS اور Android کے اجازت ناموں کے ماڈلز کا موازنہ۔ بنیادی فرق: iOS کو Info.plist میں ہر اجازت کے استعمال کے مقصد کی واضح متنی وضاحت درکار ہے۔ Android shouldShowRequestPermissionRationale فراہم کرتا ہے تاکہ صارف کو سمجھایا جا سکے کہ اجازت کیوں ضروری ہے۔ پلیٹ فارمز کے درمیان رسائی کے حقوق میں فرق کو سمجھنا صحیح ماڈل منتخب کرنے میں مدد کرتا ہے۔

اجازت ناموں کی اقسام (Normal، Dangerous، Runtime)

Normal Permissions — ایسی اجازتیں جو صارف کی رازداری کے لیے خطرہ نہیں ہیں۔ یہ انسٹالیشن کے وقت خودبخود دی جاتی ہیں: INTERNET، ACCESS_NETWORK_STATE، VIBRATE، BLUETOOTH۔ ڈویلپر کو کوڈ میں ان کی درخواست کرنے کی ضرورت نہیں ہے۔ رسائی کے اجازت ناموں کی یہ درجہ بندی رازداری کے خطرے کی سطح سے مطابقت رکھتی ہے۔

Dangerous Permissions — ایسی اجازتیں جن کے لیے ذاتی ڈیٹا تک رسائی ضروری ہے: CAMERA، RECORD_AUDIO، ACCESS_FINE_LOCATION، READ_CONTACTS، READ_CALENDAR، READ_EXTERNAL_STORAGE۔ ان کے لیے runtime درخواست ضروری ہے۔ Permission Group — متعلقہ اجازت ناموں کا گروپ: اگر صارف نے CAMERA کی اجازت دی، تو ویڈیو ریکارڈ کرنے کی اجازت (RECORD_AUDIO؟ نہیں، یہ علیحدہ گروپ ہے) — نہیں، CAMERA اور RECORD_AUDIO مختلف گروپوں میں ہیں۔

Runtime Permission — Android پر ActivityCompat.requestPermissions() کو کال کرنا یا iOS پر CLLocationManager.requestWhenInUseAuthorization() کے ذریعے درخواست کرنا۔ صارف جواب دے سکتا ہے: Grant (اجازت دیں)، Deny (انکار کریں) یا «دوبارہ نہ پوچھیں» (Android پر دو انکار کے بعد)۔ موبائل ایپلیکیشن میں رسائی کے اجازت ناموں کو ترتیب دینے کے لیے صارف کے رویے کو مدنظر رکھنا ضروری ہے۔

Runtime Permission

Runtime Permission Android پر ہر استعمال سے پہلے موجودہ حالت کی جانچ ضروری ہے۔ shouldShowRequestPermissionRationale() طریقہ true لوٹاتا ہے اگر صارف نے پہلے ہی انکار کر دیا ہے — یہ وضاحت کے ساتھ ڈائیلاگ دکھانے کا اشارہ ہے۔ iOS پر، مساوی حالت کی جانچ ہے: .notDetermined، .denied، .authorized، .restricted۔ موبائل ایپ رازداری کے لیے اجازت کی حالت کی مسلسل نگرانی ضروری ہے۔

// Kotlin — کیمرے کے لیے runtime اجازت کی درخواست
class CameraActivity : AppCompatActivity() {

    companion object {
        private const val CAMERA_PERMISSION_CODE = 100
    }

    private fun requestCameraPermission() {
        when {
            ContextCompat.checkSelfPermission(
                this, Manifest.permission.CAMERA
            ) == PackageManager.PERMISSION_GRANTED -> {
                openCamera()
            }
            shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) -> {
                showRationaleDialog("QR کوڈز اسکین کرنے کے لیے کیمرہ تک رسائی ضروری ہے")
            }
            else -> {
                requestPermissions(
                    arrayOf(Manifest.permission.CAMERA),
                    CAMERA_PERMISSION_CODE
                )
            }
        }
    }

    override fun onRequestPermissionsResult(
        requestCode: Int,
        permissions: Array<String>,
        grantResults: IntArray
    ) {
        if (requestCode == CAMERA_PERMISSION_CODE &&
            grantResults.firstOrNull() == PackageManager.PERMISSION_GRANTED
        ) {
            openCamera()
        }
    }
}

یہ کوڈ صحیح نمونہ دکھاتا ہے: حالت چیک کریں → وضاحت دکھائیں (اگر ضروری ہو) → اجازت کی درخواست کریں → نتیجہ ہینڈل کریں۔ shouldShowRequestPermissionRationale ایک اہم طریقہ ہے: اگر صارف نے پہلے ہی انکار کر دیا ہے، تو وضاحت کے ساتھ ڈائیلاگ دکھائیں کہ اجازت کیوں ضروری ہے۔ اس کے بغیر، صارف مستقل طور پر رسائی سے انکار کر سکتا ہے۔

رازداری (ATT، Privacy Manifest، IDFA)

ATT (App Tracking Transparency) — ایک Apple فریم ورک (iOS 14.5+) جو ٹریکنگ کے لیے صارف کی واضح رضامندی کا تقاضا کرتا ہے۔ رضامندی کے بغیر، IDFA (مشہرین کے لیے شناخت کار) صفر لوٹاتا ہے۔ Flurry (2025) کے مطابق، ATT قبولیت کی شرح علاقے اور ایپ کی قسم کے لحاظ سے 15–25% ہے۔ موبائل ایپلیکیشن میں رسائی کے اجازت ناموں کا انتظام صحیح فریم ورک کے انتخاب سے شروع ہوتا ہے۔

Privacy Manifest — ایک لازمی فائل (2024 سے نئی ایپس کے لیے، 2025 سے اپڈیٹس کے لیے) جس میں ڈویلپر اعلان کرتا ہے کہ ایپلیکیشن ڈیٹا کی کون سی اقسام اور کن مقاصد کے لیے جمع کرتی ہے۔ Apple جائزے کے دوران Privacy Manifest کی ایپلیکیشن کے حقیقی رویے سے مطابقت کو چیک کرتا ہے۔ موبائل ایپلیکیشن میں رازداری کو دستاویزی شکل دینا ضروری ہے۔

App Tracking Transparency (ATT)

ATT میں Info.plist کلید NSUserTrackingUsageDescription کو ٹریکنگ کی ضرورت کی وضاحت کے ساتھ شامل کرنا اور ATTrackingManager.requestTrackingAuthorization() کو کال کرنا ضروری ہے۔ اہم: کیا GDPR رضامندی دکھانے سے پہلے ATT کی درخواست کرنی چاہیے؟ نہیں، ATT ایک علیحدہ Apple درخواست ہے۔ EU میں، پہلے GDPR بینر دکھائیں، پھر ATT۔ iOS پر موبائل ایپلیکیشن میں رسائی کے اجازت ناموں کے لیے لازمی ATT ترتیب ضروری ہے۔

IDFA اشتہاری انتساب اور ذاتی بنانے کے لیے استعمال ہوتا ہے۔ Android پر، مساوی GAID (Google Advertising ID) یا AAID (Amazon Advertising ID) ہے۔ Android 13+ سے، GAID تک رسائی کے لیے runtime اجازت (com.google.android.gms.permission.AD_ID) موجود ہے۔ موبائل ایپ رازداری کے لیے اشتہاری شناخت کاروں پر کنٹرول ضروری ہے۔

GDPR اور صارف کی رضامندی

GDPR (جنرل ڈیٹا پروٹیکشن ریگولیشن) — مئی 2018 سے نافذ EU ضابطہ۔ تقاضے: ذاتی ڈیٹا جمع کرنے کے لیے واضح رضامندی، رسائی کے اجازت ناموں کے انتظام کا حق، ڈیٹا حذف کرنے کا حق (بھول جانے کا حق)، ڈیٹا کی خلاف ورزی کی اطلاعات، اور بڑی کمپنیوں کے لیے DPO (ڈیٹا پروٹیکشن آفیسر) کی تقرری۔ یہ ضابطہ موبائل ایپس میں شفاف رسائی کے اجازت ناموں کا ماڈل بھی متعین کرتا ہے۔

موبائل ایپس کے لیے، GDPR کا مطلب ہے: پہلی لانچ پر رضامندی کا بینر دکھانا (اس بات کی واضح وضاحت کے ساتھ کہ کون سا ڈیٹا کن مقاصد کے لیے جمع کیا جاتا ہے)، غیر ضروری اجازت ناموں سے انکار کرنے کی صلاحیت، اور سیٹنگز میں «اکاؤنٹ حذف کریں» بٹن۔ مشہور GDPR ٹولز: OneTrust، Google کا رضامندی کے انتظام کا پلیٹ فارم (CMP)، Usercentrics۔ موبائل ایپلیکیشن میں رازداری کو یقینی بنانے کے لیے CMP انضمام ضروری ہے۔

IT Sectr میں ہم آن بورڈنگ کے مرحلے پر GDPR رضامندی نافذ کرتے ہیں: صارف واضح وضاحت دیکھتا ہے، انتخاب کرتا ہے کہ کون سا ڈیٹا جمع کرنے کی اجازت دینی ہے، اور سیٹنگز میں اپنا انتخاب تبدیل کر سکتا ہے۔ یہ نہ صرف قانونی ضرورت ہے بلکہ اعتماد کا عنصر بھی ہے: شفاف ایپس کی برقراری شرح 20% زیادہ ہے (IT Sectr ڈیٹا، 2024)۔ موبائل ایپ رازداری اور رسائی کے اجازت ناموں کا انتظام صارفین کو برقرار رکھنے کے کلیدی عوامل ہیں۔

GDPR اور صارف کی رضامندی

رضامندی ہونی چاہیے: رضاکارانہ (نہیں کا مطلب نہیں)، مخصوص («سب کچھ» کے لیے رضامندی جمع نہیں کی جا سکتی)، باخبر (صارف جانتا ہے کہ وہ کس چیز کے لیے رضامندی دے رہا ہے) اور غیر مبہم (فعال اقدام ضروری — چیک باکس، بٹن)۔ پہلے سے نشان زد چیک باکسز GDPR کے ذریعہ ممنوع ہیں۔ خلاف ورزی پر جرمانے — عالمی کاروبار کا 4% یا 20 ملین یورو تک۔ موبائل ایپلیکیشن میں رسائی کے اجازت ناموں کی صحیح ترتیب جرمانے سے بچنے میں مدد دیتی ہے۔

عملی تجاویز

IT Sectr کے تجربے کی بنیاد پر — اجازت ناموں اور رازداری کے ساتھ کام کرنے کے لیے کئی عملی سفارشات۔ سیاق و سباق میں اجازت نامے طلب کریں: سسٹم ڈائیلاگ سے پہلے ایک اسکرین دکھائیں جو بتاتی ہے کہ اجازت کیوں ضروری ہے۔ مثال کے طور پر، کیمرہ مانگنے سے پہلے دکھائیں: «QR کوڈز اسکین کرنے کے لیے ہمیں کیمرہ تک رسائی درکار ہے» — اس سے رضامندی کے امکانات 40% بڑھ جاتے ہیں۔ موبائل ایپس میں رسائی کے اجازت نامے استعمال کے سیاق و سباق میں مانگے جانے چاہئیں۔

پہلی لانچ پر تمام اجازت نامے نہ مانگیں۔ سیاقی اجازت کی درخواست (استعمال کے وقت درخواست) آن بورڈنگ کے دوران درخواست کے مقابلے میں 60% زیادہ تبدیلی دیتی ہے۔ انکار کو خوبصورتی سے ہینڈل کریں: اگر صارف انکار کرتا ہے، تو فعالیت کو مسدود نہ کریں، بلکہ متبادل پیش کریں (مثلاً، مقام کے بجائے دستی پتہ اندراج)۔ موبائل ایپ رازداری اس طریقہ کار سے فائدہ اٹھاتی ہے۔

iOS کے لیے، یقینی بنائیں کہ Privacy Manifest شامل کریں (2025 سے تمام ایپس کے لیے لازمی)۔ Android کے لیے، Google Play Console میں ڈیٹا سیفٹی سیکشن بتائیں۔ تمام اجازت ناموں کی کیفیت مقامی طور پر ذخیرہ کریں اور سسٹم سیٹنگز کے ساتھ ہم آہنگ کریں۔ باقاعدگی سے تعمیل کی جانچ کریں — قانون تیزی سے بدلتا ہے۔ موبائل ایپ کے رسائی کے اجازت ناموں کا ماڈل اور رازداری مسلسل آڈٹ کا تقاضا کرتی ہے۔