Posts Tagged app stores

App stores have no place in a web-apps world

I have read with great interest the latest Matt Asay’s post, “Enough with the Apple App Store apathy”, that provides a clear overview of why App Stores should be at the center of open source advocates’ rage. Matt is right (and some developers already started addressing this, like some of VLC project developers) but I believe that the current monopoly of app stores is just a temporary step in the wait for real web apps. App stores, in fact, do just a few things well; others not as well, and they take a hefty percentage of all transactions just because they can.
barbeque sauce

Let’s think about what an app store is about:

  • Discovery: one of the main advantages of a central point for searching applications is.. well… the fact that there is a single point for searching. Since developers, when submitting an app, need to perform a categorization or tagging it to make it searchable, an app store is actually quite helpful in finding something. Until there is too much of something. In fact, already in the iOS app store, and partially in the Android one, looking for something is increasingly a hit-and-miss affair, with lots and lots of similar (if not identical) applications trying desperately to emerge in the listing, or maybe to end up under the spotlight of some “best of” compilation. In fact, as Google would happily tell you, when you have too many things pure listings are not going to be useful; you need real search capabilities or some sort of manual suggestion (like social features, “I like it” or whatever). App stores are starting to get it, but they are insulated from the web – which means that they are unable to harness the vast, multifaceted amount of information created by tweeters, bloggers, journalists and pundits that watch and evaluate almost everything on the web. Discovery is now barely possible in a store with 100k apps; as things evolve, it will become even more difficult. In a world of web applications, well, this problem returns to a (very solvable) problem of finding something on the web. Ask Google, Bing, Baidu, Yandex, or more “intelligent” systems like Wolfram Alpha-they all seem to manage it quite well.
  • App updates: one very useful thing is the ability of an app store to send notifications of new apps, and help users in having all the update process done simply and in a single place. This is of course quite useful (just don’t claim that it is a novelty, or any YUM or APT user will jump straight at your neck), but again is totally irrelevant in a world of web apps – the app will just check for a new version, in case it uses persistent storage for caching JavaScript and includes, or simply go straight to the website of the application publisher. This also resolves the friction introduced by the app approval process in current App Stores: you submit it, and then pray :-) If an update is urgent (for example for a security fix) you just have to try as much as possible to speed it up – it is not up to the developer, anyway.
  • App backups: in a world of apps, app backups are a great idea. In a world of web apps, backups are simply bookmarks, with the cacheable parts re-downloadable in any moment. Since both Chrome and Firefox do have already their own way of syncing bookmarks, this is covered as well.
  • Payments: this is quite an important part – and something that current web apps provide in an immature way. The Google Chrome web store do something like this, but it works only on Chrome and works only with Google; there is a need for some more high-level payment scheme embedded within web apps.

As I commented to Matt in his article, I still believe that app stores are a useful, albeit temporary step towards a more open and transparent infrastructure, that we all know and love: the web. And we will not have to forfeit 30% of all revenues to be on it.

, ,

6 Comments

Web versus Apps: what is missing in HTML5

If there is a concept that is clear in the analysts’ minds is the fact that mobile (in any form) is the hot market right now. Apple’s iOS devices are growing by leaps and bounds, dispelling the doom predictions of our beloved Ballmer: “There’s no chance that the iPhone is going to get any significant market share. No chance. … 2% or 3%, which is what Apple might get” or dismissing the iPad as “yet another pc”. The reality is that new mobile platform are consolidating a concept -  the idea of the App store, that is an integrated approach to managing and buying applications – and the idea of “apps for everything”, even for data that comes off straight from a web site, like the recently launched Twitter app for the iPad, that is – in my own, clearly subjective opinion – beautiful.

After all the talks about platform independence, portability, universality of HTML5, and so on  – why Apps? why closed (or half-open) app stores, when theoretically the same thing can be obtained through a web page? I have a set of personal opinion on that, and I believe that we still need some additional features and infrastructures from browsers (and probably operating systems) to really match the feature set and quality of apps. If – or when – those missing pieces are delivered to the browser, the whole development experience will in my opinion return back to the web as a medium, substantially enlarging the potential user base and reducing the importance of a single OS to develop for.

User Interfaces: this is, actually, one of the easiest things. HTML5, CSS3, Canvas, and a whole bunch of additions (like WebGL) are already closing in on the most refined native UI toolkits. There is still a margin – of course – but that gap is closing fast. Modern toolkits like Cappuccino (one of my favorites, used to create the stunning 280slides tool) are quite comparable to native UIs, and the few remaining features are being added at a frantic pace (thanks in part to the healthy competition between Mozilla and WebKit).

