Obligatory WWDC Wrap-Up and Leopard Analysis

Posted on August 16, 2006 by schwa

Everyone else is doing it so I figure I ought to.

This was my seventh WWDC and was definitely the most social one I’ve attended by far. I met a tonne of people (mostly guys from #macsb who I’d known virtually for almost year or so) including a lot of developers whose work I really respect.

Buzz’s weblogger’s party was a great success, and I managed to stay mostly sober this time. I’d really like to thank Buzz and co. for doing such a great job and I hope this remains a Monday night WWDC tradition.

Gus Mueller did a great job introducing me (and everyone else) to every single attendee at WWDC (all 4000+ of them). The list of everyone I met this year is too long to post (or remember).

I can’t talk too much about Leopard (that dreary NDA thing gets in the way) but it looks really great so far. From a user’s perspective Leopard is good (Time Machine is something we’ve wanted for a long time), but from a developer’s perspective, WOW. I spent the first day after the Keynote and the “State of the Union” sessions being stunned and overwhelmed by all the new technology. There are so many goodies in 10.5 for developers that Apple have made it a very hard for developers to continue supporting 10.4. It will be a constant struggle to keep my head out of the clouds and remember that the end-users are still running 10.4 and won’t be upgrading en-masse for a long while (excluding those who have “found” a copy on bittorrent).

However, predictably Apple has gone and stomped on my toes. A few of the frameworks and Cocoa classes I’ve developed over the years have been superseded or replaced by code in 10.5. This is generally a good thing, once 10.5 ships it’ll be relatively easy to switch to Apple’s code and then abandon my code (probably into my code graveyard). Supporting my own code has some advantages, mainly I can support 10.4 and older OSes if needed be. I’m still trying to decide what to do with my public code that has been duplicated by Apple, should I support it – or abandon it now? There is certainly a lot of life in my code before Leopard ships.

This entry was posted in Default and tagged , . Bookmark the permalink.
  • My suggestion would be to try to position your code that works close to how Apple's works as a compatibility layer for older OS versions. I.e. I wrote my Carbon-based speech synthesis class in a way that allows exchanging it for NSSpeechSynthesizer pretty much straight. The only difference is mine has a few additional features (which is why I haven't switched to Apple's code yet).

    Of course, you can't really do that yet, since the new APIs haven't been announced to the general public and may be subject to change (*and then there's that pesky NDA thing), but you could try getting a head start at least.
  • It can be difficult to decide which versions of the OS to support when a new version is released. As I was unable to attend WWDC I haven't seen all the new APIs but it certainly appears from what I have read that there are some large changes in some areas. Probably not all, but certainly some, of the new APIs will be applicable to any application going forward and so it becomes a question of how much work the developer wants to put in to supporting Tiger. There are already numerous applications that only run under Tiger so I don't think Panther is a consideration for new development. Then there is the line of thinking that if the user won't even upgrade their OS is it likely they will pay for your software? I think if there are enough compelling features you will add to your applications under Leopard that would require a lot of re-inventing to support under Tiger that it is fine to only provide thse features under Leopard. Perhaps branch and continue the Tiger support only with maintenance releases and place all new development into the Leopard branch.
  • In the past, Apple has implemented a lot of the methods which I'd usually attach to the kits with categories. But yeah, this can happen with any bit of code -- Cocoa changes so quickly these days!

    When the new release ships with the stuff which obsoletes the old code, I try to make the old code perform as closely to Apple's implementation as I can, and toss it in the "compatibility" bin. You never know when you'll have to support some legacy release. It's still too early to call what the Leopard adoption rate will be (although I don't doubt that it'll be great -- I don't think we saw 20% of the user-facing features at WWDC), so that code will continue to be worthwhile until at least a year from now. If it's good, well-tested code, it'll continue to be worthwhile until at least 10.5.3. ;)

    Usually I ditch code that's two major OS releases old, chances are it hasn't seen much action lately anyway and bugs have doubtless crept in. And I'm not sure what you're obsoleting, but there is something that's coming that's replacing something you might be thinking of obsoleting because it's internally nasty, but someone said it would be available independently of an OS release, as it usually is for this something. (I didn't say anything)
blog comments powered by Disqus