universal links सेटअप: iOS और Android की वेब ओर से

universal links सेटअप में वेबसाइट का हिस्सा दो JSON फ़ाइलें हैं, जिन्हें आप खुद होस्ट करते हैं: iOS के लिए apple-app-site-association और Android के लिए assetlinks.json। जब कोई सामान्य https:// link टैप करता है, तो ये दोनों फ़ाइलें ऐप को वेबसाइट की जगह उसे खोलने देती हैं। दोनों फ़ाइलें उस हर domain पर /.well-known/ के अंतर्गत रहती हैं जिसे ऐप सँभालता है, दोनों को बिना redirect के HTTPS पर परोसना होता है, और हर एक उस ऐप का नाम देती है जिसे आपके URLs खोलने की अनुमति है। ऐप में भी मेल खाती सेटिंग चाहिए (iOS पर entitlement, Android पर intent filter), जो हर फ़ाइल के साथ नीचे दिखाई गई है।

universal links और Android App Links कैसे काम करते हैं

दोनों प्रणालियाँ वेबसाइट और ऐप को दो दिशाओं में जोड़ती हैं: ऐप बताता है कि वह कौन से domains सँभालता है, और वेबसाइट उसकी पुष्टि करती है। Apple universal links को सामान्य HTTP या HTTPS links बताता है, इसलिए एक ही URL वेबसाइट और ऐप, दोनों के लिए काम करता है, और जिन उपयोगकर्ताओं के पास ऐप नहीं है उन्हें browser में पेज मिलता है (Apple)। Google के शब्दों में, Android App Links उसी intent-आधारित प्रणाली पर बने हैं जो दूसरे deep links पर है, पर आपकी वेबसाइट पर Digital Asset Links फ़ाइल से सत्यापन का एक चरण और जोड़ते हैं (Android Developers)।

“Deep link” एक व्यापक शब्द है। साधारण deep link custom scheme या बिना सत्यापन वाला https:// link हो सकता है; universal links और App Links सत्यापित प्रकार के हैं।

iOS फ़ाइल: apple-app-site-association

apple-app-site-association नाम की फ़ाइल बनाएँ, बिना extension के, और उसमें अपने app identifiers और वे URL patterns लिखें जिन्हें ऐप खोलना चाहिए। यह Apple के दस्तावेज़ का संक्षिप्त नमूना है:

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.example.app"],
        "components": [
          { "/": "/buy/*", "comment": "Open URLs that start with /buy/ in the app." },
          { "/": "/help/website/*", "exclude": true, "comment": "Keep these in the browser." }
        ]
      }
    ]
  }
}

appIDs का मान application identifier prefix (आपका Team ID) होता है, उसके बाद एक बिंदु, फिर bundle identifier। components का हर item URL के एक हिस्से से मेल खाता है, और "exclude": true सिस्टम को बताता है कि मेल खाने वाले URLs ऐप में न खोले जाएँ (Apple, Supporting associated domains)। Apple पुराने format को भी स्वीकार करता है, जिसमें appID और paths होते हैं; उसकी debugging टिप्पणी कहती है कि दोनों को न मिलाएँ (TN3155)।

इसे https://<पूरा domain>/.well-known/apple-app-site-association पर रखें, वैध certificate के साथ और बिना redirect के। Apple के पन्नों के तीन नियम लोगों को अक्सर उलझाते हैं:

• हर subdomain के लिए ऐप में अपनी अलग प्रविष्टि चाहिए। example.com पर रखी फ़ाइल applinks:example.com और applinks:*.example.com दोनों को परोसती है, जबकि www.example.com जैसे खास subdomain के लिए उसकी अपनी फ़ाइल चाहिए।
• फ़ाइल किसी भी IP पता और किसी भी user agent से पहुँचने योग्य होनी चाहिए। firewall, bot filter या login wall से मिला 403 या 404 Apple के सर्वरों को उसे cache करने से रोकता है।
• iOS 14 से, डिवाइस आपके server से फ़ाइल नहीं लाते। Apple का CDN फ़ाइल लाता और cache करता है, डिवाइस लगभग हर हफ़्ते अपडेट जाँचते हैं, और cache को सीधे invalidate करने का कोई तरीका नहीं है; ऐप को दोबारा इंस्टॉल करने पर नई प्रति आती है (TN3155)।

development के दौरान entitlement प्रविष्टि में ?mode=developer जोड़ सकते हैं (applinks:example.com?mode=developer), ताकि डिवाइस फ़ाइल Apple के CDN के बजाय सीधे आपके server से पढ़े।

Android फ़ाइल: assetlinks.json

