Apple started selling 64 bit machines in 2005 and supported it in the operating system with Leopard: http://theocacao.com/document.page/343
There weren’t many 32 bit only Intel based Macs.
This complaint says far more about the developer than Apple.
There weren’t many 32 bit only Intel based Macs.
This complaint says far more about the developer than Apple.
I don't understand, why Apple even created x86 osx ABI.
When they introduced the first x86 Macs, the writing was already on the wall; in the same way, that there are claims that Carbon was deprecated for years, x86 was in the door on its way out. You would not create a new Carbon-based app today, Apple introduced ABI in similar circumstances? Well, maintaining it then for decades to follow comes with the territory.
Yes, as an user, I do mind removing it. For example, Apple had broken Preview scanning on Samsung MFPs for the entire Mojave lifecycle ([1], [2]), there's no indication that they are going to fix it, and as a workaround, users are using Samsung Easy Document Creator, which talks directly to scanner, avoiding Apple scanner libs. Yes, it a 32-bit app.
[1] https://discussions.apple.com/thread/8552818 [2] https://h30434.www3.hp.com/t5/Samsung/Scanning-problems-with...
Ah yes had forgotten that (the Apple Intel Dev Boxes were P4's)
Xeons arrived with Mac Pro.
> The people I hear complaining about this are those who, like you, didn't move to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac OS X shipped in March 2001, but even though it wasn't yet formally deprecated, it was clear it would be.
- https://lists.apple.com/archives/cocoa-dev/2019/Oct/msg00021...
At market-rate developer salary, it doesn't take a lot of man months for the port not to be worth the investment for small shops.
The reality is that Turtle couldn't make the business case to port to Cocoa at any point for 18 years, probably because most of their customers were Windows.
That's not them being lazy, that's just them directing their resources according to market demand and engineering constraints.
And Apple is not being greedy or uncaring, they also have to direct resources according to market demand and engineering constraints.
If Turtle had more Mac customers, they'd have either ported their app, or they'd purchase a Carbon compatibility library. And if more developers were actively using Carbon, Apple would put more resources into it.
They aren't, and so the two are going to part ways.
I think that guy lives in a bubble, Microsoft is still by a huge margin the lead in desktop OS market share :-P.
And really the main reason is that they try their hardest to not break people's applications. If Windows suddenly couldn't run the applications people wanted, everyone would migrate to Linux (and some to Mac, but Linux is free so the majority would go for the free stuff).
Now when I get an exe that needs to run in compatibility mode I don't even bother with it. I'm not compromising my computer because a developer has abandoned their software.
Yeah, the arc was that Cocoa was the future, but as late as 2007, Carbon was still widely considered a viable target for new apps.
Yes, it says that they didn't bother to waste resources doing unnecessary changes.
But it also says about Apple that they do not respect the time and resources of the developers that bother to support their platform.
There is no way to spin Apple breaking APIs and programs that people have worked on (for developers) and bought (for customers) in a positive way.
Keeping up with API changes from a decade ago doesn't qualify as unnecessary.
> There is no way to spin Apple breaking APIs and programs that people have worked on (for developers)
Here's the point. Apple isn't doing that. Apple don't visit customers with old macs to push breaking patches.
What happened is the developers made something that worked on old macs, didn't put in the effort to keep it up to date and are now complaining that Apple won't put in the efforts to support the old APIs on new systems anymore.
> and bought (for customers) in a positive way.
This is the developers fault I guess.
The API didn't change, it worked until Apple decided to break it in a subsequent version of macOS.
> Here's the point. Apple isn't doing that. Apple don't visit customers with old macs to push breaking patches.
They broke the API in new macOS.
> What happened is the developers made something that worked on old macs, didn't put in the effort to keep it up to date and are now complaining that Apple won't put in the efforts to support the old APIs on new systems anymore.
Yes, that is exactly the issue: Apple shouldn't have broken the API in the new macOS. The developers are perfectly in their right to complain about Apple breaking their applications and forcing them to waste time rewriting code that already worked to do the exact same thing only now in a different way because Apple doesn't care about the developers' time.
And yes, it is all on Apple - the breakage wasn't forced on Apple, it was something Apple decided to do.