From John Nack's blog: "In the interest of giving customers guidance as early as possible, we have some news to share on this point: in addition to offering 32-bit-native versions for Mac OS X and 32-bit Windows, just as we do today, we plan to ship the next version of Photoshop as 64-bit-native for Windows 64-bit OSes only."

Well to be fair, Apple has been touting XCode for the last 8 years and wasn't shy about pushing developers to using them over CodeWarrior. Not to mention the fact that they've been pushing developers to use Cocoa over Carbon, and after killing 64-bit Carbon last June, this should have been no surprise.

I'm not making excuses for Apple, and I'm sure Adobe has some good reasoning behind this, but this childish "blame the other company for [insert excuse here]" bit is getting old between these two companies.

Well to be fair, Apple has been touting XCode for the last 8 years and wasn't shy about pushing developers to using them over CodeWarrior.

Xcode and CW are IDEs; Carbon and Cocoa are APIs. While you're correct that Apple have been pushing CW users to move to Xcode for a while, this has nothing to do with what APIs you use.

Not to mention the fact that they've been pushing developers to use Cocoa over Carbon,

For new development, sure. For existing applications, not so much. I think even Apple appreciate that tossing extremely mature, reliable and optimised codebases that work without extremely good reason is not a sensible way to run a business.

and after killing 64-bit Carbon last June, this should have been no surprise.

The surprise itself was that June announcement, which was a total 180-degree reversal of everything Apple had said and promised up until then. Don't forget that previous Leopards seeds were being shipped to Adobe and other developers with 64-bit Carbon GUI support already largely in place. I don't imagine the Carbon engineers were best pleased seeing a large chunk of their handiwork suddenly flushed down the drain either, but at least Apple was paying them to grin and bear it.

...

To be fair to Apple, I doubt they made this decision lightly either. My guess is that with their OS teams spread increasingly thinly across expanding and divergent product lines (Mac, iPod, iPhone, etc.), there was a pressing need to reign in that workload ASAP, lest it get completely out of control (c.f. Copeland et al). I mean, I've no idea who the poor devil was that got to inform Jobs that Leopard would be six months late, but I bet they're still sponging him out of the carpet even now. No, not an easy decision at all.

None of this, however, is of any help or consolation to the unlucky recipients of last WWDC's surprise kick to the crotch. At the very least, a heartfelt "mea culpa" from Apple and straight-up explanation of why they had to make this move would have gone some way to lessening the bruise.

Apple may have learned a lot about shipping successful product since the bad old days of the early 90s, but they've still a lot to learn about building developer trust and relations. Treating third-party vendors as valued partners in expanding OS X into a major mass-market computing platform - not making them feel like unwanted irritants that may be swatted down at any moment - would be a good start.

...
Apple may have learned a lot about shipping successful product since the bad old days of the early 90s, but they've still a lot to learn about building developer trust and relations. Treating third-party vendors as valued partners in expanding OS X into a major mass-market computing platform - not making them feel like unwanted irritants that may be swatted down at any moment - would be a good start.

Isn't that the truth. ADC relations people are sometimes very rude and policies change far too often.

It's nothing new either. In the 1980s and early 1990s, they were as bad. They're only truly nice to the Premier developers.

This is pure nonsense, as Photoshop performance on Apple systems is the killer app of them. I think they are in love with certain company or something, this radical change is weird.

