iOS यूनिवर्सल लिंक्स बंडल आईडी और AASA ऐप आईडी बेमेल (Mismatch) को कैसे ठीक करें

बंडल आईडी बेमेल (Mismatch) iOS यूनिवर्सल लिंक्स को क्यों बाधित करता है? जब एप्लिकेशन का हस्ताक्षरित (signed) एप्लिकेशन आइडेंटिफ़ायर, संबंधित डोमेन के लिए संगत AASA appID/appIDs प्रविष्टि से मेल नहीं खाता है, तो बंडल आईडी बेमेल यूनिवर्सल लिंक्स को बाधित करता है, जिसके कारण संबंधित-डोमेन सत्यापन (associated-domain verification) विफल हो जाता है।

बंडल आईडी (CFBundleIdentifier) ​​एक अनूठी स्ट्रिंग है जो Apple पारिस्थितिकी तंत्र के भीतर एक व्यक्तिगत iOS एप्लिकेशन की पहचान करती है। यूनिवर्सल लिंक आर्किटेक्चर में, बंडल आईडी को एप्लिकेशन आइडेंटिफ़ायर प्रीफ़िक्स के साथ जोड़ा जाता है ताकि एप्लिकेशन आइडेंटिफ़ायर बनाया जा सके, जिसे ऑपरेटिंग सिस्टम होस्ट किए गए apple-app-site-association फ़ाइल के मुकाबले सत्यापित करता है ताकि मूल URL हैंडलिंग अधिकृत हो सके।

कैनोनिकल डायग्नोस्टिक चेन

नीचे दिया गया आरेख ऐप इंस्टॉलेशन और डोमेन सत्यापन के दौरान निष्पादित बहु-स्तरीय सत्यापन अनुक्रम को दर्शाता है:

Layer 1: Signed App Binary
       │
       ├── application-identifier (<Prefix>.<BundleID>)
       ├── com.apple.developer.team-identifier
       └── com.apple.developer.associated-domains (applinks:example.com)
                    │
                    ▼
Layer 2: AASA Delivery & CDN Ingestion
       │ (Apple-managed infrastructure retrieves origin AASA)
                    ▼
Layer 3: AASA Schema & Pattern Matching
       │ (Validates appIDs array and components/paths routing rules)
                    ▼
Layer 4: Device Association State
       │ (Operating system registers verified domains in local database)
                    ▼
Layer 5: Application Routing Execution
       │ (System routes matching URLs to application lifecycle handlers)

त्वरित समाधान चेकलिस्ट: 30-सेकंड डायग्नोस्टिक रूटीन

जब यूनिवर्सल लिंक्स अप्रत्याशित रूप से वेब हैंडलिंग पर वापस आ जाते हैं, तो इन मदों को क्रम से सत्यापित करें:

• हस्ताक्षरित आइडेंटिफ़ायर निकालें: सटीक application-identifier (<Prefix>.<BundleID>) प्राप्त करने के लिए संकलित बाइनरी के एंबेडेड एंटाइटेलमेंट का निरीक्षण करें।
• एंटाइटेलमेंट प्रारूप सत्यापित करें: पुष्टि करें कि com.apple.developer.associated-domains में आवश्यक पथों, क्वेरी स्ट्रिंग्स या ट्रेलिंग स्लैश के बिना सटीक होस्टनेम (जैसे, applinks:subdomain.domain.com) शामिल है।
• मूल AASA का ऑडिट करें: https://subdomain.domain.com/.well-known/apple-app-site-association फ़ैच करें और सुनिश्चित करें कि हस्ताक्षरित एप्लिकेशन आइडेंटिफ़ायर appIDs में शब्दशः सूचीबद्ध है।
• पथ मिलान (Path Matching) सत्यापित करें: पुष्टि करें कि लक्षित URL AASA कॉन्फ़िगरेशन में परिभाषित components या paths पैटर्न से मेल खाता है।
• डोमेन स्कूपिंग की जाँच करें: सुनिश्चित करें कि संबंधित-डोमेन एंटाइटेलमेंट लक्षित होस्टनेम को कवर करता है और संबंधित AASA कॉन्फ़िगरेशन उस होस्टनेम के लिए उपलब्ध है। उपडोमेन के लिए, उचित रूप से स्पष्ट होस्टनेम या समर्थित *. वाइल्डकार्ड फॉर्म का उपयोग करें।
• विकास मोड (Development Modes) को अलग करें: पुनरावृत्ति (iteration) के दौरान Apple CDN कैशे को बायपास करने के लिए डेवलपमेंट-साइंड बिल्ड पर ?mode=developer का उपयोग करें।

