Marco.org • About ▾

I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

An open enhancement request to the Mobile Safari team for sane bookmarklet installation or alternatives

My iOS app, Instapaper, relies on the installation of a Javascript bookmarklet to be effective, because it needs a way for users to easily send URLs from Mobile Safari to Instapaper.

Many other iOS apps have similar needs:

There are only three ways to send URLs from Mobile Safari to apps today:

Instapaper supports all three, but very few people use the first two. Customers prefer the workflow that the bookmarklet offers.

Most Instapaper customers install the bookmarklet directly in Mobile Safari. The process of doing this is extremely complex and user-hostile, and a large percentage of them abandon the process and are extremely dissatisfied with Safari, my app, and me as a result. I get emails like this almost every day:


(And this was one of the nicer ones.)

The current procedure:

  1. Send the user to a placeholder web page, with the Javascript code in a textarea. The user must Select All of the text in it and Copy it.
  2. The user must Add Bookmark for that page, then tap Done.
  3. The user must then open their Bookmarks, locate the newly created placeholder bookmark, tap Edit, and tap the bookmark (but not in the “delete” or “move” accessory areas) to select it for editing.
  4. The user must tap the Address line (which is not labeled as such when it is populated), tap the X “clear-contents” accessory, tap again in the Address line to invoke the pasteboard menu, then tap Paste.
  5. The user must tap Done to dismiss the editing sheet, then tap Done again to leave the Bookmarks editing mode, and then tap Done a third time to dismiss the Bookmarks sheet.

Needless to say, this is extremely error-prone and tedious, and even skilled users often miss a step.

Proposed solutions that make bookmarklets unnecessary

The best way to solve this problem is to eliminate the need for hacky bookmarklets entirely:

But I recognize that such a system would require major changes and is unlikely to ever be high-profile enough to be implemented in iOS. Other potential solutions would still be incredibly helpful:

In both cases, the user would be prompted by the OS and given an opportunity to decline.

These require changes to the public iOS APIs, so I recognize that they’re still less likely to be implemented than simpler fixes. So here are some alternatives that I assume are even simpler and therefore more likely to be implemented:

Proposed solutions, still using bookmarklets

Installing bookmarklets could be dramatically improved with any of these simple changes:

Again, any of these would be a huge help.

Developers: We need your help

Apple prioritizes API changes and new features in part by how many developers have filed bug reports requesting them. It’s an unofficial voting channel for SDK changes.

If any of these changes could benefit your apps, please file your own bugs asking for them. You can do that here. Copy sections of my text if you want to, or write your own.

Thank you for casting your vote for Apple to make this a priority for a future release.

Apple: Thank you

Thank you to anyone at Apple who has read this, regardless of whether you’re on the team that can implement any of these proposals.

Relevant reports so far:

Whenever I’ve brought this up in the labs at WWDC, every Apple employee recognizes how terrible the status quo is, but I still haven’t managed to campaign enough or to the right people to get it done.

I’ve been told repeatedly by Apple employees to keep filing bugs, even if they duplicate bugs that I’ve filed in the past. So I’m going to keep bringing this up and campaigning in the WWDC labs every year until it’s improved.

Thank you for your time and consideration.

Ads via The Deck