{"id":27495,"date":"2019-12-06T16:44:48","date_gmt":"2019-12-06T21:44:48","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=27495"},"modified":"2019-12-17T16:28:28","modified_gmt":"2019-12-17T21:28:28","slug":"apples-technology-transitions","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/12\/06\/apples-technology-transitions\/","title":{"rendered":"Apple’s Technology Transitions"},"content":{"rendered":"

Martin Pilkington<\/a>:<\/p>\n

\n

While this saving of disk space and RAM usage certainly benefits the Mac, there are arguably more important reasons to Apple for dropping 32 bit on the Mac. They don’t actually have much to do with 32 bit itself, but more with decisions that were made in 2007 when 64 bit was finalised.<\/p>\n

[…]<\/p>\n

When Apple introduced 64 bit with Mac OS X 10.5, they also introduced Objective-C 2.0. Part of this was a new and improved runtime, designed to fix problems with the old runtime. Unfortunately, these fixes were not compatible with existing apps, so they made the decision to only make this runtime available in 64 bit. However, this meant the (now) legacy runtime would have to stick around as long as 32 bit apps existed.<\/p>\n

[…]<\/p>\n

The behaviour of the legacy runtime effectively means that Apple can never update their existing objects with new ivars without breaking existing apps.<\/p>\n<\/blockquote>\n

PDFKit accidentally did just that in Sierra, causing crashes in 32-bit apps that displayed PDFs, as the framework tried to access variables that didn’t exist.<\/p>\n\n

ARC has been off-limits, too. Apple’s framework developers have been working with one hand tied behind their backs.<\/p>\n\n

Previously:<\/p>\n