बंडल आईडी और एप्लिकेशन आइडेंटिफ़ायर सटीकता क्यों मायने रखती है

एक एप्लिकेशन आइडेंटिफ़ायर की संरचना

यूनिवर्सल लिंक सत्यापन एप्लिकेशन के प्रदर्शन नाम, आंतरिक URL योजना या बंडल नाम का मूल्यांकन नहीं करता है। applinks.Details पर Apple दस्तावेज़ीकरण के अनुसार, सुरक्षा मॉडल पूरी तरह से योग्य एप्लिकेशन आइडेंटिफ़ायर पर निर्भर करता है, जिसकी संरचना इस प्रकार है:

जहाँ:

• ApplicationIdentifierPrefix: आपके Apple डेवलपर खाता कॉन्फ़िगरेशन में निर्दिष्ट ऐप आईडी प्रीफ़िक्स (जैसे, 9JA723G82S)। कई आधुनिक डेवलपर खातों के लिए, यह मान 10-अक्षर की टीम आईडी से मेल खाता है, लेकिन इंजीनियरों को यह मान लेने के बजाय कि दोनों परस्पर परिवर्तनीय हैं, अपने Apple डेवलपर पोर्टल में वास्तविक प्रीफ़िक्स को सत्यापित करना चाहिए।
• CFBundleIdentifier (बंडल आईडी): लक्ष्य की बिल्ड सेटिंग्स में परिभाषित केस-संवेदनशील, रिवर्स-DNS स्ट्रिंग (जैसे, com.example.mobileapp)।

होस्ट की गई apple-app-site-association (AASA) JSON फ़ाइल में, यह संयुक्त स्ट्रिंग appIDs सरणी या appID शब्दकोश प्रविष्टियों के भीतर दिखाई देती है (जैसे, 9JA723G82S.com.example.mobileapp)। यदि संकलित बाइनरी के एंबेडेड एंटाइटेलमेंट और होस्ट की गई AASA प्रविष्टि के बीच कोई वर्ण विसंगति, केसिंग अंतर या ट्रेलिंग स्पेस मौजूद है, तो डोमेन सत्यापन विफल हो जाता है।

एकीकरण ट्राइएज के दौरान बंडल आईडी बेमेल सबसे उच्च-प्राथमिकता वाले कारणों में से एक है जिसकी जांच करनी चाहिए, लेकिन यह एकमात्र कारण नहीं है कि यूनिवर्सल लिंक वेब पर वापस आ सकता है।

संबंधित डोमेन और AASA दो-तरफ़ा संबंध कैसे स्थापित करते हैं

कस्टम URL योजनाओं के विपरीत, जिन्हें कोई भी स्थापित एप्लिकेशन डोमेन सत्यापन के बिना घोषित कर सकता है, यूनिवर्सल लिंक्स एक सुरक्षित, दो-तरफ़ा संबंध स्थापित करते हैं:

• ऐप-से-डोमेन घोषणा: संकलित iOS एप्लिकेशन अपने कोड हस्ताक्षर में com.apple.developer.associated-domains एंटाइटेलमेंट को शामिल करके यह घोषणा करता है कि वह किसी विशिष्ट वेब डोमेन के स्वामित्व का दावा करता है।
• डोमेन-से-ऐप प्राधिकरण: वेब डोमेन पुष्टि करता है कि यह https://<domain>/.well-known/apple-app-site-association या https://<domain>/apple-app-site-association पर AASA JSON फ़ाइल को होस्ट करके विशिष्ट अनुप्रयोगों को रूटिंग प्राधिकरण प्रदान करता है।