I think Apple is probably doing negotiations in some way with Adobe for trying to resolve this. If not, Apple will purchase a small companies with quite interesting alternatives to Adobe products and improving it a lot by brute force (a lot more devs in the team) or a new development from scratch (less probably knowing the typical Apple's way).

They're not stopping development of Photoshop on the Mac. From the article:

We will get there, but not in CS4. (Our goal is to ship a [u]64-bit Mac version with Photoshop CS5[/u], but we’ll be better able to assess that goal as we get farther along in the development process.)

What this means is that the change from Carbon to Cocoa is taking longer than expected, and a 64 bit version of CS4 is not going to be available. Instead, users will need to wait till CS5 is released.

This should be very interesting to watch. Will Apple buy out other companies and roll their own Photoshop equivalent? Aperture is already competing with Lightroom, so the idea of Apple rolling their own Photoshop competitor isn't so far fetched.

There doesn't seem to be a huge issue here. Adobe isn't giving up on a 64 bit version for the Mac, It's just going to take longer due to Apple choosing to not implement 64 bit Carbon, and Adobe taking so long to rewrite their code to make use of Coccoa instead.

Some of Apple's own applications are still written on top of Carbon libraries, and I guess to an outside company, also using those APIs would take the "if it ain't broke, don't fix it" route.

It doesn't seem like either one of the companies is really at fault here, just a case of "shit happens." It may be irritating for Mac/PS users in the short term, but in the grand scheme of things, I doubt it's going to be a big issue.

I'll disagree here. Event though this article is very polite about it, it seems clear to me that this is 100% Apple's doing. They've built up way too much hubris over the years and thought, "what the hell, let's just ditch the Carbon API, we don't give a damn about how hard that will make it for Adobe and the other 3rd-party software companies." They never bothered to think about the fact that the cross-platform benefits of the Carbon framework *might* be missed.

If this were Microsoft this would *never* happen. They cater to their 3rd party developers; that's why they have so many of them.

For the first time (finally) we're seeing Apple's isolationist strategy coming back to bite them. I love Apple's design philosophy and their products, I'll even give them credit for their "idealistic purity" in this particular matter, but seriously, sometimes it just pays to be pragmatic....

Microsoft drop support for legacy APIs all the time. There's plenty of stuff out there that Microsoft don't maintain anymore, and that isn't supported by their current development tools.

Old apps can keep using them, but they can't expect to be able to use modern development tools, libraries, or even to work on 64-bit Windows.

Microsoft's idea of backwards compatibility, aside from causing all kinds of problems with forward compatibility, is binary only. Microsoft do not, and never have, claimed source backwards and forwards compatibility.

Besides, Apple are being pragmatic. They can not possibley afford to lug the backwards compatibility albatross around with them. Microsoft can't afford to either (see recent article on Windows 7), so what chance do Apple, a hardware company with a tiny fraction as many resources have?

Microsoft typically directly supports its products for 7 years. When it comes to APIs, they only ever really break compatiblity every 10 years or so.

Apple typically supports its products for about 2 years, and they break API compatibility with EVERY release, which typically means once a year.

Linux is the worst when we are talking about ever-shifting APIs, the linux API will often break compatibility in minor bug fix releases.

When you look at it this way, you see why Linux has next to no commercial support, Apple has a moderate amount (although mostly from small shops with agile teams), and Microsoft is the one that ISVs love the most.

Apple typically supports its products for about 2 years, and they break API compatibility with EVERY release, which typically means once a year.

Eh, what? Tell me what broke during the transition from Panther to Tiger? From Tiger to Leopard? Apple releases a new version of OS X every year? There isn't an ounce of truth in anything that you've said.

The fact that there are applications that work on Leopard and not on older systems has little to do with broken APIs. It's because Apple is introducing new APIs and in the case of Leopard, Objective-C 2.0 which developers willingly adopt that makes it impossible to support older versions of OS X. If the developers were so inclined, they'd ignore the new APIs/features and target 10.2+. It is still possible, but nobody does it since most users rarely lag by more than one OS X version.

Linux is the worst when we are talking about ever-shifting APIs, the linux API will often break compatibility in minor bug fix releases.

No? You're confusing API with ABI.

When you look at it this way, you see why Linux has next to no commercial support, Apple has a moderate amount (although mostly from small shops with agile teams), and Microsoft is the one that ISVs love the most.

If Microsoft could have dumped Win32 and MFC support, they would have gladly done it years ago.

Eh, what? Tell me what broke during the transition from Panther to Tiger? From Tiger to Leopard? Apple releases a new version of OS X every year? There isn't an ounce of truth in anything that you've said.

Apple releases a new version every year to year and a half (not counting leopard). And to answer your question, pretty much everything breaks. Six months after a new version of OSX comes out, you can not use any new versions of pretty much anything unless you upgrade.

The fact that there are applications that work on Leopard and not on older systems has little to do with broken APIs. It's because Apple is introducing new APIs and in the case of Leopard, Objective-C 2.0 which developers willingly adopt that makes it impossible to support older versions of OS X. If the developers were so inclined, they'd ignore the new APIs/features and target 10.2+. It is still possible, but nobody does it since most users rarely lag by more than one OS X version.

For the most part, you are wrong. If you are talking about an API that is being kept around for compatibility (like carbon), that will not change from version to version. But Apple introduces breaking changes with every release. I have friends who are commercial apple developers, and have heard the woes first hand.

No? You're confusing API with ABI.

To a major vendor, there is little difference. Hardware companies do not make money from software, they make software to sell hardware. Linux makes drivers a maintenance nightmare, due to the fact that you may need to release a new version at any time.

If Microsoft could have dumped Win32 and MFC support, they would have gladly done it years ago.

Backwards compatibility has been the mantra at redmond pretty much since day one, often to a fault. From a purely technical point of view, Apple and Linux have the better approach. If something is broken, or poorly designed, you fix it. If that breaks existing apps, then it is their responsability to keep up to date.

To a major ISV like adobe, an API shift means a massive amount of work with very little visible gain to the end user. That is not the way they like to spend their money, and perfer to only update when they absolutely have to.

Don't get me wrong, I love apple passionately (look at my avatar, that was the first computer I owned, and to this day one of the best I have ever used). As an engineer, I perfer to rewrite when something is not as good as it could be. The idea of preserving a bug accross revisions for the sake of compatibility is just wrong. But that doesn't change the fact that from a practical sense, the microsoft way makes far more sense to a large ISV.

Like I pointed out in my last comment, the reality of the software world backs me up. Apple software is mostly done by small, agile shops who can keep up easily. Linux software is mostly done by engineers on their free time. And Microsoft has hands down the most commercial support for their platform.

They never bothered to think about the fact that the cross-platform benefits of the Carbon framework *might* be missed.

Yeah, because people are still writing MacOS 9 apps. The point of Carbon was it was an easy transition between OS 9 and OS X. It was always known that it would become less and less relevant over time and that you were supposed to use Cocoa whenever possible.

If this were Microsoft this would *never* happen.

Have you already forgotten the complete dropping of Visual Basic? VB.NET is a completely different language.

They cater to their 3rd party developers; that's why they have so many of them.

No they don't, they cater to their own needs and drag everyone else along for the ride. They have so many developers because they eliminated the competition in the mid 90's, leaving no where else for the developers to go.

10 years ago, when Apple was readying the first release of Mac OS X, Apple actually didn't want to do Carbon. Adobe then said to Apple that Mac support for all Adobe applications would be dropped if Apple didn't comply.

Now Adobe is willing to rewrite. Interesting how the attitude of Adobe changes when MS enters direct competition (XPS vs. PDF, Silverlight vs. Flash, Expression vs. Creative Suite) and Adobe actually needs its user base to diversify, becaus if Adobe forced all users to go Windows-only it would just be a matter of time they prefer MS' own stuff. First porting Premiere etc. back to Mac OS X and now this.

It's not that Adobe didn't have time or Apple didn't push them. It's that Adobe wanted to reap great rewards from poor and very old code.

When Adobe brought out Photoshop 7 around 2001, it was the first version that ran under the Carbon libraries, so that it could be a native Mac OS X application. It also ran much more slowly as if Adobe added the "include carbon.h" line in the source code and linked to the carbon libraries without doing anything more. Photoshop 6 in the Classic environment, with Mac OS 9.x as a host, ran faster.

The application became a progressively worse performer through CS and CS2, showing that it was never really re-written for Mac OS X but patched.

After a very long delay, the CS3 version finally works reasonably well, but doesn't remain completely idle--always taking around a minimum of 3% CPU--unusual for a Mac OS X application.

The on again/off again decision from Apple concerning 64-bit Carbon is a pain but Adobe knew what was ahead and they chose to do the cheap thing, again.

So the upshot of this news is that if you need high performance computing with photoshop (ie, want it to properly take advantage of your 64bit 8 core 32GB ram machine) it might be a good idea to install windows XP64bit on Vista64bit until photoshop cs5 makes it onto OSX, its just lucky( and forward thinking) apple makes it really easy to burn off the drivers for windows so you can wipe OSX and do a clean install of windows, or use bootcamp.

Everyone is talking like the 64 bit version is going to be three times faster than the 32 bit one. For the average CS user the difference would hardly be noticeable.

People have weird expectations about 64bit apps and OSes in general. Lots of people seem to think it would atleast double the speed of their computer if they started using 64bit apps but that just is wrong. Most apps will not benefit from it at all, 64bit instructions mostly only benefit if you have to do lots of maths. In the case of CS it would likely only benefit things like filters, and even then only marginally. The GUI itself will not be any more responsive or anything than in the 32bit version, neither the generic tools available.

The good thing about 64bit CS is that it allows CS to access a lot more memory at once without the OS having to do paging. So, if you are manipulating several very high-quality images it might benefit you. Still the benefit will most likely be negligible.

I completely disagree. The effects are negligable for something like word processing. If you are doing anything even remotely professional with CS, you are going to feel the difference for anything involving encoding or other extremely CPU intensive tasks, let alone the difference the extra ram makes.

CG animation and frequent compiling, and gaming are the only areas I can think of where it would make as much of a difference.

Ignoring the Lightwave anomaly, going to 64 bit gets you an average of 5% performance increase in 3d modelling applications, about 10 - 20% increase in encoding performance, and +/-5% performance in games.

There are times when 64 bit processing will help (particularly with 64 bit integer heavy code), but for most applications the gains will be marginal to nonexistent.

In the general case, yes. When talking about x86 processors, not true. In 32 bit mode, an x86 processor has 8 general purpose registers to work with. That's not much, and limits the efficiency of code. When in 64 bit mode, you've got 16 registers. You get about a 20% speed increase just from that. If we were still talking PowerPC here, then yeah, 64 bit wouldn't help.

64bit instructions mostly only benefit if you have to do lots of maths. In the case of CS it would likely only benefit things like filters, and even then only marginally.

What do you think filters are, if not lots of math?

Yeah, 64 bit helps when doing math on huge numbers - which Photoshop probably doesn't do - but the bigger help is when using lots of memory, which Photoshop is known for.

Just thinking about it, I realized that this would be a perfect situation for Adobe to widen its usage of Qt. Qt already supports 64-bit native Cocoa bindings in its next version, it's much more cross-platform than any other C++ solution out there, and Adobe already uses it for Photoshop Albums....