How iOS 9's Safari View Controller could completely change your app’s onboarding experience.
Getting somebody successfully onboarded into your app is fraught with pitfalls and hiccups which prevent them from becoming a regular user. Here’s a potential solution for it.
Hey, I’m Rizwan Sattar! I’m working on LaunchKit, a set of tools to help mobile makers launch apps, and Cluster, an app for sharing to small groups.
In March 2008, I was lucky to be invited by Apple to check out the unreleased iPhone SDK, and it changed my career. I’ve been working on iOS projects ever since.
Every social app out there relies on some form of invitation to get people to become new users. It usually involves an email or SMS sent to prospective new users, enticing them to sign up.
On the web, or where people are using computers, this generally is considered a Solved Problem™. The user clicks a link with a special, unique code in it, instantly identifying them on the webpage, allowing the site to tailor the onboarding experience for the new person.
In an iOS app, there are 2 additional complications:
- The invited user must download an app.
- The app has no idea who the user is, or where they came from.
This means that even the best invitation flow looks like this:
- User receives an email from someone to be friends in a new iOS app.
- User clicks on a special link in the email, which opens a webpage in Mobile Safari.
- Knowing who the recipient was, the web app eases the signup process by pre-filling data.
- User signs up at the site, and decides to download the iOS app.
- When she starts the iOS app, she’s unexpectedly presented with a sign-up or login screen.
Before iOS 9, there’s no way for your app to know anything about who the user is, or even that the user visited the company’s website and signed up for an account.
At this point, you would think the user would intuitively just log in to the app using the same credentials she used on the site. However, you are not your users, and many things can go wrong:
- Some get frustrated, feeling like they just did this (which they did).
- Some others people will mistakenly try to sign up again.
- There’s even some that will sign up with a different email address than the one they were invited with, which complicates private sharing apps.
- They have forgotten their password or even email address they used to sign in with (see 2nd bullet)
Luckily, Apple has been listening and watching how native apps have been struggling to transition a user from the web to an app and have offered a few solutions over the years, but they’re not so great, as you’ll see.
I’m going to show you how iOS 9's Safari View Controllers might make this way easier, but first let’s take a look at what the current tools by Apple are:
Smart App Banner
The first not-so-great solution by Apple is Smart App Banners. When your user is viewing your site in Mobile Safari, a banner can display across the top that lets you open this page within the app. With this, a trick can be to include some sort of auth token within the url, so when the app receives the url, it can perform a behind-the-scenes sign in.
However, this only works if the app is already installed, which a new user is not likely to have. If the app is not installed initially, the smart app banner shows an “Install” link, which takes you to the App Store. After installing the app, the user would have to know to return to the website, then press “Open” in the app banner in order to sign in. This makes the Smart App Banner not a realistic helper in the onboarding process.
I can’t completely discredit Apple here though, because I don’t think they were designed to help this onboarding problem.
Shared Web Credentials
The next not-optimal solution that Apple came up with is Shared Web Credentials. Essentially, if you save your passwords to iCloud Keychain (which you generally turn on at setup), then the app can access the passwords.
You can create a special apple-app-site-association file to the root of your website, and it will whitelist any apps which can access any saved passwords that the user may have stored while signing in on the web.
In the native app, it can query the shared web credentials and get access to the email and password and sign you in.
However, in my opinion, this is not been a great solution: a) iCloud Keychain needs to be enabled, b) your site needs to have some of a password login, and c) the user must agree to save their password to iCloud Keychain before running your iOS app.
Introducing Safari View Controller
At WWDC 2015, Apple introduced Safari View Controller as a way for developers not to have to create mini-browsers of their own, to show small bits of web content inside their own apps. (Like what happens when you tap a link in the Twitter app: Rather than go to Mobile Safari, Twitter will open its own browser window for you to view the content).
Safari View Controller is a pre-built browser that has all the bells and whistles of Mobile Safari, but can be presented without leaving your app.
Ricky Mondello, a Safari and WebKit engineer at Apple, says (emphasis mine):
And with Safari in the name, Safari View Controller brings features that your users already love from Safari, but now they’re in your app.
Let’s start off, first and foremost Safari View Controller shares cookies with Safari and other website data.
So what this means is if one of your users is already logged into a website in Safari, if they tap a link in your app and Safari View Controller comes up they might still be logged in.
But there’s something else nobody has been focusing on: In addition to third-party services being logged in, you can also see if YOUR users are logged into your web app already, so you can seamlessly sign them into your iOS app!
A Real-World Example
For the last couple of years, I’ve worked on Cluster, an app for sharing photos and videos with small groups of people. Think Instagram mixed with privacy and multiple feeds.
One of the biggest challenges for Cluster (and any app where content is shared to specific people only) is how to invite someone easily, and have them identify themselves to Cluster the same way they were invited (i.e. they use the same email address to sign-up with, that they were invited with).
For the longest time our solution has been:
- When the user receives an email or sms invite, they click a link, which takes them to Mobile Safari and gets them to sign up on the web.
- Then we encourage them to download the iOS app and use that instead (Cluster is primarily heavy media sharing, so works better in a native app)
- Hope/cross fingers/pray that they sign in with the same account they just created.
For the most part, it works ok, but we still have people accidentally making new accounts with different email addresses, simply because they forgot what email address they had originally used. Then, they wonder why none of their private groups are showing up. To them it is as if Cluster completely “lost” their data.
One workaround to this has been to somehow talk to our webpage, and maybe find out who the user is. We used a “Safari Bounce” technique where, from our app, we open a special URL on our site asking for a auto-login token. The server then checks the browser cookies to identify the user, generates a one-time token to sign in, and bounces back to our iOS app with the token in the URL.
Improving the “Safari Bounce”
Since Safari View Controller shares cookies with Mobile Safari, launching it within our own app should at least let us do do the “Safari Bounce”, but much faster:
Rather than opening a URL in Mobile Safari, you simply create an SFSafariViewController instance, give it the URL, and present it modally.
The mechanics are the same as launching Mobile Safari; the webpage is still redirecting back to our app using an URL scheme*, even though it looks like it was communicating directly with our app.
This already feels better. Apple even wants you to use Safari View Controller for OAuth in this way! The transition to opening the webpage feels smoother, and is generally a faster experience.
Still, there’s a lot happening on-screen, and it feels slightly janky. Could we do even better?
Hidden Safari View Controller
What if we briefly launched a SFSafariViewController instance hidden and without animation?
It turns out, it totally works.
In the past I always worried about building a seamless first-time experience for our users. None of the “magic” solutions felt elegant.
Using a hidden Safari View Controller to help identify your user removes user confusion and makes your app feel magical when users use it for the first time.
What Is Now Possible
With Safari View Controller, we now will have a way to “talk” to our webpage and learn a little bit about who the user is, and what they were doing, so we can do all of the following:
- If the user already is logged into the website, you can seamlessly sign them in, without prompting them to check their Shared Web Credentials. This is still secure, since the website would have to have an API built that would do the redirect back to the app for you.
- If they are not logged in, tailor the onboarding experience for that specific user linked via the special code in the original URL that was tapped. (e.g. “Hi Samantha! Here are some of Jack’s photos he has invited you to see!”)
- Or, if you want to get fancy, you can even change the “intro” UI to be based on which kind of marketing the user came in from. People who use Cluster come from all kinds of backgrounds: College kids, new moms, grandparents, travelers. So being able to modify the intro UI for a particular kind of person might be very helpful!
Thanks for reading! If you enjoyed this article, I would really appreciate you hitting the recommend button below. Connect with me on Twitter @rizzledizzle with any comments or thoughts.
Special thanks to Taylor Hughes (@taylorhughes), Brenden Mulligan (@mulligan), Felix Krause (@krausefx), and Sam Soffes (@soffes) for looking over this post to ensure I’m not a crazy person.