इंस्टॉलेशन या ऐप अपडेट के दौरान, ऑपरेटिंग सिस्टम डोमेन के लिए पुनर्प्राप्त AASA कॉन्फ़िगरेशन के मुकाबले ऐप के हस्ताक्षरित एसोसिएटेड डोमेन एंटाइटेलमेंट को सत्यापित करता है। ऐप एसोसिएशन के लिए उपयोग किया जाने वाला एप्लिकेशन आइडेंटिफ़ायर AASA कॉन्फ़िगरेशन में घोषित संबंधित आइडेंटिफ़ायर से मेल खाना चाहिए। आइडेंटिफ़ायर के मेल खाने के बाद, अनुरोधित URL को भी कॉन्फ़िगर किए गए components या paths नियमों को पूरा करना होगा.

विफलता का लक्षण: बेमेल आइडेंटिफ़ायर वेब फॉलबैक क्यों मजबूर करते हैं

जब एप्लिकेशन आइडेंटिफ़ायर बेमेल होता है, तो iOS आम तौर पर एप्लिकेशन आइडेंटिफ़ायर बेमेल को घातक रनटाइम अपवाद के रूप में सामने नहीं लाता है। इसके बजाय विफलता संबंधित-डोमेन सत्यापन स्थिति, डिवाइस डायग्नोस्टिक्स या परिणामी वेब फॉलबैक व्यवहार में दिखाई देती है:

• सिस्टम हैंडलिंग: जब डोमेन एसोसिएशन विफल हो जाता है, तो सिस्टम सत्यापित यूनिवर्सल लिंक पथ के माध्यम से ऐप को कॉल नहीं करता है। URL कैसे खोला गया था और आसपास के ब्राउज़र संदर्भ के आधार पर, URL मूल एप्लिकेशन को डिलीवर होने के बजाय वेब हैंडलिंग में रहता है या उस पर वापस आ जाता है।
• उपयोगकर्ता अनुभव प्रभाव: जब कोई उपयोगकर्ता संदेश, मेल या सफारी में किसी मिलान करने वाले वेब लिंक पर टैप करता है, तो सिस्टम अधिकृत मूल ऐप मैपिंग को पहचानने में विफल रहता है और ब्राउज़र में वेब URL खोलता है।

यह भी देखें: बंडल आईडी ──> यूनिवर्सल लिंक्स आर्किटेक्चर

Apple का CDN AASA फ़ाइलों को कैसे फ़ैच और कैश करता है

इंस्टॉलेशन हैंडशेक और Apple CDN मैकेनिक्स

जब com.apple.developer.associated-domains एंटाइटेलमेंट वाला कोई एप्लिकेशन इंस्टॉल या अपडेट किया जाता है, तो सिस्टम एक संबंधित-डोमेन संबंध स्थापित या ताज़ा करता है:

• CDN-मध्यस्थ स्क्रैपर: जब सिस्टम एक संबंधित-डोमेन संबंध स्थापित या ताज़ा करता है, तो यह Apple के संबंधित-डोमेन बुनियादी ढाँचे के माध्यम से डोमेन का AASA डेटा प्राप्त करता है और एसोसिएशन को सत्यापित करने के लिए उस डेटा का उपयोग करता है।
• स्वतंत्र कैशिंग जीवनचक्र: Apple-प्रबंधित CDN अपने स्वयं के रीफ्रेश और कैशिंग जीवनचक्र को नियंत्रित करता है, इसलिए यह नहीं माना जाना चाहिए कि मूल अपडेट तुरंत CDN के माध्यम से दिखाई देने लगेगा। परिवर्तनों का परीक्षण करते समय, जहाँ उचित हो, प्रलेखित विकास वैकल्पिक मोड का उपयोग करें और डिवाइस एसोसिएशन स्थिति का निरीक्षण करें।
• मूल सर्वर आवश्यकताएँ: मूल वेब सर्वर को application/json MIME प्रकार का उपयोग करते हुए, एक वैध, विश्वसनीय TLS प्रमाणपत्र (स्व-हस्ताक्षरित प्रमाणपत्र अस्वीकार कर दिए जाते हैं) के साथ HTTPS पर AASA फ़ाइल प्रदान करनी चाहिए। AASA होस्टिंग को HTTP पुनर्निर्देशन (redirects) पर निर्भर नहीं होना चाहिए; AASA समापन बिंदु को HTTP 200 OK के साथ सीधे फ़ाइल वापस करनी चाहिए।

