URL Scheme: wat het is, hoe het werkt en wordt gebruikt in ontwikkeling

Wat is URL Scheme?

URL Scheme — is een unieke protocolidentificatie die een applicatie registreert in het besturingssysteem om oproepen via aangepaste links te ontvangen. Wanneer een gebruiker op een link zoals myapp://profile/123 klikt, identificeert het systeem de applicatie die het schema myapp heeft geregistreerd en draagt de controle met de volledige URI over. Dit mechanisme stelt applicaties in staat gegevens uit te wisselen en elkaar te openen zonder tussenkomst van serverinfrastructuur.

Het concept van URL Scheme is rechtstreeks overgenomen uit de webstandaarden RFC 3986, waar het URI-schema de eerste component is van elke universele resource-identificatie. In mobiele ontwikkeling is dit idee aangepast voor communicatie tussen applicaties, waar in plaats van een HTTP-server de applicatie zelf de link verwerkt.

Voorbeelden van bekende URL Schemes

Veel populaire applicaties registreren hun eigen URL Schemes voor integratie met externe diensten. Spotify gebruikt bijvoorbeeld het schema spotify://, Telegram — tg://, en Instagram — instagram://. Ontwikkelaars maken ook vaak een schema van het type appname:// voor interne navigatie en het testen van schermen.

URL Schemes worden nog steeds op grote schaal gebruikt in pushmeldingen, e-mailcampagnes en QR-codes, waar onmiddellijke overgang naar een specifiek gedeelte van de applicatie vereist is. Vanaf iOS 9 en Android 6 zijn er echter alternatieve mechanismen verschenen die de kale schema's geleidelijk aanvullen en vervangen.

URL Scheme-syntaxis: schema, host en pad

De structuur van een aangepaste URI voldoet aan de algemene specificatie RFC 3986 en bestaat uit verschillende componenten. Het schema wordt als eerste gespecificeerd en gescheiden door een dubbele punt van de rest van het adres. Na het schema kunnen host, poort, pad, query-parameters en fragment volgen, die elk optioneel zijn.

De volledige syntaxis ziet eruit als scheme://host/path?key=value#fragment. Het schema is het enige verplichte element, de rest wordt bepaald door de behoeften van de specifieke implementatie. De dubbele schuine streep na het schema is historisch afkomstig van HTTP en is niet strikt verplicht volgens de specificatie, maar wordt overal als conventie gebruikt.

URI-componenten

Voor een visuele weergave van de URI-structuur wordt een componententabel gebruikt. Elk element heeft zijn eigen doel en verplichtingsniveau.

Ontwikkelaars kunnen vrij de structuur van de URI kiezen, wat flexibiliteit biedt, maar compatibiliteitsproblemen veroorzaakt tussen verschillende versies van de applicatie. Het wordt aanbevolen om het URL Scheme-formaat te documenteren als onderdeel van de publieke API van de applicatie en het te versiebeheren bij wijzigingen.

Hoe URL Scheme werkt in iOS

iOS vereist expliciete registratie van elke URL Scheme in het Info.plist-bestand van het project. De ontwikkelaar voegt een array CFBundleURLTypes toe, waarvan elk element een identificatie (CFBundleURLName) en een lijst met ondersteunde schema's (CFBundleURLSchemes) bevat. Na registratie stuurt het systeem automatisch alle inkomende oproepen naar geregistreerde schema's naar de applicatie.

De verwerking van een inkomende URL Scheme vindt plaats in de applicatie-delegate via de methode application(_:open:options:). Deze methode ontvangt een URL-object waaruit het pad en de query-parameters worden geëxtraheerd om een navigatiebeslissing te nemen. De verwerking moet een Bool-waarde retourneren die het succes van de operatie aangeeft.

Verwerking in AppDelegate

Hieronder staat een voorbeeld van een implementatie van een URL Scheme-handler in de taal Swift. De code demonstreert het extraheren van de host en query-parameters uit de inkomende URI met behulp van URLComponents.

func application(
    _ app: UIApplication,
    open url: URL,
    options: [UIApplication.OpenURLOptionsKey: Any]
) -> Bool {
    let host = url.host
    let params = URLComponents(
        url: url,
        resolvingAgainstBaseURL: false
    )?.queryItems
    if host == "profile" {
        navigateToProfile(params)
    }
    return true
}

De methode gebruikt URLComponents voor het veilig parsen van query-parameters. Deze benadering heeft de voorkeur boven handmatige parsing van de string, omdat het automatisch procentuele codering en decodering van speciale tekens in parameterwaarden afhandelt.

Hoe URL Scheme werkt in Android

