> No, including an interpreter like they did (Rosetta) was an alternative.
The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.
That was the sane reason that Jobs made it almost impossible to port legacy text based software to early Macs. Microsoft jumped onboard developing Mac software and Lotus and WordPerfect didn’t early on.
But today you would have to have emulation software for Apple //es, 68K, PPC and 32 bit and 64 bit x86 software and 32 bit and 64 bit ARM (iOS) software all vying for resources.
Today because of relentlessly getting rid of backwards compatibility, the same base OS can run on set top boxes, monitors (yeah the latest Apple displays have iPhone 14 level hardware in them and run a version of iOS), phones, tablets, watches and AR glasses.
Someone has to maintain the old compatibility layers and patch them for vulnerabilities. How many vulnerabilities have been found in some old compatible APIs on Windows?
> The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.
I don't see that as a downside; I see it as a strength. Why should everyone have to get on the library-of-the-year train, constantly rewriting code -- working code! -- to use a new API?
It's just a huge waste of time. The forced-upgrade treadmill only helps Apple, not anyone else. Users don't care what underlying system APIs an app uses. They just care that it works, and does what they need it to do. App developers could be spending time adding new features or fixing bugs, but instead they have to port to new library APIs. Lame.
> Someone has to maintain the old compatibility layers and patch them for vulnerabilities.
It's almost certainly less work to do that than to require everyone else rewrite their code. But Apple doesn't want to spend the money and time, so they force others to spend it.
This may come as a surprise to you, but the vast majority of users absolutely hate it when their software changes.
They don't want all new interfaces with all new buttons and options and menus.
People get used to their workflows and they like them. They use their software to do something. The software itself is not the goal (gaming excepted).
I'm not suggesting that things should never be gussied up, or streamlined or made more efficient from a UX perspective, but so many software shops change just to change and "stay fresh".
I'm not sure why you're responding to me. Nothing that you're saying is anything that I've mentioned or brought up. I know what the downsides are. I'm just saying that the goals that Apple has optimized for have resulted in a loss of things that many would consider valuable.
The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.
That was the sane reason that Jobs made it almost impossible to port legacy text based software to early Macs. Microsoft jumped onboard developing Mac software and Lotus and WordPerfect didn’t early on.
But today you would have to have emulation software for Apple //es, 68K, PPC and 32 bit and 64 bit x86 software and 32 bit and 64 bit ARM (iOS) software all vying for resources.
Today because of relentlessly getting rid of backwards compatibility, the same base OS can run on set top boxes, monitors (yeah the latest Apple displays have iPhone 14 level hardware in them and run a version of iOS), phones, tablets, watches and AR glasses.
Someone has to maintain the old compatibility layers and patch them for vulnerabilities. How many vulnerabilities have been found in some old compatible APIs on Windows?