assetlinks.json statements का एक array है, जिसमें आपका package name और ऐप को sign करने वाले certificate का SHA-256 fingerprint होता है। एक ऐप के लिए Google का उदाहरण:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

package name और fingerprint को अपने मानों से बदलें। शर्तें Google की guide से (23 अक्टूबर 2026 को अपडेट):

• इसे https://<domain>/.well-known/assetlinks.json पर application/json content type के साथ परोसें।
• HTTPS का इस्तेमाल करें, भले ही ऐप के intent filters में http भी घोषित हो।
• कोई redirect नहीं, न 301 न 302।
• इसे ऐप द्वारा सँभाले जाने वाले हर host domain पर प्रकाशित करें।
• एक फ़ाइल में कई ऐप हो सकते हैं, और sha256_cert_fingerprints फ़ील्ड कई fingerprints ले सकता है, जैसे debug और production build के लिए।

अगर आप Play App Signing इस्तेमाल करते हैं, तो आपके स्थानीय keytool का fingerprint आम तौर पर उपयोगकर्ताओं के डिवाइस वाले से मेल नहीं खाएगा। Google कहता है कि सही JSON टुकड़ा Play Console में Release > Setup > App signing से लें।

ऐप की ओर autoVerify वाला intent filter है। Android के दस्तावेज़ का यह रूप है:

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="http" />
    <data android:scheme="https" />
    <data android:host="www.example.com" />
</intent-filter>

Android ऐसे filters में हर hostname की पुष्टि करता है, और *.example.com जैसे wildcard host के लिए root domain example.com पर फ़ाइल चाहिए (Android Developers)। Android 15 और उसके बाद, सत्यापन समय-समय पर भी चलता है, और फ़ाइल में बदलाव लागू होने में सात दिन तक लग सकते हैं; Android 14 और उससे नीचे फ़ाइल केवल इंस्टॉल या अपडेट के समय पढ़ी जाती है (Android Developers)।

server की जाँच-सूची

दोनों फ़ाइलें कुछ ही एक जैसे कारणों से फ़ेल होती हैं, इसलिए server को दोनों के लिए एक साथ जाँचें:

content type के लिए, दोनों फ़ाइलों को application/json के रूप में परोसने से सेटअप एक जैसा रहता है। Apple का दस्तावेज़ iOS फ़ाइल के लिए content type नहीं बताता, इसलिए वह हिस्सा आपका चुनाव है। एक स्थिर nginx उदाहरण:

location = /.well-known/apple-app-site-association {
    default_type application/json;
}
location = /.well-known/assetlinks.json {
    default_type application/json;
}

जाँचें कि यह काम कर रहा है

फ़ाइल को बाहर से जाँचें, फिर डिवाइस पर व्यवहार। TN3155 से Apple के अपने debugging चरण:

1. curl -v https://<domain>/.well-known/apple-app-site-association चलाएँ और पुष्टि करें कि 200 और JSON मिल रहा है, 301, 302, 403 या 404 नहीं।
2. Mac पर, sudo swcutil dl -d <domain> जाँचता है कि फ़ाइल डाउनलोड होती है, और sudo swcutil verify -d <domain> -j <path-to-JSON> -u <URL> जाँचता है कि कोई URL pattern से मेल खाता है।
3. iPhone पर, link को Notes ऐप में चिपकाएँ और दबाकर रखें। अगर सब ठीक सेट है, तो “ऐप में खोलें” और “browser में खोलें”, दोनों विकल्प दिखेंगे।

Android के लिए, Android 12 और उसके बाद Google की मैनुअल सत्यापन प्रक्रिया (जो ऐप Android 12 से नीचे को target करता है, उसके लिए पहले adb shell am compat enable 175408749 com.example चलाएँ):

adb shell pm set-app-links --package com.example 0 all
adb shell pm verify-app-links --re-verify com.example
# कुछ मिनट इंतज़ार करें, फिर:
adb shell pm get-app-links com.example

आउटपुट हर domain को उसकी स्थिति के साथ सूचीबद्ध करता है, जैसे verified या legacy_failure। Google एक Statement List Generator और Tester भी देता है (Digital Asset Links tool), जो मौजूदा statement फ़ाइल को टेस्ट करने के लिए है। व्यापक टेस्ट के लिए मोबाइल वेबसाइट टेस्टिंग चेकलिस्ट देखें।

कब links ऐप नहीं खोलते

iOS पर browser के address bar में URL टाइप करने से ऐप कभी नहीं खुलता, क्योंकि वह browser के भीतर सीधा navigation है; और अगर उपयोगकर्ता पहले से आपके domain पर है, तो उसी domain का link भी Safari में ही रहता है (TN3155)। लॉगिन बटन जैसे flows के लिए Apple का समाधान है एक अलग subdomain, जिसकी अपनी applinks प्रविष्टि और AASA फ़ाइल हो, ताकि सिस्टम टैप को साइट से बाहर जाना माने।

