If you’ve been following along on my blog posts or interacting with me on Twitter, you’ll know that I’m fascinated by the idea of building a web of apps on every device. This is especially true on app centric mobile and tablet devices. But the idea also applies to browser-centric desktops because, sometimes, an app is the way to go.
The very first, and possibly the defining characteristic of the web is it’s interconnectedness. The ability for a web site to link to another one seamlessly. The irony is that an app can just as easily link to a web site hundreds (possibly thousands) of miles away. But when it comes to linking to other apps on the SAME device, well, that just happens a lot less often.
Fortunately, custom schemes or custom protocols are a great way for apps to connect to each other on-device. In fact, there’s sizable industry momentum building around the idea of using custom schemes to deep link between apps. There are at least three initiatives that I’m very interested in and have been following closely in this area:
- Facebook’s App Links (http://applinks.org)
- Google’s App Indexing (https://developers.google.com/app-indexing/)
- Bing’s App Link program (http://www.bing.com/dev/en-us/applink)
All three have interesting facets of their own but the idea is simple: take an http link (such as http://spotify.com/artist/Beyonce) and provide a way to transform it into a custom scheme link (Spotify://artist/Beyonce).
Custom schemes aren’t new. They’ve been around since at least 1996 when the Internet Explorer team (yes, that Internet Explorer!) first debuted them at Microsoft’s Professional Developer Conference. Other notables at that conference? A keynote by Douglas Adams, a session by Steve Jobs and our very own Andrew Clinick (@andrewclinick) as an attendee. Andrew also happens to be my source for this info! Basically, the idea is that an app signs up for a custom scheme and then other apps can launch it with a URI that uses the custom scheme. The wonderful thing is that custom schemes works on Windows, Android and iOS. Of course the APIs are different on every platform. If you’re interested in how custom schemes work on iOS, start here. Here’s how they work on Android. A detailed walkthrough that shows how to handle custom schemes in a Windows app lives here.
Okay, that’s great. You defined a custom scheme that can be used to deep link into your app. You’ve also decorated your http pages with the right metadata so other apps can find your custom scheme. Pretty soon, you’ll discover a problem that is unique to custom schemes. There is no authoritative way to take ownership of a custom scheme! Say you went with myawesomeapp: and you’ve got apps in the Android, Windows and iOS stores. That does not prevent someone else from coming along and using the same scheme. Unlike the World Wide Web, there is no central authority that polices and mandates that these schemes be unique. You can use strategies like reverse domain naming which is recommended by the Internet Engineering Task Force. But that still doesn’t prevent a malicious app from engaging in this behavior.
So, what ends up happening is that an app attempts to deep link into your app and the user might end up in a place neither you nor the calling app expected. I call this the Evil Twin problem. How do you prevent your friends directing a user to your evil twin instead of you on Windows? Well I’m glad you asked!
First things first, here’s how an app deep links into another app on Windows:
var options = new LauncherOptions();
options.TargetApplicationPackageFamilyName = “24919ArunjeetSingh.Build2014PhotoBlog_5gh9hndrtk5nw”;
await Launcher.LaunchUriAsync(new Uri(“com.aruntalkstech.tumbleme:?Oh=Yes”), options);
We add LauncherOptions when calling the LaunchUriAsync API. The new launcher option we are using is called TargetApplicationPackageFamilyName. A Package Family Name is simply an identifier that uniquely identifies a Windows app. The assumption here is that at some point, the owner of the app we want to deep link into (the app that signed up for com.aruntalkstech.tumbleme://) gave us their package family name. Now it is important to note that every Modern windows app has a package family name. The simplest way to obtain the package family name for your app is to call the Windows.ApplicationModel.Package.Current.Id.FamilyName API within the app. This works for Silverlight 8.1 apps, Windows Phone 8.1 apps, Windows 8.x apps and of course Windows 10 apps.
Where does the Package Family Name come from? Lets analyze the one above: 24919ArunjeetSingh.Build2014PhotoBlog_5gh9hndrtk5nw. The part before the underscore is a generated name the Windows developer center gave me when I reserved a name for my app. So this part is unique to my app within the Windows store. It is also what is known as the Package Identity Name. The second part is a hash of the certificate used to sign my app. Remember, your users will either obtain your app from the Windows store or by way of an enterprise deployment. Either way, it will be signed using a certificate issued to you for app signing. So unless you manage to compromise that certificate, you can be sure that another app can’t steal your package family name.
Well there you have it! A detailed (too detailed?) discussion of the Evil Twin problem and the way we’re hoping to solve it with Windows 10. If you have feedback or questions, please leave a comment or tweet me @aruntalkstech. The code above came from https://github.com/arunjeetsingh/ContractsAndPickers. This repository has the app we’re trying to deep link into as well as the Launcher code shown above. Finally, the app we’re trying to launch has already been published to the Windows Phone store and lives here: http://www.windowsphone.com/en-us/store/app/build-2014-photo-blog/7a5612c4-1a7f-4e7e-806a-06f0970d854a. Happy hacking! 🙂