Let’s take a closer look at what is actually happening, when we implement a URL Scheme in our app.
What is A “Service”?
Remember that the URL Scheme is a custom Service; the first part of a URL, that tells the system what application/tool is necessary to execute the connection. It’s what’s referred to as the Application Layer of the TCP/IP protocol (the network stack everyone uses, these days).
The ironic thing, here, is that we don’t actually use a network connection at all. It just looks like one. If we declare a custom URL Scheme, the system just directly launches our app, without doing any network calls.
What the System Cares About
The only part of this whole transaction that interests the system, is the Service (prefix) portion of the URL. All the rest of the URL is ignored by the system, and is passed to your app, once it is launched or foregrounded.
The system gets the Service, by examining your app, when it is installed (or updated). At that time, the system scans the app package for the Info.plist file. If it finds a CFBundleURLTypes dictionary, it parses that, and extracts the app’s URL Scheme (You can specify more than one Service, but why?).
It then stores that Service key into an internal hash/lookup table, that matches the Service to your app. Subsequently, if the system receives a DNS lookup request for a URL that specifies that Service, it starts the app (as opposed to doing a name lookup), and hands the app the URL, once it’s running. If the app is removed, the hash is also removed. If the app installs an update that does not include the scheme, it will also be removed from the hash table.
The app is then responsible for parsing the URL, and determining what to do with the information. The system is done with the URL.
This is why you get an error, if you try executing the URL without the app being present. The system looks in its app/Scheme lookup table, fails to find it, then tries to do a DNS lookup, but, since it has no idea what the Service is, it just gives up, right away.
Conclusion
So, the system scans the app, when it is installed or updated, and saves the URL Scheme in an internal hash table. Upon getting a reference to a URL that has a URL Scheme, it looks for that Service in its hash table. If it finds it, it completely avoids doing any network activity, and, instead, starts/foregrounds the app, and hands it the URL. The app is then responsible for figuring out what to do with it.
If the app is not installed, its Scheme is not available in the hash table, so the system then treats the URL as a network call. Since it has an unknown Service prefix, the call fails.
You can see why this is quite secure. If the app is not available, nothing leaves the device, and the URL resolution just fails. If the app is available, it is simply started, and the URL is handed to it as a simple string; to be parsed and examined at the app’s discretion.
Now that we understand the basics, let’s get started with some implementation.