In this blog post we will demonstrate how to make the transition from one mobile app to another mobile app as seamless as possible. The technique we show is also applicable when migrating users from a web app to a mobile app.
One of our clients had released a simple promotional app first, but then started offering another app. Ideally, all existing users should be converted to the new app. Deep linking allowed us to make the transition look seamless to users.
A special web link triggers the installation of the new app from within the promotional app. When a user launches the new app for the first time, she is already logged in. We will show how to do this on iOS, using Firebase Dynamic Links. Our example code for the server-side implementation uses Java & Spring-Boot.
Deep Links
So-called deep links point to specific content within websites or mobile apps. They can also hand a mobile app additional parameters which it can process on launch. We use this to provide the parameters necessary for login on app launch. Firebase Dynamic Links are the tool of our choice, because they come with two important features:
- They survive app installs. The links are processed on launch, even if the app was not yet installed at the time the deep link was clicked.
- Your marketing team certainly wants to track which links lead to conversions. Dynamic Links provide them with the analytics to do that.
Note that there are other frameworks for deep linking, for example Branch. We don’t recommend implementing deep linking by hand: as soon as you need more than the very basics, the required effort is likely not going to be worth it.
Creating Dynamic Links
Our promotional app requests a dynamic link from the server, which then can be used to install the new app, and to automatically login users on first launch. The dynamic link will point to the iOS App Store, or the Play store, depending on the platform from which the link was requested. Dynamic Links look like this: https://smv42.app.goo.gl/9RQ9XlXtX685OXAg1.
Creating Dynamic Links on the Server
On the server, we create a dynamic link by making a request to the Firebase REST API. Note that we use code from MobileESP to detect the platform from which a request is made, which in turn uses the UserAgent HTTP header.
If there is no authenticated customer, only a link to the store will be returned to clients:
If the customer is authenticated, a DynamicLinkInfo object is created first. It contains all information needed to generate the links for the respective app store. We also add the one-time token which is needed for our auto-login here.
Clients will only receive the link. All necessary data about the customer, as well as the one-time token which will be used for automatic login, can be extracted from it.
Requesting Dynamic Links from iOS
Both apps communicate with our server via REST APIs. We pass the current user’s id, and the server adds a one-time login token. The token is only valid for a limited duration, to reduce the chance of it being leaked and abused. The function looks like this:
Upon receiving the link from the server, we open it in the mobile Safari browser. Safari then redirects users to the App Store, where the app can be downloaded.
Reading Dynamic Links
To read the content of dynamic links, we need to include the Firebase Dynamic Links SDK. Instructions for adding and configuring the SDK can be found here. Once the new app is installed and launched for the first time, application:openURL:options: in AppDelegate will be called.
We extract the user id from the url property, and the one-time token that was added by the server.
Finally, we make a call to our server with the parameters we extracted in order to login the user automatically.
Conclusion
Auto-login can be implemented easily via Dynamic Links. This feature is a great way to convert more users from your web app to your mobile app, or to convert users from one mobile app to another.
Beyond this use case deep linking is helpful in many situations, especially when one has both a website and a mobile app, or several apps which have the same users.