AASA JSON प्रारूप स्थिरता

आधुनिक iOS संस्करण लीगेसी paths सरणियों के साथ पिछड़े संगतता (backward compatibility) बनाए रखते हुए दानेदार (granular) components शब्दकोश सिंटैक्स का समर्थन करते हैं।

यूनिवर्सल लिंक्स डिबगिंग पर Apple डेवलपर तकनीकी नोट TN3155 के अनुसार, किसी दिए गए details प्रविष्टि के भीतर, डेवलपर्स को या तो आधुनिक appIDs + components संरचना या लीगेसी appID + paths संरचना का उपयोग करना चाहिए; एक ही प्रविष्टि में दोनों संरचनाओं को न मिलाएं, क्योंकि मिश्रित कॉन्फ़िगरेशन अप्रत्याशित सत्यापन व्यवहार उत्पन्न कर सकते हैं।

पुराने AASA उदाहरणों में आमतौर पर "apps": [] शामिल होता था। आधुनिक Apple OS रिलीज़ को लक्षित करने वाले तैनाती के लिए, इस कुंजी की आवश्यकता नहीं है; इसे केवल तभी बनाए रखें जब ऐसे पुराने OS संस्करणों का समर्थन कर रहे हों जो विशेष रूप से इसकी अपेक्षा करते हैं।

डायग्नोस्टिक प्रोटोकॉल: चरण-दर-चरण समाधान वर्कफ़्लो

चरण 1: codesign के साथ हस्ताक्षरित ऐप एंटाइटेलमेंट का निरीक्षण करें

यह निर्धारित करने के लिए कि किसी निर्यात किए गए IPA या डिबग बिल्ड में सटीक अपेक्षित एप्लिकेशन आइडेंटिफ़ायर और संबंधित डोमेन हैं या नहीं, macOS codesign कमांड-लाइन यूटिलिटी का उपयोग करके सीधे बाइनरी के कोड हस्ताक्षर का निरीक्षण करें। application-identifier, com.apple.developer.team-identifier, और com.apple.developer.associated-domains को एक साथ जाँचें।

प्रावधान प्रोफ़ाइल (provisioning profile) दिखाती है कि प्रोफ़ाइल कौन सी क्षमताओं और डोमेन की अनुमति देती है; हस्ताक्षरित निष्पादन योग्य (codesign) दिखाता है कि भेजे गए बाइनरी में वास्तव में क्या है।

चरण 2: होस्ट किए गए AASA JSON स्कीमा का ऑडिट करें

सत्यापित करें कि मूल सर्वर एक वैध AASA फ़ाइल होस्ट करता है जो प्रमाणीकरण या पुनर्निर्देशन के बिना सार्वजनिक रूप से सुलभ है। ध्यान दें कि पुराने AASA उदाहरणों में आमतौर पर "apps": [] शामिल होता था, जबकि समकालीन iOS रिलीज़ को लक्षित करने वाले आधुनिक कॉन्फ़िगरेशन इस कुंजी को छोड़ देते हैं।

नीचे दिया गया मानक AASA JSON स्कीमा आधुनिक appIDs और components संरचना का उपयोग करके उचित पथ रूटिंग को दर्शाता है:

