Universal Link — ano ito, prinsipyo ng paggana at pag-configure

Ano ang Universal Link

Universal Link ay isang karaniwang HTTPS link na may anyong https://example.com/page na kapag na-click mula sa iOS device ay nagbubukas ng naka-install na app sa halip na Safari. Ang pangunahing pagkakaiba sa Custom URL Scheme: hindi nangangailangan ang Universal Link ng pagpaparehistro ng custom na scheme (myapp://) — gumagamit ito ng ordinaryong domain. Tinatanggal nito ang problema ng URL Scheme hijacking, kung saan ang anumang app ay maaaring magparehistro ng parehong scheme.

Ipinakilala ng Apple ang Universal Link sa WWDC 2015 sa loob ng iOS 9. Ang mekanismo ay naging bahagi ng Handoff at Spotlight ecosystem: ang Universal Link ay gumagana hindi lamang sa browser, kundi pati na rin sa mga resulta ng paghahanap sa Spotlight, sa Mail, Messages at iba pang system app. Bilang karagdagan, ang Universal Link ay sinusuportahan sa watchOS at macOS — maaaring buksan ng user ang app sa iPhone sa pamamagitan ng isang link sa Mac.

Ang pangunahing bentahe: nag-iisang URL. Hindi pinamamahalaan ng developer ang dalawang magkaibang link (isa para sa web, isa para sa app). Ang Universal Link ay ang parehong https link. Kung naka-install ang app — ito ang bubukas. Kung hindi — ang parehong link ay bubukas sa Safari bilang isang ordinaryong web page. Nagbibigay ito ng perpektong fallback nang walang pagkawala ng trapiko.

Paano Gumagana ang Universal Link

Ang mekanismo ng Universal Link ay binubuo ng tatlong yugto: pag-verify ng asosasyon, pagproseso ng link, at fallback sa browser. Ang bawat yugto ay kritikal para sa tamang operasyon. Kung hindi naka-configure ang asosasyon, itinuturing ng iOS ang link bilang isang ordinaryong paglipat sa Safari. Tingnan natin ang bawat yugto nang detalyado.

Pag-verify ng Asosasyon (Association Verification)

Sa unang pag-click sa link, iOS ay nagda-download ng file na apple-app-site-association mula sa server sa address na https://example.com/.well-known/apple-app-site-association. Ang file ay naglalaman ng JSON na may Team ID at Bundle ID ng app, pati na rin ang listahan ng mga path na dapat buksan ng app. Ini-cache ng iOS ang file na ito at pana-panahong sinusuri ang pagiging bago nito (kapag nag-a-update ng app, nag-restart ng device).

Ang JSON file apple-app-site-association ay dapat na ma-access sa pamamagitan ng HTTPS nang walang mga redirect. Dapat ibalik ng server ang Content-Type: application/json. Mahalaga: ang file ay walang .json extension — hinahanap ito ng iOS nang mahigpit sa path na /.well-known/apple-app-site-association. Inirerekomenda din ng Apple na magdagdag ng suporta para sa Universal Link sa CDN at suriin na ang file ay hindi na-block ng robots.txt.

// apple-app-site-association — minimal na configuration
{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "TEAMID.com.example.app",
                "paths": ["/product/*", "/profile/*", "/search"]
            }
        ]
    }
}

appID ay nabuo bilang Team ID + Bundle ID (TEAMID.com.example.app). paths — isang array ng mga pattern ng URL na dapat iproseso ng app. Maaaring gamitin ang *, ? at NOT notation: ["NOT /admin/*", "/product/*"]. Ang mga path ay sinusuri sa pagkakasunud-sunod ng enumeration: ang unang tugma ay tumutukoy sa pag-uugali. Kung hindi tumugma ang path — bubukas ang link sa Safari.

Pagproseso ng Link (Link Handling)

