Universal Links Logo

URL Schemes – The Basics

This entry is part 2 of 12 in the series Universal Links

Before we move on to Universal Links, we’ll begin with setting up classic URL Schemes (Deep Links). These are fairly simple, and use most of the same hooks as Universal Links.

If you already know all this, feel free to skip to the next part.

What is A “URL Scheme”?

DISCLAIMER: This is a VERY simplified explanation! If you want the real skinny, check the WC3 site.

URLs (or URIs) are designed to have several parts:

service :[/[/]] host [/[ path ]][?[ query ]]

Service

The Service component is the part we’ll be dealing with for URL Schemes. It tells the software what kind of communication protocol (and maybe data format) to expect, when connecting to the resource.

The most familiar service is “http[s]”, which means basic HTTP Web data.

There are a couple of other familiar services, such as “mailto”, or “tel” (Mail Protocol, and Telephone Number, respectively).

This is case-insensitive, and required.

Host

This is the actual resource address, in either a DNS lookup form (the most familiar type), or a straight-up IP address (127.0.0.1, for example). We’ll be dealing with this part, for Universal Links.

This is case-insensitive, and required (but not if we are using URL Schemes).

Path

This is the internal path from the main connection point, to the resource location, inside the resource host.

Path components are separated by forward-slash (“/“) characters.

This may be case-sensitive (depends on the implementation of the resource host). It may also be omitted, if the host directly points to the resource.

Query

This is any “parameters” that are being sent to the resource.

Again, this may be case-sensitive (depends on the implementation of the resource host). This may be omitted, if there are no parameters.

Where We Fit

The “URL Scheme” is a customized Service for the URL.

You can pretty much use any string that you want, but it should be short, and not collide with any well-known schemes. Apple has a set of schemes that they use, internally. You shouldn’t use any of these. Additionally, many popular apps have URL Schemes, and you shouldn’t pick anything that collides with them. That said, finding URL Schemes for apps is not always straightforward. Most apps publish their URL Scheme, but not all. I often need to find them in obscure blogs or wikis.

It is possible to find out the URL Schemes of apps that you have installed on your phone. It’s not exactly straightforward, but you may not have a choice. Here’s a fairly good blog post about how to get the URL Schemes of an app. It’s a bit “dated,” but the technique still works fine, using the latest iMazing app (3.0), and the operating systems that are current at the time of this posting (iOS17.5, and MacOS14.5).

Pick A Scheme

Once we’re ready to start, we should pick a scheme. For this lesson, I have picked three schemes: one for each of the app variants:

  • "iul1" This is for the classic App Delegate app.
  • "iul2" This is for the Scene Delegate app.
  • "iul3" This is for the SwiftUI app.

These shouldn’t collide with any other apps, and will transition well, to Universal Links (as we’ll see, later).

Deep Links from these schemes will look like this:

  • "iul1://?stop"
  • "iul2://?caution"
  • "iul3://?go"

etc.

Once we have the schemes in place, you’ll be able to open these links on your phone, and it will ask if you want to open the app, then open the app, and set the “traffic lights” to the appropriate value.

If you try it now, the phone will yell at you for giving it a bad URL.

Nothing to Do On the Web Server

Right now, all the action is happening on-device. If the app is installed, it will be opened. If it is not, nothing will happen, except that you’ll be yelled at by the phone, for a bad URL.

We don’t care about the Web server.

Before we get started, let’s explore this a little further.