Native Mobile App Design Flaw #1

This isn’t going to be (or at least it certainly isn’t intended to be) a fight-inducing post about native-vs-HTML5 apps on mobile… but rather something I’ve noted as a bit of a flaw of the new Native Mobile App model where you download an app from a specific App Store/World/Marketplace.

For those of you that have been around the Interwebz since the beginning (or at least say… circa 2000) you’ve likely noticed that most applications you download for your computer (PC, Mac, or Linux) have gotten faster and faster as the years go by.

There’s 3 major reasons for this:

  1. Internet connection speeds have massively increased from our measly 56k dial up modems
  2. Use of CDN (Content Delivery Networks) has improved things so that you download from a server that is geographically closer to your location
  3. Vendors now provide a quick download installer that fetches the required resources only when you start installing the application

Item #3 is the key.  When you download the latest version of say “Mozilla Firefox” you get a tiny installer that downloads in seconds.  Only once you start it up does it do a quick inspection of your hardware (to find out if you need the “Windows 7 32bit” files, or the “Windows 8 64bit” files for example) and maybe asks if you want language packs, extra features, etc. then downloads only the assets you need for your installation.

The same applies whenever you want to get an update! You download the new parts that you need and essentially “patch” your existing installation.

This is where the flaw comes into play with Mobile Apps downloaded on your smartphone or tablet.  The publisher of say “Angry Birds” (Rovio Entertainment Ltd. btw) (weighs in at: 39.9MB 145MB now Angry Birds on iTunes) might have fixed a typo or a silly off-by-one error amounting to less than 100 bytes… yet every user that wants to get that update has to re-download just shy of 150MB of data!

Not only is this a major waste of network bandwidth but if you are applying these updates over your 4G cellular network while whipping down the highway at 75 miles/hour (120km/h for the metric folks) you’re not only putting unnecessary stress on the cellular network, and your battery… but brutally eating into your bandwidth cap (for those that have them) or (gasp! roaming data charges!). You should be saving that precious bandwidth for watching funny cat videos! 😛

This feels like an epic failure to me to have come so far with online software delivery… and then just throw it down the toilet and re-download entire apps whenever there is the slightest change.

Now I do realize this is quite a challenge to solve as you’d need to provide a smart solution that accounts for literally 1,000’s of developers coding styles/structures.  Some sort of magical binary diff… but that’s what motivates us developers! A Challenge! Announce: “It can’t be done!” and dozens of developers will stay up all night to try and prove you wrong!

Ok, time to play Devil’s Advocate

  • I guess if you had a hybrid app with a small native wrapper that loaded most of the content from a remote server on install/access and cached it as “app related files” then you can overcome the “big download hit” for updates.
  • HTML5 advocates will point out that this is how & why the HTML5 appcache was designed.  Enable smart caching of the resources that can be cached and used offline and only fetch fresh resources as/when needed.
  • A native app with a collection of simple WebViews could combine the benefits of the above 2 items for an app that might never need updating yet always be up-to-date.
  • I’m sure there are a bunch of bright developers that have already taken one or more of the approaches above (even for completely different reasons) but serendipitously solved this problem.

What’s your thoughts? Are we messing things up? Will it all not matter the closer we get to wireless “Gig-E”? Or will the big mobile vendors (Apple, BlackBerry, Microsoft, Google, Mozilla) come up with an ingenious solution?


2 thoughts on “Native Mobile App Design Flaw #1

  1. Good stuff so far.
    More food for thought would be that right now I feel like we take the amount of bandwidth available for granted, and that one day data will be like energy. There will be companies dedicated to redirecting and controlling the flow of bandwidth to key areas in the network when needed. Maybe this is already happening. But imagine it getting to the point of having the rolling black outs equivalent but for the Internet! Millions of people each downloading a 40mb file for just a 100kb file change as you said would be an extremely large amount of unnecessary data on this already fragile network. So I’m with you, something will need to be standardized on and start planning now so that when those dark days of the Internet future do come we won’t be left in a scramble to find a solution.

    My 2 cents anyway

  2. Yeah I’m sure in time the idea of downloading half a gig of data will be something that happens in seconds while you are paying for food at the drive through but today it seems so inefficient and a waste.

    I’ve seen a few games now that have a small installer and then download all the resources they need from their own servers on first run. I think there’s a lot of merit in this as subsequent downloads would not need to download all the additional resources.

    I think if Mobile app market vendors offered the same sort of service with a simple API I think we’d have something! 😉

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s