At WWDC this year, Apple announced something that got a LOT of people excited: with iOS 15 and iPadOS 15, mobile Safari extensions would be available. For many years, extensions for desktop browsers have brought a ton of value to users.
Some of the most popular extensions add features to an otherwise boring, basic web browser, like:
Extensions have been around on desktop for all the major browsers but they have been missing in the two most popular mobile browsers: Safari and Chrome.
Apple's announcement changed that, and it's a huge, bold step for them, especially since Apple's focus on privacy and security may be seen as contrary to the reputation some extensions have gained. But Apple's thorough review process and some clear ground rules allow them to maintain a promise to the user that no nefarious extensions will be available.
Apple made some user-experience (UX) decisions with mobile Safari extensions that mean users may struggle to use them. The biggest challenge lives in onboarding or opting-in to the extension in mobile Safari.
In 2015, Apple added a feature called "Share Extensions" that allowed an app developer to offer a branded Share option to Safari. For example, Evernote iOS users could add an Evernote option to the Share Sheet in Safari. If a user was on an article website in Safari, and they wanted to "clip" the article, they could open the Share Sheet and select the Evernote icon and this would "send" the webpage to the Evernote app.
It was a neat feature, but the trouble is, the user didn't get the Evernote share option in Safari when they installed/updated the Evernote app. The user had to jump through a lot of steps, starting in Safari, to enable this option. There was no path from the Evernote app to enable the feature.
This led to Evernote (or any other app that wanted to help their users to turn on the feature) to build a goofy web page, loaded in Safari, that guided the user through the steps of enabling the Share Sheet feature for Evernote.
Share Extensions have about three steps to activate:
Despite only three steps to enable this feature, most users probably have no idea that they can do this because it's pretty hidden.
Back to the new and exciting mobile Safari extensions. The user experience problem here is mostly apparent if you want to activate a mobile browser extension that you'll use on every website in Safari, like a coupon checker, a cash back alert app, or even Apple's example "Fish Translator," that replaces mentions of the word "fish" with a fish emoji.
For the screenshot examples below, we'll be showing an extension named "Fish" to keep this generic, but assume we're talking about any extension whose value to the user is to do something automatically on all webpages, to save them time, money, etc...
In the case of installing a new mobile Safari extension, the user has to not only opt in to the given Safari extension, but they then need to make multiple choices about where they want to allow the extension to run.
Step 1: The user has to select the font size icon in the address bar (that's the address bar at the bottom of the screen in iOS 15).
Step 2: The user has to tap the Manage Extensions option in a long menu of disparate things.
Steps 3 and 4: After tapping the Extensions menu item, the user sees a list of all available extensions, enabled or not.
They then tap (step 3) to toggle the new extension to On, and tap Done (step 4).
The extension is now "enabled." But we're not quite done yet. The new mobile Safari extension is now merely visible in the menu as a new option, but the user now has to remember that it's there and tap it anytime they want to use it.
This is fine for some use cases like Evernote's web clipping or Todoist's "turn this web page into a todo item," but what about Rakuten's or Acorns' use case that applies cash-back when shopping online? These use cases all require the extension to do work on behalf of the user automatically. For any "do work for me" use cases, there are more steps for the user to take before they're done with set up.
Steps 5 and 6: The user now has to tap (step 5) the new menu item with the orange warning sign...
...and make a choice (step 6):
Do I want to allow this extension "for one day" or "always?" This is a difficult choice because the user doesn't have much context here because they're just trying to set up the extension for later use. They probably don't want to use it on the site they're on now, they're simply trying to complete onboarding so that things "just work" later on when they go shopping (or when they want every web page with the word "fish" on it to show an emoji of a fish).
Step 7: After making that choice, they have to make another choice: do they want this to run on every website or just this website?
For the use case of "automatically save me money" or "automatically change the text 'fish' into a fish emoji" the right answer is "Always Allow on Every Website." But an average user may not understand this and answer correctly.
It's installed! The mobile Safari extension is installed and activated. Now the user will have their automatic whatever done for them automatically on any web page they visit in Safari.
Many apps making use of these new mobile Safari extensions in iOS 15 will announce their new features inside their apps. These Safari extensions are "bundled" with a host, native, iOS app, they aren't distributed separately. There's no App Store for Safari extensions like there is with Google Chrome extensions.
So, the user will update the Fish app on their phone (or more likely it'll auto-update in the background), the user will launch it for the first time since the update, and the app will pitch to the user this new, amazing feature. The user should be able to see this pitch, decide whether they're interested and accept it or not, all from within the native app.
But that's not currently possible.
Instead, the user has to get the pitch inside the app, but then jump over to Safari and make it through the 7-step installation described above. If the user gets stuck somewhere in the middle, they may think to jump back to the app, but the app has no way to know where the user is in the process or to help them in any way.
Sure, the app can provide instructions describing the process of opting-in to all these things, and they can even load those instructions on a webpage for the user so they can see it in Safari, but all these steps are actually modals that are now covering that web page, so the user can't see the instructions.
And if the user selects "Allow for One Day" in Step 6 above, the native app and the mobile Safari extension have no way to know that the user selected that and that tomorrow the whole experience will break for them- no more automatic saving while shopping and 🐟 all disappear!
If a user forgets what settings they chose and wants to look at them, or if they want to change those settings in the future (for example, to allow the extension to run on only some websites), they probably will think to look under the app settings for the associated app. But these settings all live under a completely separate extension setting underneath Safari.
To get there from System Settings, the user has to tap through the following 5 steps:
And there's currently no way for the native app to deep link the user to that settings location. So, if a user does want to look at/change these settings, and they start in the native Fish app, that app can't help them get there. Apple has long forbidden native apps from deep linking to Settings, even though there are lots of reasonable examples of where doing so can provide a very helpful service to the user.
Safari extensions for mobile (available with iOS 15 and iPadOS 15) are amazing and powerful and sure to add very novel, valuable features that make phones and tablets even more useful for the average user. It's an absolute coup that Apple got to mobile extensions for Safari before Google has offered mobile extensions for Chrome.
This release with iOS 15 is only the first version of mobile Safari extensions and Apple has a chance to really improve these workflows to make them easier for the user in future versions. We think Apple also likely hadn't considered all the use cases that require these long onboarding flows (things like coupon checkers and cash-back services).
We believe Apple could reduce the choices pushed on the user for these permissions and avoid the "permission fatigue" that causes users to make bad decisions or worse, avoid making decisions at all.
If the following things are true...
...then what is the risk of letting the user easily opt-in to that app's mobile Safari extension?
Safari desktop extensions, by contrast, let the user opt-in to a Safari extension with a single step. It also makes the user aware in Safari that there's a newly installed extension. Desktop onboarding in Safari extensions is hands-down easier for the user. We hope Apple would provide a consistent (and much easier) experience for the user by using the same experience on mobile.
When Google eventually offers Chrome extensions for mobile, we expect them to use the same conventions that they established on desktop and not invent a novel opt-in experience for mobile. On Chrome desktop, users install an extension and that implicitly grants permission for it to run on any website until the user uninstalls the extension. Over the past few years, Google has added review processes that mostly match Apple's reviews, which removed the bad actors from the Chrome Web Store and that has been enough to keep the install process simple while also creating a secure, trusted environment.
With a simpler extensions onboarding flow, Apple has a chance to keep more users in the Safari experience as their default browser, especially while Chrome doesn't offer an extensions experience on mobile.