Hacker News Reader

Comment by karmelapple | Hacker News Reader

Mobile devices support extensions to some degree now, too! iOS Safari fully supports them, so that’s millions upon millions of potential users.

Unfortunately, the UI for initiating them isn’t quite as nice as the desktop, which is a big reason why we haven’t implemented our extension for iOS yet. Once Apple figures out a better install and activation workflow, then we’ll probably do it.

View on HN

For those who haven't tried, the UX for initiating an extension is something like this:

1. download extension

2. open Safari and tap on puzzle piece icon on the left side of the address bar (when visible)

3. tap the newly downloaded extension

4. when prompted, give permission for it to run

5. give permission for it to run always on the current site

6. give permission for it to run on every site

I appreciate the need to secure the user's permission. But this is a super clunky way to do it. This path is especially troublesome for users with disabilities (motor issues, working memory issues, or executive function deficits in particular). And given how much people with disabilities rely on extensions to make browsers/websites accessible, this is not a trivial impact.

I run a startup whose tools are used for accessibility reasons and we have streamlined our product and onboarding in many ways based on feedback from our users with disabilities. The process Apple uses is incredibly cumbersome, and I'm sure that many users with disabilities are lost along the way.

It’s actually a little worse than that. You download an app that has an extension bundled. Some apps are just shells for their extension. Others have extensions bundled for additional functionality. PayPal bundles Honey in their main app so that anybody who has PayPal already downloaded can just enable Honey in their Safari browser. But it doesn’t do anything unless it’s enabled.

Good point. In the case of Honey, I actually wouldn't want it to be enabled just because I downloaded the PayPal app. Most people probably aren't aware it's even there.

But in the case of the shell apps, it totally makes sense to activate the extension automatically upon installation since that was the whole point of downloading the app/extension.

I agree. I think there really should be a separate extension store.

That would also help raise awareness for the fact that there are extensions in the first place. I've talked with many tech-savvy people who had no idea these even existed. It's like Apple wanted to make it possible to do extensions, but not remotely easy. And since they realized that this hassle would generate blowback if the general public went through the activation experience, they decided to keep it under wraps. That way, the only people who learned about extensions in the first place were people who didn't mind digging around a bit. These people would be less likely to be upset/confused by the labyrinthine install process.

That’s what I’m feeling, too… perhaps did they add extensions to iOS hoping they wouldn’t be too popular right away? Perhaps so they could watch what extensions get made, how they impact user experience, battery life, etc. ?

I can attest to this. The UX is quite bad. I run a small SaaS[0] and had a hard time explaining to my users on how to enable the Safari extension. The UX to use is not as nice either.

In the end I switched to the traditional Share Extension.

[0]: https://ktool.io

Share extensions are fine, but they still require activation. Also, they can't automatically run on a page without user intervention, which is necessary for many/most traditional extensions.

Safari's extension support is great, I was keen to include that in the book. Having to develop extensions inside XCode and deploy them in the Apple App store felt a bit odd, but it's really interesting how the extension has a dedicated "app" on the phone, which allows for some interesting possibilities.

Reply on news.ycombinator.com