Missing iPhone OS 3.0 Features
Apple has released the third major revision of its iPhone mobile operating system and it has sparked both developer and user interest. This update is mainly Apple playing catch-up to both other mobile operating systems as well as their own promises. I have been playing with it for about a week and have compiled a list of missing features and missed opportunities.
Icons As Displays

Adding badge numbers to some icons (Phone, SMS, App Store) is sufficient to convey needed information but on other applications more information is needed. As seen with the calendar icon as well as the clock and weather icons for jailbroken users, the ability to use an icon as a display surface is a powerful and underutilized concept.
Applications should be able to modify their icons to provide quick and relevant information about themselves through multiple, pre-rendered images. Similar to how applications are displayed, a base image and multiple transparent images could be layered to produce the final icon.
When a push notification is received the ability to switch your applications icon image to another should be an option. Then, when the icon is next displayed on the screen (phone is unlocked, paged to, running application exits, etc.) it should “dance” as if you were rearranging icons but only for 1 second to indicate it has changed.
Examples:
When Sportacular (or ESPN, etc.) application receives a score update it could update itself to reflect the most recent scoring updates.
A to-do list application could display a series of pictures on its icon screen to help remind you of tasks. A shopping cart and green dollar sign would server to indicate that you need to stop by the grocery store for items and visit the bank for some transaction.
Background Processes
A lot of the debate has been over the decision to use push notification in lieu of background processes. This seems to benefit applications whose architecture is already server-client. Most developers likely don’t have the resources to set up a large infrastructure to support this architecture, nor do their apps necessarily lend themselves to it either.
In the OS 3.0 presentation (SD, HD), Scott Forstall reports that Apple’s internal testing yielded an approximate 80% reduction in battery standby time by enabling background applications. A lot of applications do not need to run constantly in the background but merely need to update themselves.
One possible solution would be to implement scheduled background code execution.
Applications could schedule themselves to have certain code run at particular times. Limitations would have to be placed on the frequency of scheduling and the length of execution allowed, say no more than 10 seconds of total CPU time and 4 schedule instances an hour. This code should work like local push notifications and only be able to play a sound, update the badge number, display a notification, or update the icon screen.
Examples:
The native weather application could now have a preference for auto-updating every 15, 30, or 60 minutes. Its icon screen would update to reflect conditions and it could also fire a notification if there are any weather watches or warning issued. It could also query the location services if time allowed to use your current location rather than any stored ones.
An application like What’s On? could notify you before a favorited program airs by scheduling itself to run at the :25 and :55 minute mark of each hour. While this functionality could be achieved through normal push notifications it shows an example where the infrastructure might not be feasable to implement.
Native App and OS Decoupling
While a lot of the native apps’ features are tied closely to the underlying operating system, decoupling would still prove to be of great benifit. When Apple discovers small quirks in their native apps the changes have to be rolled into the next OS update. The creation of an “Apple Applications” category in the App Store would allow them to distribute updates and new applications independently of the OS. Major changes that rely on underlying OS API changes could still be controlled using this method.
Decoupling would also allow for the deletion of the native applications since the possibility exists of later reinstalling them through the App Store. For users like me who never use the Stocks, Contacts, iTunes, etc. apps it would eliminate the need for it as a jailbroken feature.
Notification Center
Allow for a notification center to be pulled down by swiping across the status bar which provides access to Messaging, Email, iPod, Phone, Search, and Settings. Think of it as a shamless ripoff/combination of Android’s notifications, SBSettings, and Status Notifier which provides access to common features without quitting the current application. In addition to just the alarm icon, icons for new SMS, MMS, and email, missed calls, and vibrate would be displayed.
SMSs can be viewed and replied to (though no conversation history). MMSs could also be viewed and replied to via SMS. New emails could be viewed and forwarded, deleted, moved, or replied to. The iPod song could be chaned within the current playlist, a new playlist selected, or a song picked from the standard artist/album/song heirarchy. A list of missed calls and voicemails could be accessed as well as the contact list. Placing a call or listening to voicemail would obviously suspend the current application similar to how an incoming call does. A global search would provide you with quick access to you to all your data though some selections would quit the current application to launch their own. Finally access to simple settings such as WiFi, airplane mode, and bluetooth would allow for quick setting changes.
Since the OS is unix-based when this Notification Center is active the current application’s process priority would be reduced to allow these functions to operate smoothly.
Now extremely frequent operations such as replying to an SMS, MMS, or Email would not take you out of your current application. Switching on WiFi or turning on bluetooth can be done as needed inside an application. Accessing your contacts and phone records for copy and pasting info from would be quickly accessable.
Other Minor Features
- Srobbling – The iPod.app should scrobble all my music to Last.fm. The Last.fm app should only be a client to the sites streaming music and database.
- Photo/Video Sharing – It would be trivial to add a “Share” option to the photo action sheet which brought up an interface to upload both photos and videos to Flickr, Facebook, YouTube, etc. It should also support the features for all of those sites (sets, tags, etc.).
- Turn-by-turn – xGPS can do it without the digital compass. At the very least the 3G S should have this. Everything needed is already programmed the features just need to be tied together. If Apple did it then maybe it could even be backgrounded like the iPod.
Hopefully some of these will trickle into the 3.0 minor updates over the coming months. If not, use this as a base for 4.0, Apple.
This ideas are awful and will kill my battery life, last.fm scrobbles when I sync my iPhone with the computer. I have reviewed your resume and would like to offer you a position in the field of waste management.
July 6th, 2009 at 9:31 amAll of these features (except the decoupling) are already implemented via jailbroken packages. None of them are a significant detriment to battery life.
Get back to work playing with your blades!
July 6th, 2009 at 9:58 am