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)
Stephan Cleaves
· 3 years ago
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.
Uli Kusterer
· 3 years ago
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.
All Comments
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)
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.