The Pain of Updates: Separating Content from Application

If you ever updated a large iPhone/iPad or Android app you know how painful it can be. How many times have you cursed the publisher of your product because:

  • The connection to the internet dropped or decided to slow to a crawl
  • The App icon gave the message “Waiting” and would not continue
  • The  battery in your device died or the application crashed
  • You ran out of patience waiting for the download to finish
  • The device went to sleep in the middle of the download
  • Your wife yelled at you to change the babies diapers NOW

Customers of iBird–and most likely of other large birding apps such as Audubon, Sibley and others–all have huge apps that occasionally or frequently need to be updated. And when that happens they usually look for the Tylenol before commencing.

Lumps Are Not All the Same Size

Here at Mitch Waite Group we have had our share of suffering customers who let us know they were unhappy trying to update their app. Whether the app be on the Apple or Android platform, the complaints usually fall into one of the categories in the bullets listed above. Why are there so many problems with these mobile device updates? After all when you update a program on  your PC or Mac it’s a pretty straightforward process. In fact most of the time you can walk away and come back later to see if it’s done.

The reason that apps are harder, fall into one or more of these categories:

  • Mobile devices are not normally connected directly to the Internet over Ethernet
  • Mobile devices use WiFi which is often unreliable and slow
  • Mobile devices have slow processors and not much RAM as compared to desktop or laptop PCs so everything takes longer
  • Mobile apps are not well designed for update processes

This last point, Mobile apps are not well designed for update processes, is one that large apps are particularly plagued with. Take iBird Pro – on the iPhone iBird Pro is over 500 Megabytes. That is 1/2 a Gigabyte. Its a lot of space. For example if you have a metered cell phone plan of 200 MB a month and try to download iBird over it you will eat up your entire allotment and be charged for the overages. If you have a 10GB a month plan you will eat up 5% of it with this one download.

Who Do You Love: Apple or Google?

Apple developers with large apps will tell you that they love Apple a lot more than Google (who licenses the Android OS to the carriers) for one big reason. Apple bundles the content of an app with the program itself, puts them in one file and then hosts that file on their servers. Google on the other hand limits the size of the app they will allow to be placed on there servers to 25 Megabytes. There are statements on the web from the last Bootcamp that Google increased the maximum size of an app all the way up to 4 GB. However we have not been able to confirm that. So as a developer, up to now, if your app is larger you must find a way to get around this.

Automagic Downloads: the Bird by Bird Installer

Given iBird Pro’s database is 500 MB we had to come up with a way to handle the Android app size limit. The way we did it was to unbind the database from the application. The way it works is like this: When you download an iBird app from the Market you are basically getting the main application without the database. Once the app is installed you are taken to a screen in iBird where you can download the illustration, photo and sound files (what we call binary data). You are given the option to download all of the content or just some of the content (for example all species which start with the letter A).  We also made it so you can skip doing this download process. In which case when you actually go to a species page in iBird the very first thing that happens is the binary data for that bird is downloaded automagically.

Now if Google has actually increased their app limit to 4 GB would we want to bind the database back to the app and let them host the whole thing for us like Apple does? The simple answer is no. The reason is as follows.

The Benefit of Separating Content from Application

The advantages we get as developers and pass on to our customers when we separate the database from the content are:

  • We can update the database and the user doesn’t have to reinstall the entire app to get these changes.
  • We can modify the app and the user doesn’t have to download 500 MB of data  to get these changes.
  • We can make even tiny or minor changes in the database and the customer can download them quickly and with little effort or interruption.

The negative side of separation are:

  • We as developers have to pay to host the database
  • The place we host the database has to be a fast server so customers don’t have to wait a long time for the delivery

Now that we have discovered the Content Delivery Network MaxCDN who now host our Android database we have solved both the above negatives.

Show me an Example

Here is an example of how we present the separation when the app starts. This shows the iBird Lite app starting up and the message received that a database update is waiting. The customer can skip it for now and do it later if they wish.

But Wait — There is More

As  you can see in the message for this update we added 18 new photos. A link is provided for seeing what photos we have added. You can try it now if  you like:

http://bit.ly/iBird_Lite_db

We used Google docs, specifically a spreadsheet for this list. If we had included more features we could list them here as well.

Mitch

End of the Story?

Maybe not. Stay tuned for more as we continue to advance and improve the database update process.

8 thoughts on “The Pain of Updates: Separating Content from Application

    • Cameron how do you think the updates to iOS5 will help solve the dilemma this blog post discusses? With Apple products we bundle the database with the app because that is the way we did it in the beginning. So we get the benefits of Apple’s servers hosting our huge database and the disadvantage of our customers not being able to update the database without updating their entire app. Could we separate the database from our Apple app? Yes we could but at this point we are just not prepared to do that. We have some other ideas however that might give the iPhone app some advantages over the Android app. Stay tuned.

  1. Thank you for posting this explanation. It was detailed and worded such that everyone who bothers to take the time to read it should understand why there are differences in the way this app and its databases are both downloaded and delivered. By posting this info you have demonstrated that you really do care about all of your customers And as a bonus, I learned some Interesting facts.

  2. Mitch, I use a number of medical iPhone apps that enable you to update content from within the application itself (Medscape, Eprocates). I appreciate these are only text-based updates and are likey quite small in size. Is then the updating issue more an issue with size of the updates in ibird app than anything else?

    As an aside, can you give us any morsels of info on potential features coming to the app 😉

    Thanks Mitch,
    James

    • James the issue with the iBird update (and other similar apps) is the shear size of the database. Apps like Medscape and Eprocates only need to update text which takes up very little space. Apps like iBird contain high definition illustrations, photos and sounds which consume megabytes of space. So you are correct the update issue is basically a size issue. As far as tiny morsels of potential new features if you read the blog in its entirety you will find some indications of areas we are exploring for future features. I can’t go into too much details because our competition reads this blog and will copy anything we do (as you can see if you own any of the other bird apps). Luckily they don’t do a very good job borrowing our ideas 🙂

    • Pat I wish I could accommodate your request but unfortunately there is not any way I can think of that would work any better than the way we are doing it now. You are asking if you could download the database to your computer after you purchase iBird, then sync your Android phone or tablet with it. On the surface that sounds like a good idea. The problem is you still have to somehow sync your Android phone/tablet with the computer. That is not as easy as it sounds. Each carrier and tablet manufacturer uses a different way to communicate with a computer. So we can’t count on a standard approach. Some have USB and some don’t. Some mount the Android device as a drive and some dont. Even once you have established a connection between device and PC you still have to make sure the data gets transferred with no errors. So now you have two places where errors can occur: the download from the server to the PC and the sync from the PC to the device. You have essentially doubled the number of failure points in exchange for perhaps a more reliable connection to the internet. Then what about those people who use dialup or have really slow internet connections on their computers? So perhaps this can help you appreciate the complexity of large databases. Personally I think the best solution is the way Apple does it; unlike Google Apple allows apps to be up to 1,000 megabytes in size. Google limits apps to 50 megabytes or 1/20 of what Apple allows. If Google allowed just 10X larger apps we could put the whole database in the app and their would be just ONE installation step.

Leave a Reply