أذونات الوصول والخصوصية في تطوير التطبيقات المحمولة: ما هي، آلياتها وكيفية ضبطها

نماذج الأذونات على iOS وAndroid

نماذج الأذونات على iOS وAndroid تشترك في فكرة واحدة: يجب على المستخدم الموافقة على الوصول إلى البيانات الحساسة (الكاميرا، الميكروفون، الموقع الجغرافي، جهات الاتصال). لكن التنفيذ يختلف بشكل كبير. Android يطلب الأذونات في وقت الاستخدام (runtime)، بينما iOS يتطلب وصف الغرض في Info.plist ويطلب عند أول وصول. التنفيذ الصحيح لأذونات الوصول في التطبيق المحمول هو أساس الأمان والثقة.

قبل Android 6.0 (API 23)، كانت جميع الأذونات تُطلب أثناء التثبيت — إما أن يقبل المستخدم الكل أو لا يقوم بتثبيت التطبيق. مع Android 6.0 ظهرت Runtime Permissions: يطلب التطبيق الإذن في لحظة الحاجة الأولى، ويمكن للمستخدم الرفض. iOS يستخدم نهجاً مماثلاً منذ iOS 8.0. معرفة تطور أذونات الوصول في تطوير التطبيقات المحمولة يساعد في تصميم تجربة مستخدم مفهومة.

في 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. تتطلب طلب وقت التشغيل. Permission Group — مجموعة من الأذونات المرتبطة: إذا سمح المستخدم بـ CAMERA، إذن تسجيل الفيديو (RECORD_AUDIO؟ لا، هذه مجموعة منفصلة) — لا، CAMERA وRECORD_AUDIO في مجموعتين مختلفتين.

Runtime Permission — استدعاء ActivityCompat.requestPermissions() على Android أو الطلب عبر CLLocationManager.requestWhenInUseAuthorization() على iOS. يمكن للمستخدم الرد: Grant (منح)، Deny (رفض) أو «لا تسأل مجدداً» (على Android بعد رفضين). يتطلب ضبط أذونات الوصول في التطبيق المحمول مراعاة سلوك المستخدم.

Runtime Permission

Runtime Permission على Android يتطلب التحقق من الحالة الحالية قبل كل استخدام. الطريقة shouldShowRequestPermissionRationale() ترجع true إذا كان المستخدم قد رفض بالفعل — هذه إشارة لعرض حوار مع شرح. على iOS، المعادل هو التحقق من الحالة: .notDetermined، .denied، .authorized، .restricted. خصوصية التطبيق المحمول تتطلب مراقبة مستمرة لحالة الأذونات.

// Kotlin — طلب إذن الكاميرا في وقت التشغيل
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(). مهم: هل يجب طلب ATT قبل عرض موافقة GDPR؟ لا، ATT هو طلب منفصل من Apple. في الاتحاد الأوروبي، اعرض أولاً لافتة GDPR، ثم ATT. تتطلب أذونات الوصول في التطبيق المحمول على iOS تكوين ATT إلزامياً.

يُستخدم IDFA لإسناد الإعلانات والتخصيص. على Android، المعادل هو GAID (معرف الإعلانات من Google) أو AAID (معرف الإعلانات من Amazon). منذ Android 13+، يوجد إذن وقت تشغيل للوصول إلى GAID (com.google.android.gms.permission.AD_ID). تتطلب خصوصية التطبيق المحمول التحكم في المعرفات الإعلانية.

GDPR وموافقة المستخدم

GDPR (اللائحة العامة لحماية البيانات) — لائحة الاتحاد الأوروبي السارية منذ مايو 2018. تتطلب: موافقة صريحة على جمع البيانات الشخصية، الحق في إدارة أذونات الوصول، الحق في حذف البيانات (الحق في النسيان)، الإخطار بانتهاكات البيانات، وتعيين مسؤول حماية البيانات (DPO) للشركات الكبيرة. تحدد اللائحة أيضاً نموذجاً شفافاً لأذونات الوصول في التطبيقات المحمولة.

بالنسبة للتطبيقات المحمولة، يعني GDPR: عرض لافتة موافقة عند التشغيل الأول (مع وصف واضح للبيانات التي يتم جمعها ولأي أغراض)، إمكانية رفض الأذونات غير الأساسية، زر «حذف الحساب» في الإعدادات. الأدوات الشائعة لـ GDPR: OneTrust، منصة إدارة الموافقة (CMP) من Google، 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. خزّن حالة جميع الأذونات محلياً وقم بمزامنتها مع إعدادات النظام. تحقق بانتظام من الامتثال — فالتشريعات تتغير بسرعة. يتطلب نموذج أذونات الوصول وخصوصية التطبيق المحمول تدقيقاً مستمراً.