Android gebruikt het Intent Filter-systeem voor het routeren van deep links op basis van URL Scheme. De ontwikkelaar declareert de filter in AndroidManifest.xml binnen de tag van de Activity die de link moet verwerken. De filter bevat action VIEW, de categorieën BROWSABLE en DEFAULT, en de tag data met specificatie van het schema, de host en pathPrefix.

Wanneer een gebruiker op een link met een aangepast schema klikt, controleert het systeem de Intent Filters van alle geïnstalleerde applicaties. Als er meerdere geschikte applicaties worden gevonden, krijgt de gebruiker een keuzedialoog te zien. De categorie BROWSABLE staat verwerking van de link vanuit de browser toe.

Intent Filter configureren

Voorbeeld van een Intent Filter-declaratie in AndroidManifest.xml voor verwerking van het schema myapp op een Activity. De combinatie van action en category is verplicht voor correcte routering van de deep link.

<activity android:name=".MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category
            android:name="android.intent.category.DEFAULT" />
        <category
            android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="myapp"
            android:host="profile"
            android:pathPrefix="/user" />
    </intent-filter>
</activity>

Na het configureren van de filter moet in de Activity intent.getData() worden aangeroepen om de URI te verkrijgen. Het is belangrijk om intent en gegevens op null te controleren, aangezien de Activity kan worden gestart zonder een inkomende deep link, bijvoorbeeld bij standaard starten vanuit de launcher.

Parameters doorgeven via URL Scheme

Query-parameters in URL Scheme worden na het vraagteken doorgegeven in de sleutel=waarde-indeling, gescheiden door een ampersand. Deze indeling is identiek aan HTTP-verzoeken en wordt gemakkelijk verwerkt door de standaardtools van het platform. Parameters moeten worden gecodeerd met behulp van procentuele codering voor alle tekens die niet tot de toegestane URI-set behoren.

Voorbeeld van een volledige link met parameters: myapp://profile?userId=42&source=email&ref=abc123. Na extractie van de URL parseert de applicatie achtereenvolgens alle query-items en neemt op basis van hun waarden een navigatiebeslissing naar het doelscherm.

Beperking van URI-lengte

Bij het doorgeven van samengestelde gegevens is het belangrijk rekening te houden met de beperking van de URI-lengte. In iOS is de maximale lengte van URL Scheme beperkt tot 2 KB, waarna het systeem de link afkapt. In Android is de limiet ongeveer 8 KB, maar de exacte waarde hangt af van de versie van het besturingssysteem en de fabrikant van het apparaat. Voor grote hoeveelheden gegevens wordt aanbevolen alleen de sessie-id via URL Scheme door te geven en de overige gegevens van de server te laden.

Beperkingen en alternatieven van URL Scheme

Het belangrijkste nadeel van URL Scheme — het onvermogen om de link te verwerken als de applicatie niet op het apparaat is geïnstalleerd. De browser geeft een fout weer en de gebruiker verliest de context van de overgang. Om dit probleem op te lossen heeft Apple Universal Links geïntroduceerd in iOS 9 en Google App Links in Android 6. Beide mechanismen worden geregistreerd via een webdomein dat aan de applicatie is gekoppeld.

Universal Links en App Links werken als gewone HTTPS-links, maar openen de applicatie zonder keuzedialoog als deze aanwezig is. Als de applicatie niet is geïnstalleerd, opent de link een webpagina op hetzelfde domein, wat de gebruikerservaring behoudt. Dit maakt hen de voorkeursalternatief voor de productieomgeving.

Fallback-mechanismen

Voor URL Scheme op iOS en Android is er geen ingebouwd fallback-mechanisme. Ontwikkelaars gebruiken tussenliggende serveroplossingen: de link leidt naar een webpagina die de installatie van de applicatie controleert via JavaScript en doorverwijst naar ofwel het schema ofwel de app store. Firebase Dynamic Links en Branch.io bieden kant-en-klare oplossingen voor dit probleem met ondersteuning voor deferred deep links, die automatisch de installatiestatus bepalen en de gebruiker doorverwijzen zonder dat een eigen serverpipeline hoeft te worden ontwikkeld.

Extra complexiteit ontstaat bij het gebruik van URL Scheme in iOS 15+ en Android 12+, waar de privacyregels zijn aangescherpt. Safari blokkeert pogingen om een niet-geregistreerd schema te openen zonder voorafgaande bevestiging, en Android 12 beperkt de zichtbaarheid van geïnstalleerde applicaties via PackageManager. Deze wijzigingen maken het gebruik van URL Scheme voor interactie tussen applicaties minder betrouwbaar dan in eerdere versies van de platforms.