Slashdot Mirror
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.
Welcome to mid-1990s Solaris.
Did Apple Watches suddenly gain some dire need for 64-bit address space?
I think you mis-spelled "requirement" - at least with respect to Apple Watch apps.
For most things a watch does it just means it now needs more resources to get the same thing done.
It's not even "better" in the x86->x86_64 sense where an important bottleneck was eased. So this is just geekfappery, the warm fuzzy feeling of "64bit on the wrist", where "16bit on the wrist" probably would've done just as well... or possibly even better.
Apple's App Apps were able to app apps while apping other apps! LUDDITE software can't do that!
Apps!
Bitcode is an “intermediate representation” halfway between human-written app code and machine code.
So.... kind of like this other thing from 1996 from this obscure company called Sun Microsystems. Anyone heard of them? I think they called it Java Bytecode. Wait... bitcode... bytecode... maybe a similarity there?
It's great that Apple is using the same idea as Sun Microsystems Java. But don't try to make it out like it's some amazing innovation from Apple. Bytecode, and running on 64 bit hardware isn't amazing, it's old hat. Sun did this more than 20 years ago.
So its basically Java for the apple side.
So when I want to see the time on my apple watch at 2:40pm based on my laptop clock, the java compiler will speed up time, since it will be at least 2:41pm before the watch is ready to display the time, after doing all the GC, updates, and other critical functions.
So when I set an alarm for 6:00, to wake up at 6:05, when the watch has finished running all the ancillary processes to harvest whatever data is available, and at 6:10, after hitting the silence button only 25 times, the alarm will silence.
What great features!
With iOS 12, my phone now takes about 40 seconds to render the keypad before it calls 911.
it was mandatory on the platform for THREE FUCKING YEARS. hardly 'obscure'.
For a quick overview, you could read this : https://lowlevelbits.org/bitcode-demystified/ .
It's not like it matters because the WatchOS App-pocalypse already happened. When the Apple Watch was released, a lot of app makers threw Apple Watch apps into their iPhone apps. (Note that's how WatchOS apps work - they're tethered to an iPhone app.)
Since then, the number of WatchOS apps has ... declined, as developers realized no one was using them and there's basically nothing useful you can do with a UI on a watch. And because they're tied to an iPhone app, if you wanted to keep using a WatchOS app after it was discontinued, you had to not update the corresponding iPhone app, ever, of the WatchOS app would be automatically removed.
So moving to 64-bit - who cares? It's not like anyone uses WatchOS apps. I'm sure the five remaining WatchOS apps made the transition just fine.
LLVM bitcode contains (and needs) the datalayout of the target. This datalayout means such things as default data sizes and alignment rules. Pointer size is different for 32- and 64-bit architectures, so same LLVM bitcode cannot work in both 32- and 64-bit mode.
So, bitcode alone cannot explain portability to 64-bit.
It might be that the development tools have compiled separate bitcode files for 32-and 64-bit architectures.
.... except the compiling happens in the app store infrastructure, not on the watch. So nothing like Java's byte code and JIT compilation. Not even like Android and it's ART runtime, that compiles the code when it's installed.
Or IRIX. I had my first 64-bit desktop machine around 1996 (SGI Indigo).
No sig today...
Did you wear that Indigo on your wrist?
Yeah, nothing like it. Compiling on a computer that sits on your desk is totally different than compiling on a computer that sits in your pocket or on a computer that straps to your arm. Even if those computers are architecturally similar if not identical. The key take away here is the shape and location of your compute is vitally important to this definition of what makes Java and JIT distinctive.
“Common sense is not so common.” — Voltaire
Yeah, having to use two CPU registers to hold my file offsets was a real chore. It was impossible for 20 year old Unix systems to add system calls to with names like lseek64(). We can only write software that is as simple as possible, and we would never include even slightly complicated interfaces to do something as basic as accessing large files.
Also 32-bit systems never offer 64-bit values for time stamps, so those will all explode in the year 2038. You don't want your obsolete 32-bit watch to EXPLODE do you?
(actual upsides are related to the industry providing security updates and enhancements to newer architectures)
“Common sense is not so common.” — Voltaire
So its basically Java for the apple side.
So when I want to see the time on my apple watch at 2:40pm based on my laptop clock, the java compiler will speed up time, since it will be at least 2:41pm before the watch is ready to display the time, after doing all the GC, updates, and other critical functions.
So when I set an alarm for 6:00, to wake up at 6:05, when the watch has finished running all the ancillary processes to harvest whatever data is available, and at 6:10, after hitting the silence button only 25 times, the alarm will silence.
What great features!
With iOS 12, my phone now takes about 40 seconds to render the keypad before it calls 911.
Funny. Out of all the betas and reviews of iOS 12, isn't it amazing you are the only one to experience that?
Yeah, nothing like it. Compiling on a computer that sits on your desk is totally different than compiling on a computer that sits in your pocket or on a computer that straps to your arm. Even if those computers are architecturally similar if not identical. The key take away here is the shape and location of your compute is vitally important to this definition of what makes Java and JIT distinctive.
Hey dumbass.
The compilation is done on Apple's SERVERS, before the App is downloaded to your device.
No, he surely didn't, and it was no where near as fast or powerful as the watch. But, that doesn't matter. The interesting thing has nothing to do with the Apple Watch 4 being a 64bit wide architecture.
The interesting thing in this story (for all the non-programmers out there), is the IDE handling natively the cross-compilation difficulties of moving between 32 and 64 bits. That means it is allocating memory and changing data types of objects at compile-time.
Pretty cool stuff.
Frankly it is ridiculous that this sort of thing is even a problem. Apple, Google, Microsoft, etc should all be offering the ability to translate or run all 8-bit, 16-bit, 32-bit and 64-bit software on the newer OSs and hardware. It is an easy problem. They should also be offering emulation or JITC (Just In Time Compilation) or FRTC (First Run Time Compilation) for all older software to run on the newer hardware and OSs.
Dropping 32-bit helps simplify code that is used cross platform. All their current designs( Mac, iPhone, iPad, Apple TV and Watch) are 64-bit. They can eventually drop or deprecate 32 bit support as well from Xcode when their 32-bit devices( iOS already has ) are dropped from support. Then there would be less code to support, debug and test.
Additionally, rumors( not nessarily true ) that they will drop Intel chips for their own Arm designs for the Macs sometime in in the future. This could be also seen as a small test run for their Mac App Store in the future.
Sure it was clumsy and inconvenient, but boy did I look cool!
Everyone else is having charging issues, signal strength issues, antenna issues, front facing camera issues.
What a piece of shit apple produced
No, he surely didn't, and it was no where near as fast or powerful as the watch. But, that doesn't matter. The interesting thing has nothing to do with the Apple Watch 4 being a 64bit wide architecture.
The interesting thing in this story (for all the non-programmers out there), is the IDE handling natively the cross-compilation difficulties of moving between 32 and 64 bits. That means it is allocating memory and changing data types of objects at compile-time.
Cool. So it went from -m32 to -m64 on the compilation command args?
Back in 1995 or so we just added -xarch=sparc9 or something similar to the arguments passed to the compiler to switch from creating 32-bit binaries to 64-bit binaries.
Pretty cool stuff.
If you say so.
Then again, if anyone thinks moving to a 64-bit target is hard, how about stop doing the stupid shit like assuming you can put a pointer into an int, and that long is the same as an int?
A server is a computer sitting in a rack instead of on a desk.
Support my political activism on Patreon.
Pretty cool, sure.
IBM's System/38 did pretty much the same back in 1979, and programs written for that will still run on the latest iteration of that system (Currently called "System i") despite all the hardware being completely different - including the CPU.
Everyone else is having charging issues, signal strength issues, antenna issues, front facing camera issues.
What a piece of shit apple produced
First off, "signal strength issues" and "antenna issues" are inextricably linked; so thanks for trying to get two bites at the same apple (see what I did there?).
If by "Front-Facing Camera Issues" you are talking about the difference in the smoothing algorithms in the iPhone Xs, that is simply a misunderstanding of how it works:
https://www.macrumors.com/2018...
As for the Charging Issues, the Jury is still "out" on that one...
A server is a computer sitting in a rack instead of on a desk.
Really? I never would have known that, thanks!
Idiot.
The compilation is done on Apple's SERVERS, before the App is downloaded to your device.
Servers that are running essentially the same OS as Apple's desktops and tablets? Isn't that interesting. I mean interesting that you have no point.
Isn't the point the battery powered device doesn't need to compile any code? That takes power.