John makes many good points and discusses the subject very thoroughly. If the question interests you, I highly recommend you jump through the above link and read the article. I'll wait for you to come back here when you're done reading.
Done reading? Great.
During the article, John writes:
Cocoa was not magic pixie dust that inherently made the Finder radically better. But so why did Apple bother? Because Cocoa and 64-bit are the future of Mac OS X. And, for many new APIs, they are the present.
This is a very plausible explanation for why Apple chose to port nearly all of the system applications to the 64-bit Cocoa libraries. It is also really good marketing PR - what better way to encourage others to use your new libraries than to point our that you yourself are using them everywhere.
But there's another possible reason that I think may make even more sense: the need to test all those new libraries.
The 64-bit Cocoa APIs are brand new. As such, they need to be thoroughly tested. What better way to test them than to use them in as many applications as possible? Since the outside world doesn't have the new libraries, there won't be any third-party applications using them, and real-world applications almost always provide better testing than contrived test cases.
With all the system apps using the 64-bit Cocoa libraries, it means developers and testers will be exercising these new libraries with every app they run. Additionally, it guarantees that the application code is portable to both 32- and 64-bit environments, since Apple will still have to ship and test 32-bit versions of them. (Some of the early-model Intel-based Macs only have 32-bit processors.)
If they didn't port all this code to 64-bit Cocoa, then the 64-bit Cocoa libraries would end up shipping with a lot less testing. This would result in bugs being discovered post-release, as third-party apps are developed. That's something no developer ever wants to have to deal with. Aside from the embarrassment, sometimes you find bugs where the best fix is to change the API in a way that breaks applications. This isn't a problem if the API hasn't been released and the only apps are your own. It is difficult, often impossible, and always embarrassing to do this after you have shipped those APIs to customers. Once an API is shipped to customers, its published interface can't change, forcing you to fix the bug in other ways, which may be awkward, less efficient, or downright hack-ish.
As for why Apple didn't port iTunes to 64-bit Cocoa? My guess is that iTunes 9 was under development for quite some time, while the new APIs were still in a state of flux. If you've got a release schedule to meet (and iTunes 9 had to ship on the same day as the new iPod announcements) then you don't want to attempt porting to a potentially unstable platform. Far better to ship on-time and then begin your porting effort afterwards.
Will iTunes be ported to 64-bit Cocoa in the future? It wouldn't surprise me, but there may not be an overriding need to do so at this point. Now that the 64-bit Cocoa libraries have shipped, the "libraries need testing" argument no longer applies, so we're back to the "how will it improve the iTunes app itself" argument. John's article discusses this at length and provides a good explanation, so I won't repeat his arguments here.
No comments:
Post a Comment