Universal Link — ما هو، مبدأ العمل والإعداد

ما هو Universal Link

Universal Link هو رابط HTTPS قياسي مثل https://example.com/page، والذي عند النقر عليه من جهاز iOS يفتح التطبيق المثبت بدلاً من Safari. الفرق الرئيسي عن Custom URL Scheme: لا يتطلب Universal Link تسجيل مخطط مخصص (myapp://) — بل يستخدم نطاقاً عادياً. هذا يلغي مشكلة اختطاف مخطط URL (URL Scheme hijacking)، حيث يمكن لأي تطبيق تسجيل نفس المخطط.

قدمت Apple Universal Link في WWDC 2015 كجزء من iOS 9. أصبحت الآلية جزءاً من نظام Handoff وSpotlight البيئي: يعمل Universal Link ليس فقط في المتصفح، ولكن أيضاً في نتائج بحث Spotlight، وMail، وMessages، وتطبيقات النظام الأخرى. بالإضافة إلى ذلك، يتم دعم Universal Link في watchOS وmacOS — يمكن للمستخدم فتح تطبيق على iPhone عبر رابط على Mac.

الميزة الرئيسية: URL موحد. لا يدير المطور رابطين مختلفين (واحد للويب وآخر للتطبيق). Universal Link هو رابط https واحد. إذا كان التطبيق مثبتاً — يُفتح التطبيق. إذا لم يكن — يُفتح نفس الرابط في Safari كصفحة ويب عادية. هذا يوفر fallback مثالياً دون فقدان الزيارات.

كيف يعمل Universal Link

تتكون آلية Universal Link من ثلاث مراحل: التحقق من الارتباط، معالجة الرابط، وfallback إلى المتصفح. كل مرحلة حاسمة للتشغيل الصحيح. إذا لم يتم تكوين الارتباط، يعالج iOS الرابط كإعادة توجيه عادية إلى Safari. دعنا نفحص كل مرحلة بالتفصيل.

التحقق من الارتباط (Association Verification)

عند النقر الأول على رابط، يقوم iOS بتحميل ملف apple-app-site-association من الخادم على https://example.com/.well-known/apple-app-site-association. يحتوي الملف على JSON يحتوي على Team ID وBundle ID للتطبيق، بالإضافة إلى قائمة المسارات التي يجب أن يفتحها التطبيق. يخزن iOS هذا الملف مؤقتاً ويتحقق دورياً من حداثته (عند تحديث التطبيق، إعادة تشغيل الجهاز).

يجب أن يكون ملف JSON apple-app-site-association متاحاً عبر HTTPS دون إعادة توجيه. يجب أن يعيد الخادم Content-Type: application/json. من المهم أن الملف ليس له امتداد .json — يبحث عنه iOS بدقة في /.well-known/apple-app-site-association. توصي Apple أيضاً بإضافة دعم Universal Link في CDN والتحقق من أن الملف غير محظور بواسطة robots.txt.

// apple-app-site-association — الحد الأدنى من التكوين
{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "TEAMID.com.example.app",
                "paths": ["/product/*", "/profile/*", "/search"]
            }
        ]
    }
}

يتم تشكيل appID كـ Team ID + Bundle ID (TEAMID.com.example.app). paths هي مصفوفة من أنماط URL التي يجب أن يعالجها التطبيق. يمكن استخدام * و? وترميز NOT: ["NOT /admin/*", "/product/*"]. يتم التحقق من المسارات بترتيب التعداد: أول تطابق يحدد السلوك. إذا لم يتطابق المسار — يُفتح الرابط في Safari.

معالجة الرابط (Link Handling)

بعد التحقق الناجح من الارتباط، يقوم iOS بتمرير الرابط إلى التطبيق. تتم المعالجة في AppDelegate عبر طريقة application(_:continue:restorationHandler:) لـ NSUserActivity، أو في SceneDelegate عبر scene(_:continue:). يتلقى المطور كائن NSUserActivity بنوع NSUserActivityTypeBrowsingWeb، ويستخرج URL، وينتقل إلى الشاشة المقابلة.

// معالجة Universal Link في AppDelegate
func application(
    _ application: UIApplication,
    continue userActivity: NSUserActivity,
    restorationHandler: @escaping UIUserActivityRestorationHandler
) -> Bool {
    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
          let url = userActivity.webpageURL
    else { return false }

    // التنقل إلى الشاشة وفقاً لعنوان URL
    DeepLinkRouter.navigate(to: url)
    return true
}

DeepLinkRouter في المثال أعلاه هو فئة مخصصة تحلل URL وتستدعي منسق التنقل المقابل. بالنسبة لـ SwiftUI، تتم المعالجة عبر طريقة onOpenURL أو معدّل environment(\.openURL). من المهم معالجة ليس فقط بدء التشغيل في المقدمة، ولكن أيضاً الحالة التي لم يكن فيها التطبيق قيد التشغيل (cold start): في هذه الحالة، يفتح Universal Link التطبيق عبر خيارات الإطلاق.

Fallback إلى المتصفح (Browser Fallback)

إذا لم يكن التطبيق مثبتاً، يقوم iOS تلقائياً بفتح Universal Link في Safari. هذا فرق رئيسي عن Custom URL Scheme: لا يرى المستخدم خطأ. Fallback هو صفحة الويب القياسية لنفس النطاق. يمكن للمطور وضع رابط لمتجر App Store أو معلومات المنتج أو محتوى بديل في هذه الصفحة.

