Apple Watch Apps Instantly Went 64-Bit Thanks To Obscure Bitcode Option (venturebeat.com)
Jeremy Horwitz, writing for VentureBeat: An obscure feature in Apple's Xcode development software enabled Apple Watch apps to make an instant transition from 32-bit to 64-bit last month, an unheralded win for Apple Watch developers inside and outside the company. The "Enable Bitcode" feature was introduced to developers three years ago, but the Accidental Tech Podcast suggests that it was quietly responsible for the smooth launch of software for the Apple Watch Series 4 last month.
Support for Bitcode was originally added to Xcode 7 in November 2015, subsequently becoming optional for iOS apps but mandatory for watchOS and tvOS apps. Bitcode is an "intermediate representation" halfway between human-written app code and machine code. Rather than the developer sending a completely compiled app to the App Store, enabling Bitcode provides Apple with a partially compiled app that it can then finish compiling for whatever processors it wants to support. The report suggests that this change allowed Apple to avoid the great "appocalypse" which occurred when it decided to kill support for 32-bit apps on iOS.
Support for Bitcode was originally added to Xcode 7 in November 2015, subsequently becoming optional for iOS apps but mandatory for watchOS and tvOS apps. Bitcode is an "intermediate representation" halfway between human-written app code and machine code. Rather than the developer sending a completely compiled app to the App Store, enabling Bitcode provides Apple with a partially compiled app that it can then finish compiling for whatever processors it wants to support. The report suggests that this change allowed Apple to avoid the great "appocalypse" which occurred when it decided to kill support for 32-bit apps on iOS.
There are other gains to be had. For instance, updating apps to 64-bit means that everything links against Apple's 64-bit library binaries. As a result, Apple can drop the 32-bit binaries from watchOS, leading to less maintenance, smaller and faster system update downloads, and more space available for the user to use on the device. Given that these are rather constrained devices, every little bit (pun intended) helps.
this watch only has 18 hours endurance unless you basically turn it off. Some watch.
Funny mine lasts 2 to 3 days...
Mike @ The Geek Pub. Let's Make Stuff!
So other than addressing >4Gb of memory, what are the upsides?
64-bit ARM processors have more than double the number of general purpose registers than 32 bit ARM processors have. This can speed up code considerably, by reducing the number of load/store instructions needed when you have half the registers. And as decisions as to register use is done at compile time (and not at runtime), this benefits 64-bit code mores than 32-bit code (as the compiler has to presume the lowest common denominator, and all compile 32-bit code assuming the 15 general purpose registers found on 32-bit ARM CPUs).
The big upside for Apple of course is no longer needing to maintain or ship any legacy 32-bit codebases. All current Apple devices now feature a 64-bit CPU, so Apple can get rid of 32-bit kernel support. If all apps are required to be 64-bit, Apple doesn't need to maintain or ship 32-bit system libraries. Xcode will be simplified, as there won't the any need for 32-bit build tools or targets.
Not having to maintain the massive amount of 32-bit support code inside Apple's various OS's will be a big win for Apple -- but that win will also trickle down to end-users, as Apple will be able to put more effort and emphasis on common codebases for their entire product line, and can put development resources that were being used to maintain 32-bit support to other tasks.
Yaz
64bit ARM architectures are more power efficient than the older 32bit ones. ARMv8 is a more advanced instruction set than ARMv7.
So will we all just abandon to the scrap heap all the very expensive Apple devices that already exist and are still working? You know, all the 32 bit devices?
All of the old software and development tools still work if you need to target a really old device.
Apple has been primarily 64-bit for a very long time now. 64 bit support for OS X came out in 2005, all new Macs had 64-bit hardware by 2007, and in 2011 64 bit became required with Mac OS X Lion (10.7). The iPhone has been 64 bit since the iPhone 5s (2013). AppleTV has been fully 64-bit for two generations now (since 2015), however it needs to be noted here that prior to the 2015 model, the AppleTV didn't permit 3rd party apps anyway.
And as this article indicates, bitness of the tvOS and Apple Watch devices matters less, as Apple accepts the applications as byte code from the vendors, and can compile it on the fly for specific devices in whatever bitness they support. As such, your device has to be quite old to need 32 bit support, and Apple for at least the last year has required all apps submitted to its app stores to be 64-bit.
If Apple is not supporting 32 bit OSs anymore, then are app developers going to have to keep a copy of XCode 7 or whatever that does support the vast number of legacy devices?
The number isn't as vast as you are implying. Unsupported Macs would have to be at least 12 years old now. Unsupported iOS devices are more than 5 years old at this point. The AppleTV has never had a revision that permitted 3rd party apps which wasn't 64 bit. It's only on the Apple Watch where there is a currently supported 32 bit OS -- and as the article indicates, Apple got around much of the issues between 32-bit and 64-bit versions by having byte code based apps which it can compile to the necessary architecture on the fly on your behalf.
So yes -- if you for some reason really have to target old 32 bit devices, at some point you'll need an older Xcode around. Presumably you're deploying these to the devices yourself, as the App Store hasn't permitted 32-bit apps for at least the last year. Next year macOS is dropping 32-bit application support altogether.
Yaz