Video: actually, WebM is in my tests a very good alternative to H264, in terms of quality and in decoding efficiency (in my tests, WebM playback uses 20 to 30% less CPU than the ffmpeg H264 decoder, which is quite a good result). As for quality, the results of MSU graphics and media lab codec comparison found out that WebM is approximately equivalent to the baseline x264 encoding; that is, good enough for most applications. The substantial drawback of WebM is at the moment the dreadful encoding time – 5 to 20 times slower than comparable, more mature encoders. Substantial effort is needed before WebM can become encoding-wise competitive.

2D and casual gaming: ah, the hard point of gaming on the web. Up to now, gaming has been mainly relegated to the Flash engine, and is one of the parts still not replicated well by HTML5, Javascript et al; in fact, Flash is quite important for the casual gaming experience, and some quite stunning games are based on flash, and comparable to native games (if you want to waste some time, look at RoboKill2 as an example).However, given the fact that no fully compatible open source flash player exist, there are still issues with the real portability and platform independence of flash gaming in general (despite the excellent improvements in Gnash and LightSpark; also, it may even be possible to see in the future a native translator to Javascript like the SmokeScreen project. Actually, there is a great deal of overlap of Flash with recent evolutions of Canvas/HTML5/Javascript – it is clear that the overall evolution of the open web platform is going in the direction of integrating most of flash functionalities directly within HTML.

3D gaming: There is at the moment no way to create something like the Epic Citadel demo, or Carmack’s RAGE engine on iOS. The only potential alternative is WebGL, that is (like the previous links) based on OpenGL 2.0 ES, and paints on the HTML5 canvas (that, in the presence of proper support for hardware compositing, should allow for complex interfaces and effects). The problem is that browser support is still immature – most browsers are still experimenting in an accelerated compositing pipeline right now, and there are still lots of problems that need to be solved before the platform can be considered stable. However, after the basic infrastructure is done, there is no reason for not seeing things like the current state of the art demos on the web; modern  in-browser Javascript JIT are good enough for action and scripting, web workers and web sockets are stable enough to create complex, asynchronous event models. It will take an additional year, probably, until the 3D support is good enough to see something like WoW inside a browser.

Local binary execution: for those things that actually cannot be done by a browser, local execution is the only alternative. For example, having a complex VPN client embedded in a web page is something that would simplify the task of connecting to a web (or non-web) in an easy way without downloading any additional package. This model was demonstrated by Google in its ChromeOS presentation, showing off a game based on the Unity web player, ported to the Native Client (NaCl) environment. The problem of the initial implementation of NaCl was that the binary was actually not portable across cpu architectures; the new pNaCl (portable NaCl) uses the incredibly good LLVM infrastructure to generate portable bytecodes.

Payment: there is one thing that is sorely missing or incomplete, and that is billing and payment management from the web application. Within iOS, and thanks to iTunes and carrier interactions, paying even in-game or in-app is easy and immediate. There is no similar ease of use and instant monetization within web applications, at the moment. One of the missing things is actually the overall management of digital identities, that is inextricably linked to the payment possibilities and channels.

DRM: yes, DRM. Or content protection, or whatever. Despite the clear indication that DRM schemes do not work, there is no shortage of studios or content producer that want to ensure that there is at least a minimum form of “protection” against unwanted use. I don’t believe that this form of protection is useful at all, but I am not confident in people accepting this in the next 5 years – and this means that DRM should be possible in the context of the browser. Possible alternatives are the use of a ported content execution engine (imagine a video player based on pNaCl, that brings its own DRM engine inside). Or integrating an open source DRM engine like DReaM (if it survives the Oracle changeover, that is). This kind of tool can also help to prevent cheating in online games (imagine a WoW like game, based on Javascript: what prevents the user to change the code on the fly with something like GreaseMonkey?) and other multiplayer environments.

App stores: what is an app store?  A tool to reduce searching costs, and in Apple iTunes model a framework for app management and backup. In a sense, something like this is possible right now with some browser/OS integration (the excellent Jolicloud has something like that right now, and with some additional support for web packaging formats and remote synchronization like Mozilla Sync this can become ubiquitous).

What do you think? Is there something else missing? Comments are, as usual, welcome…

, , ,

5 Comments