Gam(bl)ing On Apple: One SDK To Rule Them All, One SDK To Find Them, One SDK To Bring Them All And In The iPhone Bind Them?

Continued from ‘Apple iPhone 2.0 (And Other) Predictions: Not The Usual Suspects‘…

From the early March event, we already know that a finalized SDK (and corresponding v2 firmware, likely with Bonjour-based wireless sync capability, finally) are en route, along with ‘push’ email/calendar/contacts/tasks support, Cisco VPN compatibility, and full Exchange integration licensed from Microsoft. Everything in the prior sentence after ‘along with’ will finally enable the iPhone to crack the corporate world in a big way, to the possible detriment of subsequent Windows Mobile and (especially) Blackberry device demand.

The primary focus of the remainder of this writeup, however, is the SDK. In beta since March, I strongly suspect that the final version will be unveiled at WWDC. First and foremost, it’ll largely squelch the homebrew application space, with the exception of ‘jailbreaking’ programs specifically designed to shatter the iPhone’s carrier-specific lock. This’ll occur for fundamental ease-of-use reasons, and in spite of several key current SDK limitations:

• An inability to route VoIP traffic over cellular data connections (for obvious cellular partner-sensitive reasons, in addition to the fact that VoIP over today’s EDGE is at best unpredictable).
• An inability to run an SDK-based program/process (therefore programs/processes) in the background (probably to prevent developers from crafting code that’d prematurely drain the battery or, from a performance standpoint, bring the CPU to its knees).
• Programs (signed and DRM’d) can only be obtained from the iPhone App Store (although free applications are possible even under this restricted-distribution model).

Gaming on handhelds as a concept has long drawn industry attention, but to date I’ve never personally been a big fan of the idea, and the hype-to-reality ratio has to date also been unpalatably high. My contacts at the Khronos Group have been beating the drum for years, and they’ve done great work at standardizing the various APIs that virtualize the specific hardware executing various multimedia functions. But when I press them for details, even they admit that their efforts only provide some of the necessary puzzle pieces.

Look at a collection of mobile phones, or think back to all the ones you’ve owned so far. Their user input and display facilities (for example) are completely different, right? This discrepancy means that developers must code vendor- and model-specific versions of their applications (unless they go with a performance- and feature-strapping approach such as Java, which has plenty of compatibility issues of its own), increasing both development cost and time, narrowing the per-version potential market size, and complicating both the requisite distribution and after-sale support scenarios.

I’ve long thought that Windows Mobile might cultivatee a critical-mass market that would ignite the smoldering gaming-on-handheld flame, but this vision largely hasn’t come to pass. One key reason is that the DirectX Mobile and Direct3D Mobile APIs are extremely immature compared both to their full-blown Windows brethren and to Khronos-developed equivalents (which of course Redmond doesn’t support), and Microsoft’s commitment to maturing its mobile APIs has been weak and inconsistent. Plus there’s the divergent user input scheme issue to consider, along with the plethora of available screen sizes, resolutions and native orientations.

The iPhone SDK, along with the to-date and continuing success of the hardware it targets, is likely to enable Apple to succeed where Microsoft failed. OpenGL and CoreAudio support expose the iPhone’s graphics and audio hardware to rich, limited-overhead third-party interaction. And, following the model it pioneered with computers and then iPods, Apple intentionally offers only a limited suite of hardware options, thereby further simplifying developers’ challenges.

I don’t anticipate that the second-generation iPhones will make substantial upticks to the first-generation device’s graphics capabilities, in part so that developers can craft code that’ll run acceptably across the product line. And games won’t be the only graphics- and sound-rich software 3D applications that’ll harness the SDK in order to tap into hardware acceleration. General-purpose application UIs, for example, will employ 3D in order to maximize the functionality of the devices’ limited-size screens.

I’m excited to, six months from now, see what sorts of code iPhone developers have crafted. I highly doubt I’ll be disappointed.