In the modern (all iOS and 64-bit macOS) runtime the ivar offsets are patched up at runtime so the layout of classes (including base classes) can change without breaking compatibility.

Working around the limitations of the 32-bit Objective-C runtime imposes significant costs, it is far from a simple recompile with a different pointer size. It also adds a lot to the size of the installed OS.

In a way, this is the true last step of the Mac OS X transition that started in 2001--the removal of the transitional APIs that made it possible.

Theoretically would’nt programms written in pure Swift today be able to compile for any new hardware plateform, thus avoiding the kind of issues that 32/64 switch faced?

The educational story of this sort is the transition between python 2 and 3... not ever done for some packages.

[1] http://lowendmac.com/2006/core-duo-macs/

https://arstechnica.com/gadgets/2009/08/mac-os-x-10-6/5/

If you want to find unusual problems with older Apple hardware for the sake of reusability, take a look at the firmware from around that time. It was just weird enough to make it similar to standards but often too difficult to support a decade later. In a decade, people are going to say the same about the not-quite NVMe SSD interfaces in current Macs.

Anyhow, I doubt they'd have had time to make a solid 64bit x86_64 SDK even if they had delayed the hardware to late 2006. They had never stopped maintaining the x86 port of OS X (aka Rhapsody, Open Step, NeXT Step), just stopped shipping it as a product, because their strategy was and still is to package their OS in hardware boxes. They started shipping x86 boxes to developers in the form of the x86 development box, which was a (32bit) Pentium 4 shoehorned into a Power Mac G5 case. Its OS is also what leaked to the early x86 hackintosh scene; before Apple shipped their own x86 Macs. I ran it on an custom Athlon64 box and a ThinkPad T42.

Since they already had the x86 port, it was an easy switch at a time when all x86 hardware from Intel was still 32bit. If they knew Intel would adopt x86_64 from AMD, one option could've been to ship with AMD CPU's on the first models, but I'm not sure how well that'd have turned out logistically or whether it'd have made a huge difference.

We have 20000 Mac users in a company of 90000, I don’t think this is a corner case for large technology companies.

My machine is managed in the sense some things are preinstalled and IT has a way to push software updates.

What more management is required? Anything more and IT would probably fuck it up like they did when our division was still on Windows.

Not saying your company has to be like this. Just saying 1) this is where MS has very little competition, and 2) where they make absolute bank.

Company size doesn't have much to do with this. Macs are popular at IBM.

140,000+ employees in this company. Macs outnumbers Windows boxes. Pretty much the only place you see Windows machines are in the various accounting departments, and in the call centers where they're just used as terminals to big iron.

At least as one gets older and just want to get that thing done that they always have (a certain big name author still writes using WordStar in DOS i believe).

Do they really, or is it just that consumers are more likely to be persuaded by Apple's marketing?

Personally, I have some apps which I use regularly, and are at least 20 years old. I use mostly Windows for that reason too.

My Ubuntu netbook is nice for travelling purposes, but for the kind of work I get paid for, it is Windows and occasionally macOS.

Given that a lot of current Macs come with only 8GB of ram it is not ideal to run a lot of applications in a virtual machines, but applications that need much RAM have almost certainly moved to 64bit anyway.

Again, someone else will understand it better, but I think products like Veertu were built on Apple's built in hypervisor framework, and it would not be difficult for people to build additional free virtualization options in MacOS. My point is that the reasons for choosing Linux over MacOS are already sufficient without targeting users of older Mac software, and that people who are using older Mac software probably also use new Mac software, and won't have too difficult a time using the older stuff too.

A while ago I would have said that something like Wine would be great for using the best software I can ever remember which only ran on early Macs. Except that these days you can do that in Javascript in any browser, and while the software was good, I've already spent a few weekend afternoons playing with them, and I don't need to anymore.

I miss my 32bit iOS games more than I'd miss any 32bit MacOS applications, which I could run anyway through virtualization. I also wish they'd stop disappearing features from Apple software in general, but I think sunsetting 32bit apps or Carbon are generally better for the Macintosh ecosystem.

Due to the closed ecosystem for iOS, this type of abandoned app preservation will be extremely hard to do :c

Calculator is 64-bit

https://www.apple.com/shop/product/MD564LL/A/apple-usb-super...

Calculator:

  Obtained from:	Unknown
  Last Modified:	12/27/16, 9:00 PM
  Kind:	Intel
  64-Bit (Intel):	No
  Location:	/Users/mitch/Library/Application Support/iPhone Simulator/6.0/Applications/610B1057-FF52-4D59-AE7D-DDD406E83F18/Calculator.app