The Broken Mobile App Model of Today

Standard

Over the last few years the new paradigm of Mobile applications has appeared. Mobile is primarily a Software with an optional (but frequent) online component. This is not new. This is actually how “online” got started. Proprietary and native applications accessing data somewhere else. It works. It’s powerful. However, the Mobile App model is inefficient and broken right now and it’s not because of fragmentation or multiple technologies — which cause technical pain. It’s because the model prevents rapid iteration, integration, control and experimentation, which are big business pain points.

I’m far down the list of Mobile experts in the world. My experience comes mostly from the investment we’ve made over the last nine months to make EveryMove available on iOS (in addition to our website) and soon on Android, but also as an avid user of Mobile technology. More than once I had to get a reality check to learn how limited Mobile development is, and it shouldn’t be.

It’s Apple’s Fault!

Apple is a control freak. They believe excessive control over every single bit of a product will yield a better product. Because of that m.o., when they launched their App Store they chose the most controlled way of building apps. Not only Apps had to be built in a fully proprietary language, framework and environment, they also had to comply with an enormous list of rules and they had to be certified and approved by Apple before they would be available for the device. It makes sense to do it this way to deliver an incredible consistent experience. If you were an early iPhone user and installed Apps, you know how they all felt just like the built-in apps.

When Google launched Android they followed the model Apple had set on the industry with more openness. Use an open language, with an open framework, with a tool set you could get from multiple vendors. You still submit the app to their app store, but you could install apps that were not on the app store, except that discoverability of those apps are basically non-existent.

The Early Days of the Web & Java

The Web has always been very open. There is no central organization approving your website to go live. There is no certification process and until this day, discovery of new Web sites (or Web Apps) are done via word of mouth (email, social, etc.), search engines or referrals. When Java came out circa 1994, it promised a world where full applications would be hosted on the cloud, downloaded and cached on the browser and they would have the ability to run online or offline. It was the equivalent of saying you wanted to run “Microsoft Word” and the first time you tried to open a DOC file, MS Word would be downloaded automatically for you and cached. If a new version of Word would be available, the cache would be invalidated and the new version downloaded.

It never happened. It didn’t happen because the timing was off and the execution was weak. Bandwidth wasn’t fast enough to make that model work. Browser fragmentation and the unavailability of Java built-in on Windows and other OSes made the process painful. Java slowness on those computers made sure no serious applications could be written at the time.

The New Mobile App Model

My argument for this entire post is that Mobile App Model should embrace the Java Model of the mid-90s. I like the idea of an App Store for discovery, but there is no real reason Apps bits couldn’t live at the app Developer servers. There is also no reason that Apps couldn’t be more modular and instead of a single blob download, be downloaded as components that could be upgraded independently. It’s not only good software development practice to componentize your product, but it also makes for faster downloads of changes.

We can still have an App Store. We can still have Certified Apps, similar to getting an SSL certificate. The apps wouldn’t be certified for their quality or content, but certified there is a trust chain. It wouldn’t also prevent developers who don’t own servers to host their content at some other place, but it would be up to the app Developer to decide.

What this model allows for is incredible flexibility for app developers to quickly (hours) to fix and ship new bits. It would allow app developers more analytics information about their app downloads, including “source” information (how did people find my app). It would enable A/B testing! Now I can give every other user a slightly modified version to see how they engage better. I can still do A/B testing in today’s App Store, but it’s “unnatural” and painful, while A/B testing on the web is easy and magical.

Security wise, phones should give less access to information to app developers. An App by default should be forbidden from accessing my contacts or my photo albums, and only if they get a special certificate, which might require part of the binary to be certified and digitally signed by the OS manufacturer, they could access those APIs.

Finally, the same way that I can do cross-domain AJAX calls today, two apps that want to talk to each other on the phone should be able to do that. If my app wants to expose a local API (i.e., getCurrenUserFullName) I should be able to do that. It would open up Mobile development and provide incredible integration across apps.

And we do some of that today

There are apps that are working around the limitation of the App Store by creating their own infrastructure just like that. They run a Web Control, fetch JavaScript, CSS and HTML from the server, cache it and run the app. If new updates are available, the fetch the new JS/CSS/HTML. ┬áIt’s a lot of infrastructure and supporting work, just to get the flexibility of quick patches, quick iterations and A/B test.

If App Stores want to embrace the new ultra fast-paced world of startups experimentation (agile, lean, etc.) they will need to adapt a different model. The one we have today is not friendly to startups.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s