Pagkatapos ng matagumpay na pag-verify ng asosasyon, iOS ay nagpapasa ng link sa app. Ang pagproseso ay ginagawa sa AppDelegate sa pamamagitan ng method na application(_:continue:restorationHandler:) para sa NSUserActivity o sa SceneDelegate sa pamamagitan ng scene(_:continue:). Ang developer ay tumatanggap ng NSUserActivity object na may uri na NSUserActivityTypeBrowsingWeb, kinukuha ang URL, at nag-navigate sa kaukulang screen.

// Pagproseso ng Universal Link sa AppDelegate
func application(
    _ application: UIApplication,
    continue userActivity: NSUserActivity,
    restorationHandler: @escaping UIUserActivityRestorationHandler
) -> Bool {
    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
          let url = userActivity.webpageURL
    else { return false }

    // Pag-navigate sa screen ayon sa URL
    DeepLinkRouter.navigate(to: url)
    return true
}

DeepLinkRouter sa halimbawa sa itaas ay isang custom na klase na nag-parse ng URL at tumatawag sa kaukulang navigation coordinator. Para sa SwiftUI, ang pagproseso ay ginagawa sa pamamagitan ng method na onOpenURL o modifier na environment(\.openURL). Mahalagang iproseso hindi lamang ang foreground launch, kundi pati na rin ang kaso kapag ang app ay hindi pa nasimulan (cold start): ang Universal Link sa kasong ito ay nagbubukas ng app sa pamamagitan ng launch options.

Fallback sa Browser (Browser Fallback)

Kung hindi naka-install ang app, iOS ay awtomatikong nagbubukas ng Universal Link sa Safari. Ito ang pangunahing pagkakaiba sa Custom URL Scheme: hindi nakakakita ng error ang user. Ang fallback ay isang karaniwang web page ng parehong domain. Ang developer ay maaaring maglagay sa page na ito ng link sa App Store, impormasyon ng produkto, o alternatibong nilalaman.

Mahalaga: ang fallback ay hindi maaaring i-customize sa antas ng iOS. Binubuksan lang ng iOS ang URL sa Safari. Upang magpakita ng ibang nilalaman sa mga user na may naka-install at hindi naka-install na app, gamitin ang Smart App Banner (meta-tag para sa Safari na nagmumungkahi na buksan ang app) o JavaScript detection ng pag-install ng app. Nagbibigay din ang Apple ng SKAdNetwork para sa attribution ng mga pag-install sa pamamagitan ng Universal Link.

Universal Link vs Deep Link

