iPad devsugar: Three lessons from the iPhone

As an (extremely smalltime) iPhone developer I am not convinced that the part about short-time attention-span will ring true for the iPad. I suspect that the comfortable nature of a quality screen and ease of entertainment consumption will lead to the iPad being used more than a lot of people's laptops eventually.

I can actually see the device becoming a real contender when it comes to single-task work, for instance I believe an iPad with a keyboard connected could be just about the best writing station for someone writing creatively. Distraction free and a setup that mimics the old type-writer a lot better than a regular laptop. (Not to mention the fact that it's a much better device for proof-reading).

Is there any good reason why the SDK doesn't include an API that can save application state (heap, stacks, registers) with a single call, and restore it with another? For apps with a small memory footprint and few threads this should be very fast, certainly much faster than any non-binary serialization process the developer has to write herself and that cannot capture state completely (stack, registers), and could provide an experience like on a "switch task" O/S - as some of you may recall, we had those on the PC back in the day as an intermediary step on the way to multitasking.

At least on the iPhone, I don't really need multitasking at all. There is nothing I can think of I want an application to be doing on the phone when I am not using it. But I frequently need to jump between apps, to copy/paste something or to read that paragraph on the web page again before continuing on my e-mail. Push notifications are a better solution for the other scenarios - I'd much rather have an incoming Skype call appear as a push notification than spend my battery on having Skype running continously in the background.

I think this will largely apply on the iPad too, although if people start using them for real work they might want to be able to use other apps while those music files are being converted or Picasa for iPad matches faces to people... or any long-running task really.

Perhaps the save/load state at program exit/startup could even be the default behavior for future apps? Coupled with some O/S provided UI to easily access the most recently used app this would considerably enhance the user experience at little cost to developers or battery life. And it would end the frustration with all those apps that are useful but simply haven't implemented this "go back to where you left off" feature.

The prime example from my own use is an app from RATP, the entity that runs public transport in the Paris metro area. It shows estimates of when buses and trains will arrive at various points, but since this is inherently unpredictable I want to re-check the estimates fairly frequently. Doing so currently requires me to launch the app, watch the splash screen, select network (bus, metro, regional train, etc.), select line, select stop... then finally look at the estimate for two seconds and close the application. While it does have a "favourites" list that shortens this process to launch, select favourites, select favourite, I still spend 90% of the time with this app navigating it. Since it provides me with very useful information - and the total time is still fairly low - I can endure it, but it would no doubt have been a lot better with a "switch task" concept built right into the platform itself.

I think we will start to see richer apps on the iPad making use of the extra screen real estate.

Apps like Facebook will be used less tho imo due to the screen being big enough to just browse the web on the full site.

Interesting to see how the extra real estate will work with third-party applications. Some apps MUST go larger on the iPad, like facebook for example, sure it worked fine on the little screen but you should have a much better experience on the big screen.

Constructive. Nice.

Good ways to remember to be friendly to the user.

Great article, even though I'm not a developer or coder of any kind, still interesting to see best practices in sausage making.

One other note: the screens have different pixel densities. It's about 160ppi on the iPhone and about 130ppi on the iPad, so a shape of certain pixel dimensions will be about 25% larger on the iPad. For example, a 160px x 160px square will be 1" on the iPhone and 1.25" on the iPad. If you make an element that is to be touched and it's a little on the small side on the iPad, it'll be REALLY small on the iPhone.