Using DNS to solve the deep linking problem
A while ago, several companies (Facebook, URX, Quixey, etc.) took on the task of solving a problem that exists in Apple and Google’s mobile ecosystems: the disconnect between URLs on the web and the URLs that exist to help apps interlink amongst each other. Despite some creative efforts, there exists no canonical way for app developers to the share the URLs which would open their apps, or for a website to know if a deep link will actually work. The result is deep links are seldom used and the user gets a bifurcated experience between the mobile web and the apps they have on their device. Unfortunately, while I applaud the above companies for the services they’ve created, they don’t own these closed ecosystems and cannot truly solve this problem in an elegant or widely used way. That leaves us with Apple and Google to come up with the solution.
How would I solve this problem if I were Apple or Google? #
DNS.
When it comes to domain names and resolving the IP addresses behind them, this problem has already been solved for almost three decades. Your OS resolves a domain by querying a DNS server and finds the IP address by looking at the A/AAAA records.
A similar mechanism could work for apps:
When the OS receives a request to open an HTTP URL (either from an app or from the browser), it does a DNS look up to get both the A/AAAA record and the TXT records matching a certain format. If the TXT record contains an App Bundle ID or Play Store package name that matches an app present on the device, it forwards the request to the app. The app can then choose to handle the request or not. If the app chooses to handle the request, that app comes into focus and handles the rest. If the app is not present on the device or chooses not to handle the URL, the user is sent to the browser. The user will never realize such a negotiation took place.
What are some potential drawbacks? #
How about security and spoofing? The same threats already exist for domains, so nothing new here.
How about if the user really wants to go to the browser or the app doesn’t support a particular URL? If the app decides whether to handle the request, it becomes trivial to add a setting causing the app to not respond to a request. The app developer could implement this behavior or it could be done at the OS level.
How about if one domain maps to many apps (Facebook Messenger, Google Maps, etc.)? Create a DNS record for a sub-domain and it can hold the records for that particular app. Just like you can have many virtual websites on one domain, you can have many apps connected to one domain.
Why couldn’t this be solved in the mean time with a redirector like Bit.ly? For security reasons a website cannot accurately determine if an app is installed on a device, so it really wouldn’t work that well. Besides: who wants a fundamental thing like hyperlinks going through a service/company? That’s why something like DNS works: nobody owns the DNS network and its neutrality makes it work for everybody.
Wouldn’t this enable developers to trick users by sending them to the wrong app? Just like a developer is not incentivized to point their domain to a server not under their control, there is no incentive for a developer to point users to an app not under their control. Anyways, the user has to have the app installed before any of this would work in the first place.
Why does this solution work for Apple and Google? #
In order for such an idea to work, neither Apple or Google give up control of their respective ecosystems to some other entity, nor do they need to create a common protocol with each other (although that would be nice). DNS-level app resolution could be implemented on either platform independently of the other and nobody would be for the worse.
Furthermore, DNS is a known entity: People understand how it works, it is already widely used (an understatement at best), and it was setup to solve this exact type of problem.
If Apple and Google went for it, HTTP URLs would then become the canonical way to call an app, just as they are the canonical way to call a website. From there on out we could all enjoy the network effects seen on the web created by hyperlinking, but inside the walled garden of mobile.