Ang Universal Link at tradisyonal na Deep Link (Custom URL Scheme) ay lumulutas ng parehong gawain, ngunit pangunahing naiiba sa arkitektura at seguridad. Custom URL Scheme — isang custom na protocol (myapp://) na nagrerehistro sa Info.plist. Ang anumang app ay maaaring magrehistro ng parehong scheme (myapp://), at hindi matukoy ng iOS kung alin ang "tunay". Ito ay tinatawag na URL Scheme hijacking.

Universal Link ay lumulutas ng hijacking problem sa pamamagitan ng domain verification. Ang may-ari lamang ng domain ang maaaring maglagay ng apple-app-site-association sa kanyang server, na nagpapatunay ng ugnayan sa isang partikular na Bundle ID. Dalawang app ay hindi maaaring magrehistro ng isang Universal Link: kung magkaroon ng conflict, ang iOS ay nagbibigay ng priyoridad sa huling naka-install na app o nagbubukas ng Safari.

Ibang pagkakaiba: Fallback. Ang Custom URL Scheme ay walang fallback — kung hindi naka-install ang app, nagpapakita ng error ang browser. Binubuksan ng Universal Link ang website. Ang nag-iisang URL ay nangangahulugan na ang SEO value ng link ay nananatili (ang link ay ini-index ng Google), at ang user na may anumang device ay nakakatanggap ng may-katuturang nilalaman. Ang Universal Link ay isang ebolusyonaryong hakbang mula deep link patungo sa unified link.

Pag-configure ng Universal Link

Pag-configure ng Universal Link ay may kasamang bahagi ng server at kliyente. Bahagi ng server — paglalagay ng apple-app-site-association file sa address na https://domain/.well-known/apple-app-site-association. Bahagi ng kliyente — pagrerehistro ng domain sa Associated Domains sa Xcode (Capabilities → Associated Domains → applinks:example.com). Pagkatapos nito, awtomatikong natatanggap ng app ang lahat ng Universal Link para sa tinukoy na domain.

Mga hakbang sa pag-configure:

1. Gumawa ng apple-app-site-association na may tamang appID (TeamID.BundleID) at paths
2. Ilagay ang file sa server sa path na /.well-known/ nang walang .json extension
3. Suriin ang accessibility: curl https://domain/.well-known/apple-app-site-association
4. Idagdag ang domain sa Associated Domains (Xcode Capabilities)
5. Ipatupad ang pagproseso sa pamamagitan ng NSUserActivity (AppDelegate o SceneDelegate)
6. Subukan sa isang tunay na device (hino-verify ng simulator ang asosasyon)

Pag-debug ng Universal Link — karaniwang sakit ng ulo ng mga iOS developer. Mga pangunahing dahilan ng hindi gumaganang mga link: hindi accessible ang apple-app-site-association file sa pamamagitan ng HTTPS, maling appID, hindi application/json ang Content-Type, redirect mula sa /.well-known path, pag-cache ng lumang bersyon (reset sa pamamagitan ng Settings → Developer → Associated Domains Development). Nagbibigay ang Apple ng tool na "Validation Checker" sa Apple Developer Console para sa pagsubok ng asosasyon.

Branch at iba pang MMP platform ay pinapasimple ang pag-configure ng Universal Link: awtomatiko nilang binuo ang apple-app-site-association at i-host ito sa kanilang sariling domain. Ang developer ay kailangan lamang idagdag ang Branch domain sa Associated Domains at i-integrate ang SDK. Ito ay lalong maginhawa para sa mga startup na walang sariling server infrastructure para sa pagho-host ng AASA file.

Mga Limitasyon at Pagkatugma

Universal Link ay may ilang mga limitasyon. Una: ang apple-app-site-association file ay dapat na mahigpit na ma-access sa pamamagitan ng HTTPS (hindi sinusuportahan ang HTTP). Pangalawa: ang link ay dapat pumunta sa parehong domain na tinukoy sa Associated Domains. Hindi gumagana ang cross-domain Universal Links — para sa bawat domain ay kailangan ng hiwalay na entry sa Capabilities at hiwalay na AASA file. Pangatlo: hindi gumagana ang Universal Link sa WKWebView — sa Safari lamang at mga system component.

Pagkatugma: iOS 9.0+ (Universal Link), watchOS 6.0+ (Handoff Universal Link), macOS 10.15+ (Catalyst at Mac app). Sa mas lumang bersyon ng iOS, bubukas ang link sa Safari. Nangangahulugan ito na sa iOS 8 (mas mababa sa 1% ng mga device) hindi gagana ang Universal Link. Inirerekomenda na suportahan din ang Custom URL Scheme bilang fallback para sa mga lumang device, kung ang audience ay may kasamang user na may lumang bersyon.

Mga pagbabago sa iOS 16+: Pinahusay ng Apple ang pagproseso ng Universal Link para sa SwiftUI. Lumitaw ang isang bagong modifier na environment(\.openURL) na may kakayahang maantalang pagproseso. Pinapayagan din ng iOS 16 na buksan ang Universal Link sa app kahit sa pamamagitan ng SFSafariViewController. Para sa mga user ng iOS 16, inirerekomenda na ganap na lumipat sa SwiftUI processing ng Universal Link, na iiwan ang AppDelegate code para lamang sa backward compatibility.