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.
Add New Comment
Viewing 3 Comments
Thanks. Your comment is awaiting approval by a moderator.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
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)
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
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.
Add New Comment