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:
- Internet connection speeds have massively increased from our measly 56k dial up modems
- Use of CDN (Content Delivery Networks) has improved things so that you download from a server that is geographically closer to your location
- 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) 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 40 MB 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?