I'm surprised we would want HTTP URLs for this. Especially since, as this article is written, no HTTP requests are ever being made.
Why not have an ios:// (or android://) prefixed URL, and have whatever follows that determine the app? If you passed along the rest of the path, you could specify logical resources to link to.
Already possible on Android (and I believe iOS), but rather an application can register its own URL scheme. (For instance, Twitter can set up twitter://)
The problem there is you can't have a single URL that just goes to the web page if there's no app installed. That's what the author is trying to solve.
Android has a solution where an app can handle all links to a certain domain. (The OS asks you if you want to use the browser or the app, and you can set it to always use the app if you like.)
Ok, now I see the problem the author is trying to solve. Thanks for clearing that up.
I think from an HTTP perspective, the right way to solve this is to use vendor specific content types and have the OS resolve whether to open it in an app or not.
So when a link is clicked on in a browser, you use the request's Accept header to indicate which apps are installed on the device (and have registered a custom content-type). The server then can respond with a custom content type and let the OS dispatch the response to the appropriate app.
For app to app links, the OS could just perform an HTTP HEAD to see which app to dispatch to.
What happens as that ecosystem grows, though? There's Windows phones, Blackberry, and others. The solution would have to be either universal (like app://) or implemented by the OS/applications themselves (like Android Intents).
Why not have an ios:// (or android://) prefixed URL, and have whatever follows that determine the app? If you passed along the rest of the path, you could specify logical resources to link to.