Wednesday, June 18, 2014

App Ecosystem Architecture

Hello, my loyal, long-suffering, readers! Many apologies for not posting for sometime. I have been busy building an app monetization service: Kundalera. Okay, so the name of the company is bad. The website is basic. Heck even the product is small. What am I gonna do? I'm building this basically by my self. (I do have a couple of "helpers".) I'm also moving across the country and looking for a day job. (The company will be really cool if I ever get funding.) The idea behind Kundalera is to provide web services and an SDK for app monetization.

    There are a few parts to it:
  1. Improved billing services
  2. Improved user acquisition
  3. Novel app monetization models
  4. Some really cool apps

But enough about that right? It's boring and no one wants to hear my secret plans to take over the world anyway. On to the good stuff: SOFTWARE ARCHITECTURE:

The app ecosystem is broken. Period. Certainly it is more broken on Android than on iOS, but lets put Apple aside for the moment. If you search "android app ecosystem broken" on Google, you get 16 million results.

It is broken for many reasons. Foremost among them are security and stability. Android runs on a very wide variety of hardware including many non-smartphone platforms. This leads to development complexity for app developers accessing features such as disk storage and the cellular transmitter that iPhone developers don't get to touch. Now you can argue that it's a bad idea for app developers to do this, but Google has given them a hammer and they have smashed their thumbs and in turn the thumbs of all of their users. Users can opt not to give apps access to these low level resources, but then they don't have functional apps. And like the developers, if you give users a hammer...

Apple doesn't face this problem. It doesn't give developers access to these low level resources. They have kept the OS abstraction barrier intact whereas Google has allowed it to be broken. And why did this happen? Google came to the party two years late. The first iPhone was released in 2007, the first Android phone in 2009. Furthermore, the original Android phones were primitive creatures compared to the quite sophisticated iPhone. Google knew that the availability of apps for Android would make or break the success of the product, so it opened up the APIs giving developers access to these low level resources that they did not have on Apple. It worked. Developers developed tons of apps. People bought Android devices. Android is now the most popular mobile OS in the world. Other OSes without a vibrant app architectures (I'm looking at you Symbian, Blackberry, Windows Phone) are struggling at best.

The mobile world has become extremely app based. Many users don't use voice functionality and spend most of their day using a handful of apps. Meanwhile, the desktop/laptop world has become increasingly web based. Most users spend a large majority of their time using a web browser and browsing a handful of sites. Ironically, these are frequently the same sites whose apps they use when on their smartphones. This forces the sites to develop two entirely separate products. If they are smart, these companies share a lot of back-end services. Regardless, the vast difference in presentation layer technology increases maintenance costs a lot.

App architecture should look like web site architecture. The web browser is a sandbox that keeps malicious or inefficient sites from doing bad things to the User's computer. So why don't companies just create some new css or a slimmed pages and go with mobile web sites?

    Two reasons:
  1. Standard web-scripting languages don't allow the flexibility of app development languages
  2. App developers want home screen real estate in the form of an app icon

We can address these concerns by adopting a true Model View Controller architecture across platforms (web, various mobile flavors). The mobile OS providers should incorporate a transparent web browser into mobile OSs that will run 'apps'. This will effectively sandbox the apps in a web browser, keeping the user's device (more) secure from malicious/incompetent apps developers. Second, this will allow developers to write web applications that will then serve as apps.

But that only solves part of the problem. The mobile app stores have become the largest consumer software distribution centers in the world. But no problem. The installation of an app can simply download the static content to the device. This static content will be different than the static content from a web application. It will fit the form factor of the device and be more touch friendly. The dynamic content will then be provided by web service calls. This will encourage developers to write code in a more service based architecture.

And what about the richer interaction that apps provide? The browser consortiums must solve that problem. New, better, languages, and frameworks must be developed. (I for one would love to see JavaScript die. It is horrible bastardization of an Object Oriented and a procedural programming language, but that's another rant.)

Of course, developers will have to write their applications (at this point mobile apps and web apps) in order to be more functional offline. No more 404 pages. Rather, a normal UI, but one that may provide error messages regarding network connections upon attempts to access remote content. This would be a huge improvement for web applications as well.

There is one last problem. Many apps really do need access to phone primitives, lights, Bluetooth, etc. They belong in a special category: 'real' apps, i.e. those which truly run on top of the OS instead of the web browser sandbox proposed above. These should undergo a stringent review that the app developer must pay for in order to determine their safety/performance. This review needn't be done by the mobile OS provider, but could be done by an approved third party, much the same way that SSL certificate subjects are validated.

Android provides a fantastic open platform that has reeled in many app developers and it is now the leader in the mobile OS market (by number of devices). Apple's iPhone is far more locked down. It just plain does less, but it provides a more secure, reliable, consistent user experience. The adoption of the above recommendations would allow app developers to more easily develop for both platforms and provide a better user experience on both while improving reliability AND security.