Copyright 2004 by M. Uli Kusterer Fri, 29 Nov -1901 11:06:32 GMT Comments on article blog-adobe-on-carbon-64-bit at blog-adobe-on-carbon-64-bit Comments witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) en-us Comment 2 by Uli Kusterer Uli Kusterer writes:
JulesLt, the issue with what you call a "smaller and more manageable codebase" is that they already have the code, it works, it's been bullet-proofed. They need to write it for the other platform anyway. All they'd get from using Apple-specific tech would be inconsistencies between the two platforms, and the inability to fix bugs in the code, because most of it sits opaquely in Apple's framework. If it's their own code, Adobe can choose to hire someone to fix it right now. If it's in Apple's code, they have to wait until someone at Apple gets around to it. A DTS incident may speed that up, but it's still on Apple's schedule.

I agree that it would be easier to just not be cross-platform, but then it's always easier to drop features than to get them right.
Comment 1 by JulesLt Well, one argument would be that you should, theoretically, end up with a smaller and more manageable modern code-base, which would reduce costs going forward. And for a product on the scale of CS, the cost per customer would be low, even though it would be a huge endeavour.

However, as John Gruber's post also notes, Adobe's CS apps use their own cross-platform application framework already, so this isn't the case of just porting an application (as it will be with Final Cut) to Cocoa, but bending Cocoa to behave as per Adobe's framework.

The cross-platform side also holds them back from being able to use technology like CoreImage to cut their development costs.