The absolute simplest way to get the Instapaper "Read Later" bookmark into Mobile Safari is to add it to Safari on your desktop and then have iTunes sync your bookmarks across to your iOS device.

I was suggesting the same thing. This is the way I have automagically found the "Read Later" bookmarklet on my iOS devices.

"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"

I disagree that this is the best way to solve the problem: it would restrict availability of integration with Safari to native apps, leaving pure web-hosted apps at a disadvantage. Why should every web-hosted app that handles URLs have to produce an iPhone app just to lower the user-experience hurdle? And bear in mind that the app won't have access to cookies set in Safari, so the user will need to authenticate themselves twice - once in Safari, once in the app.

I think the best solution would be one completely within Safari - window.external.AddFavorite or something similar.

> I think the best solution would be one completely within Safari - window.external.AddFavorite or something similar.

But then, what of native applications? And what if you actually just want to send a URL to an other native application? Also, AddFavorite (terrific casing from the MSIE team here) with arbitrary JS?

Also, if the registry/send to method works with offline web applications, then there is no restriction, the site "just" need to bundle a small offline webapp able to handle the information (not sure if there is any specified way for the OS/shell to send data to offline web applications though)

They can improve their current procedure by using this technique: http://joemaller.com/___

1. Append bookmarklet as suffix to a short URL 2. Tell user to visit that page and bookmark that URL 3. Instruct user to edit that bookmark and delete the prefix of that URL

This removes the step of asking user to copy the URL from a textbox. Plus, if the user misses the step of removing the prefix portion of the URL, clicking that bookmark will direct them to the instruction page.

But yeah, the process still stinks.

Two other solutions:

1. Support Safari extensions in Mobile Safari. Users install it from the gallery, get a nice little icon to tap in the toolbar.

2. Support an HTML tag in the head, like web browsers do to detect feeds today. Something like <link rel="bookmarklet href="javascript:location.href...">. The browser would detect this, display some sort of notification icon in the address bar, and give the user the option to install it upon tap.

This is the type of thing that concerned me about Mobile Safari and Flash. It's not that I care so much about Flash being on the iPhone/iPad (it'd be nice if it could work well though), it's that they're preventing all browser plugins and extensions. HTML5 is great, but standards tend to become standards by adopting the innovative third-party addons. Mobile Safari seems far too locked down at this point.

Same goes for the iPad's Mail App. I'd love to use it, but until I can add my own Archive button (I use MailActOn with OS X), it's far too tedious for managing my inbox (just use it for skimming).

4.2 in November should include an "Archive" button for Gmail accounts.

That's great news. Any idea if it'll work for IMAP/Exchange accounts that have an Archive folder? For Gmail, I just use the web iPad interface (which, in my opinion, is nicer than the Mail app).

"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."

This is what Android has been doing for a while. When I switched from the iPhone to Android I realised how much this sort of message passing between apps can improve the productivity of the device.

> When I switched from the iPhone to Android I realised how much this sort of message passing between apps can improve the productivity of the device.

iPhone has always[0] supported message passing between apps, based on URI schemes.

What it doesn't support is Safari sending URLs to third-party applications registered against the `http` scheme (a `redispatch` feature, basically).

[0] Or for a very long time anyway, but I think it's been there since the release of the original SDK.

After I read this, I submitted a new enhancement request to Apple citing my reasons for needing this feature and pointing them to Marco's blog post for specific examples. Please do the same if you need this feature!

How would dishonest people exploit Marco's proposed solution?

Well Marco proposed a lot of solutions so:

# 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.

Not exploitable as far as I can see, this is a mecanism which already exists through the scheme-based dispatch iOS already has (and uses). Safari would simply be extended to dispatch to third-party applications registered against the `http` scheme. Worst thing that can happen is boatloads of applications claiming to handle `http` making for a piss-poor user experience.

As far as I'm concerned this would be the best solution by far (for that issue): it only requires pretty minor changes (technically speaking, the UI/UX issues are bigger), uses existing and well-understood mechanisms, and only touches Safari.

# Add a public iOS API method for apps to prompt users to add a bookmark to Mobile Safari [or] add a Safari-handled URL scheme that apps can invoke to prompt users to add a bookmark

Would be OS-protected APIs, probably with some kind of warnings. Of course users don't read warnings, but the exploitability level would still be pretty low. This is also in-app, with mostly trusted stuff.

# 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.

Not exploitable, simply avoids wasting time but clutters the UI.

# 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

Small privacy issue: because the user has no way to know whether what was bookmarked was a regular URL or a bookmarklet, it can be any arbitrary bookmarklet at any time and let the originally bookmarked site know what the active page was when it got activated.

# window.external.AddFavorite(url, title)

From reading on the API, it seems fairly well protected (only accepts http, https or ftp schemes, title is cleaned up thoroughly before registration) and it prompts for addition instead of adding straight. I don't really see how you could exploit that, on the other hand in that state it's useless for Marco's purposes (can't set javascript:) and it lets you spam the user with infinite requests for favs. Annoying but not downright dangerous.

Did I miss anything?