I was chatting with my TUAW colleagues this morning about Mac versus iPhone programming. And as per usual with these conversations, we veered in the direction of unfettered speculation. It's an occupational hazard.

As someone who regularly develops on both platforms, I declared that the iPhone represents the future of Mac programming. The iPhone, I posited stated, offers a great new platform without the need to be fully backwards compatible like the Mac. Our own Victor Agreda challenged me to back up that position. After a bit of time and thought, I decided to do so in this post.

My key point is this: Apple's engineers have learned a lot of important design lessons during the history of OS X. When the iPhone debuted, it gave those engineers the chance to rebuild an OS and an API from the ground up. Those engineers could craft a platform and its libraries that built on the Mac's successes without dragging along its less fortunate design decisions. Yes, there were some lemon frameworks that initially made the grade, but over time, Apple has reduced their number.

Even now, Apple continues its iPhone design process, adding new frameworks and APIs at a prodigious rate. The iPhone OS remains a work in progress, developing in ways and directions that the initial release two years ago could not have anticipated. And Apple does this, knowing fully that the closed platform allows them a great deal of design freedom that would not have been possible on the open Macintosh.

In contrast, consider in how many ways the Mac's successful history drags the platform down. A commitment to existing APIs and historical design practices show up in nearly every Mac development project. The simple elegance of the iPhone's built-from-the-start-as-Objective-C 2.0-based API is largely missing from Cocoa libraries.

Whether you're working with buttons, menus or simple text views, the iPhone development approach simply works better: beautiful 2.0-style properties, consistent API design, better-thought-out object inheritance trees, and so forth. With the iPhone, you see a great new platform evolving without the need to be fully backwards compatible

Snow Leopard, with its minimal API changes has bought the Macintosh a few years of stability. But I think it's time for Apple to rethink the platform as a whole, re-imagining its API through the lens of current iPhone OS development. While Snow Leopard offers Apple the room to stay still for now, I can see Apple moving forward in a separate engineering effort to Cocoa Touch Mac, a hypothetical cross-platform OS that supports general development on iPhone and future Mac devices like my imaginary snow-princess-rainbow-pony-iTablet.

The ghost of NeXT-past, as TUAW-colleague Joachim Bean puts it, still haunts us. It's time to exorcise the unhelpful bits of that pervasive spirit and usher in the new age of the iPhone and its API design examples. Mac OS X is, and has been, a superb development platform. What I'm suggesting is that iPhone OS might just be a better one.

Reports are surfacing on the web that, while everything Apple showed on stage at WWDC 2006 was exciting and purty 'n all, the more exciting attractions are what wasn't shown on stage. AeroExperience, a Vista developer resource site (of all places), claims to have an exclusive list of many of the underlying changes, newly introduced APIs and other developer goodies that might simply not have been prime fodder for the news and PR spotlight session of the keynote.

It's a pretty lengthy list, so here are some of the highlights for you cliffnote readers out there:

• Leopard will feature resolution-independent user interface and there are several functions to get the current scaling factor and apply it to pixel measurements (we've mentioned how cool this is before, and so has Mr. Gruber).
• Address Book adds support for sharing accounts, allowing an application to restrict content according to user (.Mac already does this, so I'm wondering if they mean some kind of framework or protocol is in place to open this up to something like WebDAV or simple FTP).
• Automator includes a new user interface and allows things such as action recording, workflow variables and embedding workflows in other applications.
• Time Machine has an API that allows developers to exclude unimportant files from a backup set which improves backup performance and reduces space needed for a backup (I was curious about how Time Machine would handle 'useless junk' types of files myself).
• Carbon, the set of APIs built upon Classic MacOS and used by most 3rd party high-profile Mac OS X applications, now allows Cocoa views to be embedded into the application. This could provide applications like Photoshop and Microsoft Office access to advanced functions previously only available to Cocoa applications.
• Text engine improvements include a systemwide grammar checking facility, smart quote support, automatic link detection and support for copying and pasting multiple selections.
• Mail stationery is open to developers, allowing any web designer to create fantastic-looking Mail templates, with defined areas for custom user content (bring on the stationary plugin packs!).
• A new framework is included for publishing and subscribing to RSS and Atom feeds, including complete RSS parsing and generation. Local feeds can be shared over Bonjour zero-configuration sharing and discovery (I suspected something like this; sounds like Safari and Mail.app might share the same RSS database, as can other apps, so users don't have to waste time exporting/importing between RSS apps).

Check out the full list at AeroExperience for more of the potentially rocking Leopard features that Steve and company didn't show on stage.