Apps have URLs also - even iOS, which is the weakest link in terms of inter-app interaction, has them.
The difference here is that one platform requires shoehorning a URL into a non-document-centric use case, and the other one leaves it optional, for the developer to implement as he/she sees fit.
If I'm using the Yelp app, I expect to be able to communicate a restaurant listing to someone else via a URL. But why is it that my alarm clock needs a URL? Or my phone dialer?
The web was envisioned as interlinked documents, and for many parts of the web this is still very much the case (see: Amazon). For others this metaphor breaks down badly, and is the source of a great deal if hacks and kludges.
A lot of programs already use URIs - I know KDE dolphin specifies all resource paths as URLs regardless of if they are local or remote, and it supports a buttload of URI schema. The qt5 QML engine specifies qml files to load by URI, so you can load remote qml applications in a browser that links in the qml runtime.
I mean, we even have this nice syntax (that isn't pervasive or transparent) to supply arguments in a url with something like google.com/search?q=bacon which in bash-world would be google --query bacon or google -q=bacon.
So what is missing from URLs from being uniform resource locators?
Holy God would you look at that URL. It doesn't refer to a resource. In fact it refers to application state. This is a gross abuse of the whole concept of a URL, but the folks at Google aren't idiots - they know this. But the fact of the matter is that Google Maps is not document-based, and people have legitimate need to transport application state, independent of the semantics of the information they're looking for. Even something as simple as showing my friend the same map I'm looking at so we can talk about it requires bending the role of URIs wildly out of shape.
One can argue that the previous link was clearly a reference to the airport, and there can be a URI for it (which wouldn't transport application state, substantially hobbling its use, but whatever). This link refers to "restaurants around Times Square", which isn't a logical entity, and whose relevance to the end user depends entirely on the application state being transported (e.g., zoom level, center point, filtered results, etc).
Every time these insane-o URLs get brought up the URI-acolytes seem to end up suggesting that maybe we shouldn't have rich, interactive maps or such things, that we should force software into roles that play nicely with the document-centric, URI-friendly schemes. I for one believe that software serves users first, and methods to locate and specify information needs to adopt its users needs, not the other way around.
> Even something as simple as showing my friend the same map I'm looking at so we can talk about it requires bending the role of URIs wildly out of shape.
How so? That 'same map' _is_ the resource being uniformly indicated.
> This link refers to "restaurants around Times Square", which isn't a logical entity
Why not? It's a logical entity, which is a collection viewed a certain way.
The difference here is that one platform requires shoehorning a URL into a non-document-centric use case, and the other one leaves it optional, for the developer to implement as he/she sees fit.
If I'm using the Yelp app, I expect to be able to communicate a restaurant listing to someone else via a URL. But why is it that my alarm clock needs a URL? Or my phone dialer?
The web was envisioned as interlinked documents, and for many parts of the web this is still very much the case (see: Amazon). For others this metaphor breaks down badly, and is the source of a great deal if hacks and kludges.