The problem with most apps is they have to give you enough information to justify the space and mental bandwidth they consume. People only keep and check apps that send them daily info, and delete the rest. Commentary after the quote.
The smartphone OS we use are still largely based on the assumption of my phone being a mini-desktop, rather than, well, an information nacho, if you will. Consequently, if you’re making one of these apps, your app must give me something new daily (or more), or else it has no reason to live. Its information would be better shown to me via another app I do check often, like a social news feed or a messaging app. The only recourse the OS affords these apps in avoiding such a fate is the rather blunt instrument of push notifications (and things like Today widgets or Android home screen gadgets). (Source)
If you think about this, this is exactly the problem with online pre-Internet. There were different BBS’s with different focuses, and even with a provider like CompuServe you were always locked into a particular package of content.
Usenet was the forgotten solution to this. You had a single interface through which you could interact with dozens of servers. A new group could form anywhere and propagate immediately without central approval and without people having to download yet another application or learn yet another server and login.
That was followed by the Web, which did the same thing for read-only docs. But of course the web never built a standard for identity or interaction into the system the way that Usenet did. That led to the rise of the mega-sites (Facebook being the winner here) which supplied these interactivity platforms, and now it’s happening for apps.
In other words “There’s an app for that!” turns out to be the definition of a massive infrastructure problem, not a solution. “There’s an app for that” is the exact wrong design for anyone that wants to do serious work on a phone.
Maybe people want want they’ve always wanted — a truly two-way web, one that has as robust a spec for interactivity as it does for content delivery. Of course, the way we’ve tended to go about this is have request for documents and media standardized, but everything else is hand coded and different for every server.
Even that’s broken, isn’t it? I have a server called “Hapgood.us”. You can ask it “Do you have a page (or response) at this location?” But without knowing that it’s running WordPress I can’t even send a request to the server and say “Do you have a document named ‘Mitra’s Brain Scans’?” Each server search engine using different params, etc.