ऐप के भीतर के browsers को अलग से टेस्ट करना होगा। Apple कहता है कि browser ऐप या WKWebView में टैप किए गए links आपका ऐप खोल सकते हैं, पर वह यह भी कहता है कि तीसरे-पक्ष के browsers यह तय करते हैं कि universal links चालू हों या नहीं (“Universal links may not be enabled in every web browser”, TN3155 से), और जो ऐप आपका link अपने open(_:) call से खोलता है, वह उलटा आपके link को नहीं खोलेगा (Apple)। किसी सोशल ऐप का browser link को आपके ऐप को सौंपता है या नहीं, यह platform के दस्तावेज़ में नहीं है, इसलिए जिन ऐप्स की आपको परवाह है, उन्हें असली फ़ोन पर टेस्ट करें।

fallback के रूप में स्मार्ट ऐप बैनर

स्मार्ट ऐप बैनर वेब पेज पर केवल iOS का एक prompt है: जिन पेजों पर आप इसे चाहते हैं, उनके <head> में एक meta tag। Apple के अनुसार, ऐप इंस्टॉल हो तो वह उसे खोलता है, और न हो तो App Store पर link करता है।

<meta name="apple-itunes-app" content="app-id=myAppStoreID, app-argument=https://example.com/buy/42">

app-id अनिवार्य है, और वैकल्पिक app-argument ऐप को एक URL देता है ताकि वह मेल खाती स्क्रीन खोल सके। Apple दो सीमाएँ बताता है: बैनर frame के भीतर नहीं दिखते, और iOS simulator में नहीं दिखते।

अगर आप कोई native ऐप नहीं देते, तो इनमें से किसी फ़ाइल की ज़रूरत नहीं; progressive web app browser से इंस्टॉल होता है।

फ़ोन-आकार पर fallback पेज जाँचें

जिन लोगों के पास ऐप नहीं है, और हर वह link जो ऐप तक नहीं पहुँचता, वे आपके वेब पेज पर आते हैं, इसलिए वह पेज फ़ोन पर सही काम करना चाहिए। Mobile View Extension tab को फ़ोन के user agent, screen size और pixel ratio के साथ दोबारा लोड करता है, इसलिए आप कई आकारों पर fallback पेज का असली mobile version देख सकते हैं, और उसके साथ Chrome की device emulation भी इस्तेमाल कर सकते हैं। पर यह ऐप हैंडऑफ़ को खुद टेस्ट नहीं कर सकता: यह desktop Chrome चलाता है, इसमें touch events नहीं होते और कोई इंस्टॉल ऐप नहीं होता, इसलिए link हैंडलिंग के लिए iPhone या Android फ़ोन, या iOS simulator या Android emulator चाहिए। बिना iOS हार्डवेयर के, iPhone के बिना iPhone पर वेबसाइट टेस्ट करना देखें।

अक्सर पूछे जाने वाले सवाल

universal links और deep links में क्या फ़र्क है?

deep links व्यापक श्रेणी है; universal links Apple का सत्यापित प्रकार है, जो मानक HTTP या HTTPS links पर बना है। deep link custom URL scheme भी इस्तेमाल कर सकता है, जो आपकी नियंत्रित वेबसाइट से नहीं बँधा होता। Android App Links Android पर सत्यापित रूप है, जो सामान्य deep links में Digital Asset Links जाँच जोड़ता है।

apple-app-site-association कहाँ रखी जाती है?

https://<domain>/.well-known/apple-app-site-association पर, बिना file extension के, HTTPS पर वैध certificate के साथ और बिना redirect के। ऐप में सूचीबद्ध हर subdomain को उसकी अपनी प्रति चाहिए।

मेरा universal link ऐप की जगह Safari क्यों खोलता है?

आम कारण हैं: redirect, फ़ाइल पर 403 या 404, किसी subdomain की प्रविष्टि का न होना, या उसी domain पर टैप। Apple इन्हें TN3155 में सूचीबद्ध करता है; address bar में URL टाइप करना, या Safari में उसी domain का link टैप करना, उपयोगकर्ता को browser में रखता है। पहले curl -v से फ़ाइल जाँचें।

क्या मुझे दोनों फ़ाइलों की ज़रूरत है?

आपको हर उस प्लेटफ़ॉर्म की फ़ाइल चाहिए जिसका ऐप आप देते हैं। iOS ऐप और Android ऐप, दोनों वाली वेबसाइट दोनों परोसती है, और दोनों एक-दूसरे पर निर्भर नहीं हैं।