iPhone Multitasking and How it's Discouraging Developers from Building the Apps You Want

I’m sure you have already heard about how the iPhone’s multitasking feature is not true multitasking. This is a rather popular subject for debate among internet forums and bloggers. The average Apple fanboy will praise Steve Jobs for creating an iPhone that has the perception of great multitasking functionality without draining the battery. But what you probably don’t know is the specifics behind iPhone’s multitasking limitations and how they might restrict developers from building full functionality into their apps.

What is Multitasking

The term ‘multitasking’ refers to as the ability for an operating system to run multiple apps at the same time (not to be confused with multithreading). On a mobile device like the iPhone or iPad, apps utilize the entire screen, so it is impossible for the user to see more that one app running side-by-side. But the perception of multitasking is still felt when a user switches to another app that has retained its previous state. In this way, users can switch back and forth between apps and immediately return to what they were doing, whether it was playing a game, reading their email, or browsing the web.

iOS 4 has implemented a clever form of multitasking that allows the user to experience the benefits of multitasking without actually allowing apps to run in the background. When an app enters the background, it is given a chance to save its state and then it is put to ‘sleep.’ While asleep, the app is not allowed to execute any code until the user returns to it. There are only few exceptions to this rule, the app can continue to play music, it can schedule local or push pop-up notifications, it can finish uploading or downloading a file for a mamimum of 10 minutes, and it can receive location updates. Apple will tell you that these features are put in place to save battery life and are enough to allow app developers to deliver all the functionality they need. For the most part, this is probably true. But there is a whole classification of apps that are difficult or impossible to write given these restrictions.

Apps that don’t work well with Apple’s Multitasking

Any app that needs to schedule a task to run in the future simply cannot work with iOS. Often, these types of apps are called ‘service-based’ apps because they need to periodically synchronize with an external service such as an e-mail server, rss feed, or instant message server. The value of these types of apps are really measured on how fresh their data is. A good rss reader client app would ideally have the latest news stored on the device so it is ready to read at anytime, regardless of internet connectivity. This is particularly necessary when the user is commuting on a subway or airplane when internet connectivity is not available. In fact, one of the big differences between writing web apps and mobile apps is handling the user’s offline experience. A well-written mobile app will use aggressive data caching techniques to smooth the user’s transition from on and offline. Third-party e-mail, social networking, calendar, and instant messaging apps are in the same boat.

Apple’s Push Notification Service is Not a Solution

Apple offers a web service called Apple Push Notification Service (APNS) that allows data to be delivered from third-party providers to an iPhone app. Push Notifications are often cited as a solution to the ‘service-based’ apps problem because of its ability to notify users of new events even while an app is in the background. But using APNS is a non-trivial task to implement and is often not a complete solution anyway.

When an iPhone device receives a push notification, it presents a pop-up dialog with the message text and perhaps a few buttons to allow the user to decide what to do next. Instant message apps often use push notifications when a iPhone user receives a new instant message. This works well for instant message apps because messages are often short and the user can hit a ‘reply’ to continue the IM conversation. However, for a calendar or rss reader app, use of APNS is not really useful. The iPhone user does not need to be prompted with a pop-up every time a new calendar event is scheduled or when a new rss article is published. The user would constantly be interrupted with annoying pop-up messages. Also, push notifications can only be used to prompt the user, not actually deliver data to the app.

Implementing a third-party push notification provider is actually quite an intensive development task. A push provider requires dedicated web hosting and custom server code. But perhaps more importantly, use of a push provider may introduce security concerns. Often times the push provider web service is written to act on behalf of the iPhone user when authenticating with another third-party email, calendar, or instant messenger server. At the very least, this means that clear-text personal data is flowing through the push provider, and at worst, passwords are being stored and forwarded somewhere in the system.

In the end, implementing a ‘service-based’ iPhone app is a serious headache for developers due to Apple’s restrictive multitasking policies. Perhaps in some cases, implementing a Push Notification Provider can provide the functionality needed, but at serious implementation cost and user security risk. In other cases, a push provider simply will not solve the problem at hand due to the nature of the app. Either way, app developers are going to be discouraged and ultimately the functionality that can be delivered in an iPhone app is reduced.

There are two main reasons given as to why Apple chose to implement multitasking with such restrictions. The first and most common reason is that background apps, if left unchecked, can drain battery life. This is true, but not as big of a deal as people make it out to be. On average, both an iPhone and an Android device will last for a full day on battery power. Of course this all depends on usage, but in general you can expect to get at least a full day of use from any phone. (If you are a power Android user you can carry an extra battery with you on the go, something that is not an option with any iPhone). Second reason why Apple refuses to implement true multitasking is because they are concerned that their users do not generally understand (or want to understand) the complexities of multitasking and the impact it might have on their user experience. This point seems to fit with Apple’s continuous efforts to ‘dumb-down’ or simplify their user interfaces to make them user friendly for the masses. Don’t get me wrong, I’m all for creating intuitive and sexy user interfaces, but when it means sacrificing powerful features, I draw the line.

Paul Soucy

Read more posts by this author.