Marco.org

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:

• Blogging and publishing apps can accept URLs that users want to include in a post.
• Social networking, instant messaging, and Twitter apps can accept URLs that users want to share or send to friends.
• Task-management apps can accept URLs to be used for new tasks.
• Note-taking apps can accept URLs to include in notes or save as references.
• News readers can accept URLs for new feed subscriptions.
• Bookmarking apps can accept URLs to save for archival or search.
• File-management apps can accept URLs to download.

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

• Copy the URL to the pasteboard, then launch the app and either have it auto-detect or have the user Paste it in. But this is complex, especially since there’s no Copy button anywhere in Mobile Safari except the standard handling while editing the URL field, so most users won’t do this.
• Mail the link to a special email address. This works, but is tedious for users, and requires both a special email address to be installed in the user’s Contacts and a corresponding web service to receive the email and synchronize with the app on next launch.
• Use a Javascript bookmarklet to launch the app with a local URL scheme or send it to a corresponding web service.

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:

• Add a proper registry of apps that can accept URLs from Safari, recognized by an Info.plist key, and add a “Share” or “Send To” panel to Safari that allows users to easily send the current page’s URL to any capable apps.

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:

• Add a public iOS API method for apps to prompt users to add a bookmark to Mobile Safari, e.g. in UIApplication:
  - (void)addSafariBookmarkWithURL:(NSURL *)url title:(NSString *)title
• Alternately, add a Safari-handled URL scheme that apps can invoke to prompt users to add a bookmark, e.g.:
  safari:///addBookmark?url=___&title=___

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:

• Implement a Javascript method or URL scheme to prompt the user to add a bookmark with an arbitrary URL, specified in the code, like the old IE window.external.AddFavorite(url, title) method. If a web page could call such a method to bookmark an arbitrary javascript: URL, this entire process can be avoided.
• Alternately, allowing window.location.href to be set to a javascript: URL, and then having that be the logical URL added when someone taps Add Bookmark, could eliminate almost the entire complex procedure. (Today, doing this just executes the Javascript but doesn’t change the current page’s URL for bookmarking.)
• A less-desirable (but still helpful) alternative would be to make the Address field editable in the Add Bookmark sheet for new, unsaved bookmarks. Currently, it’s only editable on edits of existing bookmarks, necessitating many extra steps in this process.

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:

• rdar://8534665 (my most recent filing with this post)
• rdar://7636942
• rdar://6589436
• rdar://5935641
• A related bug that limits bookmarklet usability: the user’s text selection is lost when selecting bookmarks (thanks, Agile Tortoise)
  • rdar://8562369
  • rdar://7013257

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.