```json
{
  "applinks": {
    "details": [
      {
        "appIDs": [
          "9JA723G82S.com.example.mobileapp",
          "9JA723G82S.com.example.mobileapp.staging"
        ],
        "components": [
          {
            "/": "/product/*",
            "comment": "Matches product detail routes"
          },
          {
            "/": "/invite/*",
            "?": { "ref": "?*" },
            "comment": "Matches referral links with custom query parameters"
          },
          {
            "/": "/help/*",
            "exclude": true,
            "comment": "Excludes customer support URLs from native routing"
          }
        ]
      }
    ]
  }
}

चरण 3: डायग्नोस्टिक CLI टूल चलाएँ (codesign, swcutil, curl)

macOS संस्करणों पर जो swcutil डायग्नोस्टिक्स प्रदान करते हैं, संबंधित-डोमेन डेटा का निरीक्षण या सत्यापन करने के लिए टूल का उपयोग करें। चूँकि कमांड विकल्प OS और टूलचेन रिलीज़ में भिन्न हो सकते हैं, नीचे दिए गए डायग्नोस्टिक वर्कफ़्लो को चलाने से पहले swcutil --help के साथ उपलब्ध विकल्पों की पुष्टि करें:

# 0. Confirm available options (syntax may vary by OS and toolchain release)
swcutil --help

# 1. Unpack the exported IPA archive
unzip -q YourApp.ipa -d UnpackedApp

# 2. Extract and inspect signed entitlements directly from the executable binary
codesign -d --entitlements :- "UnpackedApp/Payload/YourApp.app" > signed-entitlements.plist 2>/dev/null
/usr/libexec/PlistBuddy -c "Print" signed-entitlements.plist

# 3. Check whether the AASA data can be downloaded for the domain using swcutil (macOS diagnostic tool)
sudo swcutil dl -d custom.opwakeup.com

# 4. Validate AASA pattern matching against a specific URL using swcutil
sudo swcutil verify -d custom.opwakeup.com -j ./apple-app-site-association -u https://custom.opwakeup.com/product/123

# 5. Query the Apple-managed Associated Domains CDN diagnostic endpoint directly
curl -i https://app-site-association.cdn-apple.com/a/v1/custom.opwakeup.com

एज-डिलीवर किए गए AASA डेटा का समस्या निवारण करते समय Apple-प्रबंधित संबंधित डोमेन CDN समापन बिंदु का निरीक्षण करें। इस समापन बिंदु को सार्वजनिक API अनुबंध के बजाय डायग्नोस्टिक बुनियादी ढांचे के रूप में मानें।

चरण 4: AASA परीक्षण के लिए एसोसिएटेड डोमेन डेवलपर मोड का उपयोग करें

कॉफ़ीगरिंग एसोसिएटेड डोमेन पर Apple दस्तावेज़ीकरण के अनुसार, Apple विकास के लिए एक वैकल्पिक मोड प्रदान करता है। developer मोड (?mode=developer) पात्र विकास उपकरणों को Apple-प्रबंधित CDN को बायपास करने और HTTPS पर संबंधित डोमेन से सीधे AASA फ़ाइल फ़ैच करने की अनुमति देता है।

नीचे दिया गया कॉन्फ़िगरेशन प्रदर्शित करता है कि अलग-अलग Xcode एंटाइटेलमेंट कॉन्फ़िगरेशन में डेवलपर मोड कैसे घोषित करें:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>applinks:custom.opwakeup.com</string>
    </array>
</dict>
</plist>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>applinks:custom.opwakeup.com?mode=developer</string>
    </array>
</dict>
</plist>

एक बार जब ऑपरेटिंग सिस्टम डोमेन एसोसिएशन स्थापित कर लेता है, तो एप्लिकेशन-स्तरीय रूटिंग मानक UIKit या SwiftUI लाइफसाइक्ल डेलीगेट का उपयोग करके आने वाले URL पेलोड को संभालती है:

import UIKit

// ----------------------------------------------------------------------------
// 1. UIKit AppDelegate Implementation
// ----------------------------------------------------------------------------
@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        return true
    }

    // Standard Apple Universal Link Continuation Callback
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        
        guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
              let incomingURL = userActivity.webpageURL else {
            return false
        }
        
        print("Handling verified Universal Link: \(incomingURL.absoluteString)")
        
        // Dispatch incomingURL to internal router or SDK layer for parameter extraction
        return handleIncomingRoute(incomingURL)
    }

    private func handleIncomingRoute(_ url: URL) -> Bool {
        // Application-level destination routing logic
        // Note: Returning true indicates the app handled the activity, not that URL parsing succeeded.
        return true
    }
}

// ----------------------------------------------------------------------------
// 2. SceneDelegate Lifecycle Implementation (iOS 13+)
// ----------------------------------------------------------------------------
class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        if let userActivity = connectionOptions.userActivities.first(where: { $0.activityType == NSUserActivityTypeBrowsingWeb }),
           let incomingURL = userActivity.webpageURL {
            print("Cold-launch Universal Link: \(incomingURL.absoluteString)")
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        if userActivity.activityType == NSUserActivityTypeBrowsingWeb,
           let incomingURL = userActivity.webpageURL {
            print("Foreground Universal Link: \(incomingURL.absoluteString)")
        }
    }
}

भौतिक हार्डवेयर पर क्लाइंट-साइड डेवलपर मोड सक्षम करने के लिए:

1. iOS 16+ पर, Settings > Privacy & Security > Developer Mode पर जाएँ और इसे चालू (ON) करें (डिवाइस रिबूट आवश्यक है)।
2. Settings > Developer > Associated Domains Development पर जाएँ और स्विच को चालू करें।
3. ?mode=developer एंटाइटेलमेंट वाले विकास प्रावधान प्रोफ़ाइल के साथ हस्ताक्षरित विकास बिल्ड इंस्टॉल करें।
4. उत्पादन नोट्स: ?mode=developer को विकास और आंतरिक परीक्षण कॉन्फ़िगरेशन तक सीमित रखें, और इसे उत्पादन संबंधित-डोमेन एंटाइटेलमेंट में शामिल न करें जब तक कि आपकी तैनाती को स्पष्ट रूप से उस कॉन्फ़िगरेशन की आवश्यकता न हो और वह उसका समर्थन न करता हो।

मूल कारण निर्णय वृक्ष (Root Cause Decision Tree)

Universal Link falls back to web handling
        │
        ├── Does signed application-identifier match AASA appIDs?
        │       ├── NO ──> Correct App ID Prefix or Bundle ID in AASA
        │       └── YES
        │
        ├── Does associated-domains entitlement list the exact domain?
        │       ├── NO ──> Add applinks:<domain> to target entitlements
        │       └── YES
        │
        ├── Does sudo swcutil dl -d <domain> succeed?
        │       ├── NO ──> Fix origin HTTPS, TLS certificates, or 301/302 redirects
        │       └── YES
        │
        ├── Does sudo swcutil verify match the target URL path?
        │       ├── NO ──> Correct components or paths syntax in AASA
        │       └── YES
        │
        └── Check device association state and internal application routing handlers

डायग्नोस्टिक मैट्रिक्स: यूनिवर्सल लिंक विफलताओं के मूल कारण

Xcode में दोहरे-वातावरण (Dual-Environment) कॉन्फ़िगरेशन को लागू करना

एकाधिक बिल्ड कॉन्फ़िगरेशन प्रबंधित करना (डिबग, स्टेजिंग, प्रोडक्शन)

एंटरप्राइज विकास पाइपलाइन अक्सर बिल्ड वातावरण में अलग-अलग बंडल आईडी प्रबंधित करती हैं (जैसे, com.example.app.debug, com.example.app.staging, com.example.app)।

सभी बिल्ड कॉन्फ़िगरेशन में कार्यात्मक यूनिवर्सल लिंक्स बनाए रखने के लिए:

• स्पष्ट AASA घोषणाएँ: होस्ट की गई AASA फ़ाइल को अपने appIDs सरणी में प्रत्येक वातावरण के पूरी तरह से योग्य एप्लिकेशन आइडेंटिफ़ायर को स्पष्ट रूप से सूचीबद्ध करना चाहिए:

  "appIDs": [
    "9JA723G82S.com.example.app",
    "9JA723G82S.com.example.app.staging",
    "9JA723G82S.com.example.app.debug"
  ]
  
  

• लक्ष्य-विशिष्ट एंटाइटेलमेंट: प्रति बिल्ड कॉन्फ़िगरेशन अलग-अलग .entitlements फ़ाइलों को लिंक करने के लिए Xcode बिल्ड कॉन्फ़िगरेशन सेटिंग्स का उपयोग करें, यह सुनिश्चित करते हुए कि आंतरिक डिबग बिल्ड द्वारा उत्पादन डोमेन की क्वेरी नहीं की जाती है।

लक्ष्य पहचानकर्ताओं (Target Identifiers) का प्रबंधन

यूनिवर्सल लिंक्स समस्या निवारण के लिए, वाइल्डकार्ड आइडेंटिफ़ायर पर भरोसा करने के बजाय हस्ताक्षरित बिल्ड से सटीक बंडल आईडी और एप्लिकेशन आइडेंटिफ़ायर प्रीफ़िक्स का उपयोग करें। प्रत्येक होस्टनेम को स्पष्ट रूप से मानें: यदि ऐप example.com और www.example.com का दावा करता है, तो संबंधित संबंधित-डोमेन प्रविष्टियों को कॉन्फ़िगर करें और सुनिश्चित करें कि प्रत्येक होस्टनेम उचित AASA डेटा प्रदान करता है। सुनिश्चित करें कि एंटाइटेलमेंट उस लक्ष्य पर कॉन्फ़िगर किया गया है जो वास्तव में यूनिवर्सल लिंक्स को संभालता है, और लागू होने पर किसी भी ऐप-एक्सटेंशन या watchOS लक्ष्यों को अलग से सत्यापित करें।

CI/CD में एंबेडेड प्रोविजनिंग प्रोफाइल और हस्ताक्षरित बाइनरी को सत्यापित करना

TestFlight पर बाइनरी अपलोड करने से पहले निरंतर एकीकरण (continuous integration) बिल्ड स्क्रिप्ट के अंदर एंटाइटेलमेंट और एप्लिकेशन आइडेंटिफ़ायर सत्यापन को स्वचालित करें:

# Automated CI validation script
security cms -D -i /path/to/embedded.mobileprovision > provision.plist

# 1. Inspect profile entitlements for allowed Associated Domains
/usr/libexec/PlistBuddy -c "Print :Entitlements:com.apple.developer.associated-domains" provision.plist

# 2. Extract actual signed entitlements from the compiled executable binary
codesign -d --entitlements :- "UnpackedApp/Payload/YourApp.app" > signed-entitlements.plist 2>/dev/null
SIGNED_APP_ID=$(/usr/libexec/PlistBuddy -c "Print :application-identifier" signed-entitlements.plist)
echo "Extracted Signed Application Identifier: $SIGNED_APP_ID"

# 3. Validate that signed Associated Domains match the target domain
/usr/libexec/PlistBuddy -c "Print :com.apple.developer.associated-domains" signed-entitlements.plist

# 4. Verify that the signed App ID exists in the hosted AASA file via Python
python3 -c "
import json, sys
signed_id = sys.argv[1]
data = json.load(open('apple-app-site-association'))
app_ids = [app for detail in data.get('applinks', {}).get('details', []) for app in detail.get('appIDs', [])]
if signed_id not in app_ids:
    print(f'AASA mismatch: {signed_id} not found in AASA appIDs: {app_ids}')
    sys.exit(1)
print(f'AASA consistency check passed: {signed_id} registered')
" "$SIGNED_APP_ID"

यदि सत्यापन स्क्रिप्ट त्रुटि कोड के साथ बाहर निकलती है, तो उत्पादन के लिए गैर-कार्यात्मक डीप लिंकिंग बाइनरी भेजने से रोकने के लिए बिल्ड पाइपलाइन को निरस्त कर दें।

यूनिवर्सल लिंक मिलान मानदंड

विश्वसनीय रूटिंग सुनिश्चित करने के लिए, निम्नलिखित शर्तों को एक साथ पूरा किया जाना चाहिए:

Signed App Configuration:
application-identifier = <ApplicationIdentifierPrefix>.<CFBundleIdentifier>
com.apple.developer.associated-domains = applinks:<hostname>

AASA Configuration:
appIDs = [..., "<ApplicationIdentifierPrefix>.<CFBundleIdentifier>", ...]
components / paths = Matching target URL paths and query parameters

System Eligibility:
1. Associated Domains entitlement explicitly contains the target hostname.
2. The signed Application Identifier matches an authorized entry in the domain's AASA appIDs.
3. The incoming URL satisfies the AASA routing patterns.
4. Device association state and user/browser context permit native application delegation.

भले ही एंटाइटेलमेंट, AASA एसोसिएशन और URL पैटर्न सभी मेल खाते हों, देखा गया रूटिंग अभी भी डिवाइस स्थिति और उपयोगकर्ता या ब्राउज़र संदर्भ पर निर्भर हो सकता है। उदाहरण के लिए, जब कोई उपयोगकर्ता सफारी में समान डोमेन को पहले से ब्राउज़ करते समय किसी यूनिवर्सल लिंक पर टैप करता है, तो ऑपरेटिंग सिस्टम सफारी में रहने के उपयोगकर्ता के इरादे का सम्मान कर सकता है।

सारांश और निर्णय ढांचा

यूनिवर्सल लिंक रूटिंग विश्वसनीयता तीन नोड्स में सटीक, वर्ण-स्तरीय संरेखण पर निर्भर करती है: Apple डेवलपर पोर्टल ऐप आईडी कॉन्फ़िगरेशन, Xcode com.apple.developer.associated-domains एंटाइटेलमेंट, और होस्ट की गई apple-app-site-association JSON फ़ाइल। कोई तृतीय-पक्ष SDK या रूटिंग फ़्रेमवर्क विफल ऑपरेटिंग सिस्टम डोमेन एसोसिएशन की मरम्मत नहीं कर सकता है; यह केवल URL को तब संसाधित कर सकता है जब iOS ने सफलतापूर्वक एप्लिकेशन को यूनिवर्सल लिंक वितरित कर दिया हो। यदि यूनिवर्सल लिंक्स ऑपरेटिंग सिस्टम स्तर पर सही ढंग से जुड़े हुए हैं लेकिन पैरामीटर निष्कर्षण विफल हो जाता है, तो डोमेन एसोसिएशन परत से अलग एप्लिकेशन-स्तरीय रूटिंग परत का निरीक्षण करें।

यदि आपके एप्लिकेशन को यूनिवर्सल लिंक एसोसिएशन सफल होने के बाद गतिशील-लिंक पैरामीटर बहाली (parameter restoration) और ऑनबोर्डिंग रूटिंग की भी आवश्यकता है, तो OpoInstall उस एप्लिकेशन-स्तरीय वर्कफ़्लो के लिए एक वैकल्पिक SDK परत प्रदान करता है।

डोमेन कॉन्फ़िगरेशन पैटर्न और डीप लिंकिंग एकीकरण के बारे में अधिक जानने के लिए, OpoInstall डीप लिंकिंग दस्तावेज़ीकरण की समीक्षा करें।

संबंधित सामग्री

• अवधारणाएं: एप्लिकेशन आइडेंटिफ़ायर सत्यापन, AASA स्कीमा सत्यापन, Apple CDN कैशिंग, एंटाइटेलमेंट एक्सट्रैक्शन

• प्रौद्योगिकियां: iOS यूनिवर्सल लिंक्स, Xcode एंटाइटेलमेंट्स, Apple डेवलपर पोर्टल, शेयर्ड वेब क्रेडेंशियल्स

• मानक: IETF RFC 8259 (JSON डेटा इंटरचेंज), TLS 1.3 विशिष्टता

• डायग्नोस्टिक टूल: Apple codesign CLI टूल, macOS swcutil टूल, Apple-प्रबंधित CDN कैश क्वेरी

आधिकारिक दस्तावेज़ीकरण

• संबंधित डोमेन का समर्थन करने पर Apple डेवलपर दस्तावेज़ीकरण

• संबंधित डोमेन एंटाइटेलमेंट को कॉन्फ़िगर करने पर Apple डेवलपर दस्तावेज़ीकरण

• Apple डेवलपर तकनीकी नोट TN3155: यूनिवर्सल लिंक्स डिबगिंग

• अपने ऐप में यूनिवर्सल लिंक्स का समर्थन करने पर Apple डेवलपर दस्तावेज़ीकरण