هام: لا يمكن تخصيص fallback على مستوى iOS. يقوم iOS ببساطة بفتح URL في Safari. لعرض محتوى مختلف للمستخدمين الذين لديهم التطبيق مثبتاً والذين ليس لديهم، استخدم Smart App Banner (وسم meta لـ Safari يعرض فتح التطبيق) أو اكتشاف التثبيت بـ JavaScript. توفر Apple أيضاً SKAdNetwork لإحالة التثبيتات عبر Universal Link.

Universal Link مقابل Deep Link

يحل Universal Link وDeep Link التقليدي (Custom URL Scheme) نفس المشكلة، لكنهما يختلفان جوهرياً في البنية والأمان. Custom URL Scheme هو بروتوكول مخصص (myapp://) يُسجل في Info.plist. يمكن لأي تطبيق تسجيل نفس المخطط (myapp://)، ولا يمكن لـ iOS تحديد أيهما ‘الحقيقي’.这叫 اختطاف مخطط URL.

يحل Universal Link مشكلة الاختطاف من خلال التحقق من النطاق. فقط مالك النطاق يمكنه وضع apple-app-site-association على خادمه، مؤكداً الاتصال بـ Bundle ID محدد. لا يمكن لتطبيقين تسجيل نفس Universal Link: إذا نشأ تعارض، يعطي iOS الأولوية لآخر تطبيق تم تثبيته أو يفتح Safari.

فرق آخر: Fallback. Custom URL Scheme ليس لديه fallback — إذا لم يكن التطبيق مثبتاً، يعرض المتصفح خطأ. Universal Link يفتح الموقع. URL موحد يعني أن قيمة SEO للرابط محفوظة (يقوم Google بفهرسة الرابط)، ويحصل المستخدم على أي جهاز على محتوى ذي صلة. Universal Link هو خطوة تطورية من deep link إلى الرابط الموحد.

إعداد Universal Link

إعداد Universal Link يشمل جزئين: الخادم والعميل. الخادم — وضع ملف apple-app-site-association على https://domain/.well-known/apple-app-site-association. العميل — تسجيل النطاق في Associated Domains في Xcode (Capabilities → Associated Domains → applinks:example.com). بعد ذلك، يستقبل التطبيق تلقائياً جميع Universal Links للنطاق المحدد.

خطوات الإعداد:

1. إنشاء apple-app-site-association مع appID صحيح (TeamID.BundleID) و paths
2. وضع الملف على الخادم في /.well-known/ دون امتداد .json
3. التحقق من التوفر: curl https://domain/.well-known/apple-app-site-association
4. إضافة النطاق في Associated Domains (Xcode Capabilities)
5. تنفيذ المعالجة عبر NSUserActivity (AppDelegate أو SceneDelegate)
6. اختبار على جهاز حقيقي (المحاكي لا يتحقق من الارتباط)

تصحيح الأخطاء في Universal Link هو صداع شائع لمطوري iOS. الأسباب الرئيسية للروابط غير العاملة: ملف apple-app-site-association غير متاح عبر HTTPS، appID غير صحيح، Content-Type ليس application/json، إعادة توجيه من مسار /.well-known، تخزين مؤقت للإصدار القديم من الملف (إعادة التعيين عبر Settings → Developer → Associated Domains Development). توفر Apple أداة Validation Checker في Apple Developer Console لاختبار الارتباط.

Branch ومنصات MMP الأخرى تبسط إعداد Universal Link: تقوم بإنشاء apple-app-site-association تلقائياً واستضافته على نطاقها الخاص. يحتاج المطور فقط إلى إضافة نطاق Branch إلى Associated Domains ودمج SDK. هذا مناسب بشكل خاص للشركات الناشئة التي ليس لديها بنيتها التحتية الخادمة الخاصة لاستضافة ملف AASA.

القيود والتوافق

Universal Link له عدة قيود. أولاً: يجب أن يكون ملف apple-app-site-association متاحاً بدقة عبر HTTPS (HTTP غير مدعوم). ثانياً: يجب أن يشير الرابط إلى نفس النطاق المحدد في Associated Domains. Universal Links عبر النطاقات لا تعمل — كل نطاق يتطلب إدخالاً منفصلاً في Capabilities وملف AASA منفصل. ثالثاً: لا يعمل Universal Link في WKWebView — فقط في Safari والمكونات النظامية.

التوافق: iOS 9.0+ (Universal Link)، watchOS 6.0+ (Handoff Universal Link)، macOS 10.15+ (Catalyst وتطبيقات Mac). في إصدارات iOS الأقدم، يُفتح الرابط في Safari. هذا يعني أنه على iOS 8 (أقل من 1% من الأجهزة) لن يعمل Universal Link. يُوصى بدعم Custom URL Scheme كـ fallback للأجهزة القديمة إذا كان جمهورك يشمل مستخدمين بإصدارات قديمة.

تغييرات iOS 16+: حسنت Apple معالجة Universal Link لـ SwiftUI. تم تقديم معدّل جديد environment(\.openURL) مع إمكانية المعالجة المؤجلة. يسمح iOS 16 أيضاً بفتح Universal Links في التطبيق حتى عبر SFSafariViewController. لمستخدمي iOS 16، يُوصى بالانتقال الكامل إلى معالجة Universal Link بـ SwiftUI، مع ترك كود AppDelegate فقط للتوافق مع الإصدارات السابقة.