Posts tagged iphone

Section 3.3.1 is Good News to Native iPhone Developers

There has been many reactions to the recent iPhone Developer Program License Agreement change, from apologetic, to mocking and to stunned silence.

I am not going to fight for any ideological stance, or trying to figure out why Apple made the change. It is done and won’t change anytime soon, so what remains is for smart people to adapt to the situation and seek opportunity from change.

One thing is for sure, Objective C and Cocoa skills are more valuable now than before the change. Adobe Flash CS5 was poised to bring hundreds of thousands of Flash developers pouring into the App Store. Whether they will bring tons of crappy ports with them is immaterial, it would have changed the landscape of the App Store, especially in the games area. This would have been bad news to all iPhone game developers.

Of all the fury and bluster on the web right now, how many have developed iPhone applications? How many of them use native development, i.e. using C/C++/ObjC? Native iPhone developers’ situation has only improved not diminished from this change. So people yelling right now are yelling at Apple for rewarding people who helped build the iPhone platform and not allowing people who sat on the sidelines looking to make a quick buck into the party.

Another effect of Section 3.3.1 is that iPhone version of an app will become the primary target of any cross platform app. Here is an idea for enterprising people out there, make a Cocoa to Flash compiler, or a Cocoa to Android compiler. Apple just created this market for you guys out there to fill. You can rail against the sky and cry why, or you can make the best of it and create a product that people will want. The choice is yours.

How iPad Multitasking Might Work

There has been much complaining on the web about how iPad doesn’t support multitasking, and little analysis of why Apple doesn’t allow it. Adam C. Engst wrote up a great analysis of the types of benefits that multitasking can provide and what technology is required to achieve those benefits.

I’d like to approach the question of multitasking from the user’s perspective and not from a technology standpoint. How would allowing third-party background processes impact the user experience?

Games Don’t Want Multitasking

Gaming is a largest category of the applications for the iPhone. I come from a video game background, so lets compare how game consoles approach multitasking to the iPhone.

Game consoles don’t allow third-party background processes, period. Even first-party background processes are limited. Xbox 360’s dashboard and PS3’s XMB is the interface to access system functionalities while playing a game. Both systems also reserve a small amount of memory and CPU to run system functionalities.

PS3 XrossMediaBar

The reason why consoles take such extremes to limit multi-tasking is to give games consistent hardware performance. Games typically pushes the performance of the system to the limit. When a game updates at 60 frames per second, a small decrease in performance will drop the frame rate to 30, which is immediately noticeable by the player.

Now imagine a game developer writing games for the iPad. It would be impossible to squeeze every ounce of performance out of it if at any point a random third-party application can wreck your performance and turns your game from running smoothly to slowing to a crawl.

For this reason alone, I don’t think any iPad application should expect to be running in the background at all times.

Multitasking on iPad

Believe it or not, there exists an API that manages multitasking on the iPhone. It is called Audio Sessions. An application can claim exclusive access to hardware audio codecs and stop the iPod application from running in the background by setting the appropriate audio session category.

I think this could be a glimpse into how Apple will implement multitasking on the iPad. Apple can define a set of categories for multitasking and each application will set it’s category to the most appropriate one.

Here are some categories which I think might be usedful:

  • Multitask Session Default – allow other application to run in the background with the current application. Quit the current application when the home screen is brought up.
  • Multitask Session Background – allow other applications to run in the background and also wants to keep running when another application starts, maybe quit if an exclusive application starts.
  • Multitask Session Background Resume – Same as background, except restart the application in the background when possible, i.e. after an exclusive application stops.
  • Multitask Session Exclusive – Do not allow other applications to run in the background. Quit the current application when home screen is brought up.

By defining the multitasking behavior through the API, Apple will still have complete control over the user experience, without exposing the complicity of managing processes to the users.

The Apple Way

I am just conjecturing how Apple might add multitasking to the iPad. I don’t have any sources inside Apple. However I believe that Apple will provide the best possible user experience when using the iPad. If they determine that multitasking will decrease the overall user experience then they will not add it.

Like the Cut-and-Paste complaints of a few years ago, Apple will wait until it finds the best possible way of introducing a functionality before adding it. That is the Apple way.

Why Carmack’s iPhone Visual Tour De Force Will Flop

Two words, “Battery Life.”

I have no doubts about Mr. Carmack’s technical ability. His games defined ‘cutting edge’ graphics on the PC for many years. But even he can’t fight against the biggest weakness of the iPhone, a short battery life.
More >