Does anyone know why this is changing? I thought Bitcode provided some useful flexibility for Apple and that they'd be moving in the direction of more dynamism in apps in this way, rather than removing it.
Is this already gone for iOS, or is it sticking around longer for iOS?
I guess it was an interim measure as part of the x86_64->arm transition. Now that everything targets arm, there's no need for an intermediate representation.
Bitcode wouldn't help with the x86-arm transition because bitcode is still architecture specific.
My guess is that maybe they don't want to maintain multiple old toolchains to provide the on-demand bitcode->native build step on the app store servers?
That is the case for standard LLVM bitcode, Apple's own version is more finetuned and probably a reason why they are moving away from it, no longer willing to keep maintaining their fork.
Even if bitcode was fully architecture independent, you would immediately hit a wall with various framework constants having different #defined integer values. For example, https://developer.apple.com/documentation/apple-silicon/addr... talks about how the NSTextAlignment enum has diverging definitions between archs.
By the way something similar happens on Linux where kernel syscalls have different numbers between archs, for example. (Although on mac/ios, syscalls aren't guaranteed to be stable even across minor macos versions; the only officially supported interface to the kernel is libc)
That specific change is possibly just a mistake. They take advantage of architecture transitions to do cleanup which they couldn't do normally because it's an ABI-breaking change. In that specific case, I'd guess they removed the enum values which were no longer actually supported and (accidentally?) renumbered the rest.
bitcode predates that transition (which is very much still in play). watchOS and tvOS never had (consumer?) x86 versions, the bitcode thing was a workaround to having to build fat (multi-arch) binaries for more space-constrained devices like the Apple Watch and Apple TV.
It was an interm measure for the armv7 -> arm64 transition, where they used it to convert armv7 binaries to a wacky 32-bit version of arm64.
It was also used for a few misguided things over the years, like force-enabling Swift Concurrency backdeployment for apps submitted to the app store, which mostly just introduced bugs that only happened on app store/test flight installs for zero benefit.
AIUI the point of bitcode was that you submit one bitcode app, and Apple then compiles that down to per-model native apps. The last Apple Watch without 64-bit support was the gen 3, and that is no longer supported, so the use case for bitcode is gone. I expect they'll be happy to sunset that whole chunk of infra on their end.
Afaik Craig said (probably in The Talkshow) that bitcode is not useful to do a 64bit transition as it is still specific to an architecture. It only allows for micro-optimisations.
Even the newer apple watches aren't fully 64bit, instead they run an architecture called "arm64_32" which uses 32bit pointers (which is probably why bitcode worked for this transition, I don't think 32bit bitcode could be used to produce a 64bit native binary)
Xcode 14 introduces real arm64 for watchOS, and it runs on current watches. arm64_32 appears to have been just a transitionary thing (specifically so that existing apps could be recompiled to it via bitcode).
#batterygate was an attempt to extend the life of iPhone 6 and iPhone 6s models with aged batteries by preventing unexpected shutdowns which were caused by the CPU pulling to much current when operating at high frequencies.
Apple should have been more transparent about what they were doing, but it’s difficult to argue that they were operating in bad faith. I’d wager unexpected shutdowns would result in more aggregate “unwanted” upgrades versus degraded peak performance.
It was a workaround for a problem they caused with the phone design.
I won't cry bad faith, exactly, but it was bad that the phones would lose performance after a couple years without this being properly explained up front. Their battery replacement program also helped mitigate the issue, but now newer phones cost more to replace batteries on, also because of design decisions...
Not really true. The Apple Watch series 3 was released 2017, so it got 4.5 - 5 years of support. I don't think that is bad. It will still work, it will just not get any more OS updates.
I sport an iPhone 6s. I guess it is unsupported from this year, but I have owned it since the December after it was launched. So it was supported for circa 6 years, give or take a few months. That was absolutely the longest any Apple iPhone was ever supported. Most get less (I want to say up to 4 years, but I have no actual figures to hand.) I'm not unhappy with the length it was supported to be honest. My previous phone was a Nexus 4 and that got way less, I don't think it was more then 3.
The length the Apple Watch series 3 was supported it perfectly acceptable, and I bet few bough outside of the last 2 years still have great battery life anyway.
The relevant thing is how long they support it from when they stop selling a device, not from when they started selling a device. You can still buy a brand new series 3 Watch from Apple _today_. Those devices are getting zero years of support.
In principle I strongly agree, but I have yet to find a single third party app that I want on my watch. And as long as the watch is still able to do notifications, pinging, podcasts and unlocking of my MacBook, I wouldn't consider this too bad. But let's see how this shakes out in practice
bought mine in October 2017 and still wear it daily to this day. it easily goes the full day and usually most of the next if I forget to charge it. it might last longer if I turned off the cellular antenna, but I've never needed to.
They will probably keep supporting it with security updates for quite a while, I don’t think they can get away with selling a device and then immediately pulling support.
Apple has never really been a bytecode company. I can't imagine them tossing this philosophy out the window and going all in on a virtual machine like Android does.
Like it or hate it, Apple is and probably always will ship native bits for applications.
The story goes around a bit different, first of all, Web Objects was fully migrated to Java, and the last big user of it was the iTunes store.
Secondly, the main reason for the Cocoa bridge was not to force developers to use Java, rather they were uncertain that a community grown in Object Pascal and C++, would be happy to jump into Objective-C and its syntax full of [] and @.
When they saw that Objective-C wasn't having any adoption blockers, they dropped Cocoa Bridge.
Curious what the use cases for iOS 10 are? This isn't a criticism of your comment but more just wanting to learn why a user might still be using iOS 10?
Apple does not limit minimal version of iOS during the submission process - which is a signal that this version is supported.
By removing the debugging ability it's almost pushing the responsibility onto publishers/developers to say "hey, we don't support iOS 10 anymore - we are these bad guys".
In a case when we would like to provide the best possible experience to all players (even if the market share is less than 1%) - I consider as a regression, an unnecessary change and complication.
iOS 10 is the final version which runs on 32-bit devices, and there's a decent number of those out there still. Xcode 14 has dropped support for 32-bit iOS, which by extension means it can't support iOS 10.
iOS 10 hasn't been receiving security updates for 2 years now. The last iPhones which only got updates up to 10 were iPhone 5 and 5C. They were released in 2012. iPhone 5S (released in 2013) got updates up to iOS 12, but about a year ago security updates also ceased. That's almost 9 years of support. I don't think it's unreasonable to drop support for it after such a long time. Actually, I switched just yesterday from 5S to 13 Mini, mainly because I couldn't install most apps anymore, and I think that's fair.
I hate to be "citation needed" guy, but iOS 10 is ten years old and out of security updates for a few years. At what scale is it still used? In general, iOS has had a better lifecycle than Windows XP or 7 had, so surely there's not a fleet of iPhone 5s POS devices floating around.
iOS 12 still sees a pinch of usage, because it was the last version (before 16) that dropped some devices. Anything older than that seems to be pretty much not used anymore except for extremely rare cases, based on browser usage statistics, at least.
iOS 10 was released in September 2016 and got its last update in July 2019. [1] I agree that it is probably not used at meaningful sclae, but no need to hyperbolize how old it is.
I'm very happy to see bitcode die. It was a massive pain for SDK developers, even more so if you wanted to use another native language like Rust in any way.
Interesting reversal. When Apple introduced the bitcode requirement for watchOS and tvOS, I thought this was the beginning of a coming series of restrictions that would ultimately make it impossible to ship apps for Apple platforms using anything other than Apple's LLVM toolchain. I thought that the only possible future for AOT-compiling alternative languages for Apple platforms was source-to-source translation like J2ObjC, which I then proceeded to use in my next project. I'm glad that, in this case at least, Apple didn't end up locking things down just because they could.
My guess is that the reasoning was that they thought they might be maintaining a mixed platform of both x86_64 and aarch64 and maybe even RISC-V indefinitely, and that this would allow app interop across all targets on all Apple OSes without fat binaries.
I could have told them that wouldn't even work well. LLVM bitcode is not really that great as an object distribution format. It's really just for use during builds.
I'd argue that Apple has skipped many opportunities to lock down the Mac, including not locking down the boot loader on the M series chips and allowing it to boot Linux or even (when supported) Windows aarch64. It's clear that they see the Mac as a pro platform and understand that pro users want flexibility.
"I could have told them that wouldn't even work well"
I have no idea who you are, but IIRC that choice was made while Chris Lattner was still at Apple. I doubt that they could have made a better informed decision at the time.
And yet it transparently seems like a goofy idea, and they axed it.
It could also be that Chris Lattner made that decision based on some constraints or requests that were kind of contrived and make less sense or are no longer valid today.
There was another platform i will leave nameless. They performed additional "ahead of time" type optimization after a developer submitted a binary. That layer had bugs. I personally saw them surface. Since the AOT happened transparently on the platform vendor's machine it was very hard for a developer to test, diagnose, confirm fixed, etc. The developer still got blamed for bugs hitting the end user. That layer one can also imagine could see changes on the platform vendor's server so something could theoretically break later on and nobody would know until the bug reports came flooding to the developer.
Because it was a goofy idea. Sounds good superficially, but ill conceived at the design stage.
Moreover, that goofiness may also be why they don't need it anymore. It wasn't a solid idea to begin with, so your changing requirements wind up revealing that.
> It's clear that they see the Mac as a pro platform and understand that pro users want flexibility.
I think it's more they know the right strategy about how to shift Mac users to iOS.
The initial hope was the iPad Pro was so powerful and felt so spaceage next to the janky worst intel Macbooks ever that people would switch voluntarily. When that didn't happen they switched tactics.
It will happen, MacBooks will eventually ship with iPadOS as their main OS and MacOS as a legacy option that will eventually be deprecated entirely. You have to remember the main success of the past 10 years has been on Apple being a parasite on the work of others via app store fees and they're gonna eventually manage to capture that value on the Mac, there will be execs sat at the top who actually find it strange they don't already get a cut of say Adobe CC when running on a Mac because they're not people in love with the concept of "computing" like HN readers, oldschool Mac users and the like are.
If you target Apple platforms you would need the token Apple build machine, but it'd be out for daily driver which means devs not buying highest-end hardware or upgrading frequently.
MacBooks will eventually ship with iPadOS as their main OS and MacOS as a legacy option
Absolutely not.
Just from a business point of view, in the 37 year history of the Mac, it’s never sold better. Ever since Apple Silicon Macs were available for sale the end of 2019, it’s been record quarter after record quarter.
The Mac is a $10 billion—and growing—business. It’s not going anywhere [1].
Here's the thing, you being a presumably (seen as we're on HN) techie and interested in the concept of computing are thinking "No one would ever want a MacBook running iPad OS"
Executives at Apple will be thinking "People love MacBooks form factor, people love iPadOS and if we ship them together we capture all the value of the Mac software market too"
Now, my personal beliefs are much closer to yours, but my belief of what will play out is what Apple execs believe is best.
Executives at Apple will be thinking "People love MacBooks form factor, people love iPadOS and if we ship them together we capture all the value of the Mac software market too"
If you listen to Apple execs when they speak to these issues, there’s nothing to indicate they feel this way.
You didn’t respond to the fact that Mac sales have never been better, with several record quarters in a row. Why would Apple mess around with that?
Many Mac owners also own iPads; there’s no reason to put iPadOS on MacBooks when they’ll buy an iPad anyway.
Does bitcode have the same performance gains from `-emit-llvm -flto=full`? It seems like Clang is better at inlining across compilation units when -emit-llvm is passed, but it also seems to store additional object files in temporary files? Is there a way to tell Clang to put everything it needs per translation unit in one file?
66 comments
[ 0.20 ms ] story [ 148 ms ] threadIs this already gone for iOS, or is it sticking around longer for iOS?
My guess is that maybe they don't want to maintain multiple old toolchains to provide the on-demand bitcode->native build step on the app store servers?
Ah, I didn't know that. Thank you
By the way something similar happens on Linux where kernel syscalls have different numbers between archs, for example. (Although on mac/ios, syscalls aren't guaranteed to be stable even across minor macos versions; the only officially supported interface to the kernel is libc)
I wonder why: was there some benefit for Apple in doing this?
aka "no fun allowed"
It was also used for a few misguided things over the years, like force-enabling Swift Concurrency backdeployment for apps submitted to the app store, which mostly just introduced bugs that only happened on app store/test flight installs for zero benefit.
Apple should have been more transparent about what they were doing, but it’s difficult to argue that they were operating in bad faith. I’d wager unexpected shutdowns would result in more aggregate “unwanted” upgrades versus degraded peak performance.
I won't cry bad faith, exactly, but it was bad that the phones would lose performance after a couple years without this being properly explained up front. Their battery replacement program also helped mitigate the issue, but now newer phones cost more to replace batteries on, also because of design decisions...
> #Batterygate
Pick one.
I sport an iPhone 6s. I guess it is unsupported from this year, but I have owned it since the December after it was launched. So it was supported for circa 6 years, give or take a few months. That was absolutely the longest any Apple iPhone was ever supported. Most get less (I want to say up to 4 years, but I have no actual figures to hand.) I'm not unhappy with the length it was supported to be honest. My previous phone was a Nexus 4 and that got way less, I don't think it was more then 3.
The length the Apple Watch series 3 was supported it perfectly acceptable, and I bet few bough outside of the last 2 years still have great battery life anyway.
Like it or hate it, Apple is and probably always will ship native bits for applications.
Secondly, the main reason for the Cocoa bridge was not to force developers to use Java, rather they were uncertain that a community grown in Object Pascal and C++, would be happy to jump into Objective-C and its syntax full of [] and @.
When they saw that Objective-C wasn't having any adoption blockers, they dropped Cocoa Bridge.
And yes, people still use iOS 10, and at scale we should be able to troubleshoot problems on that iOS.
By removing the debugging ability it's almost pushing the responsibility onto publishers/developers to say "hey, we don't support iOS 10 anymore - we are these bad guys".
In a case when we would like to provide the best possible experience to all players (even if the market share is less than 1%) - I consider as a regression, an unnecessary change and complication.
[1] https://en.wikipedia.org/wiki/IOS_10
edit : it looks like they already are, as the release note says so..
My guess is that the reasoning was that they thought they might be maintaining a mixed platform of both x86_64 and aarch64 and maybe even RISC-V indefinitely, and that this would allow app interop across all targets on all Apple OSes without fat binaries.
I could have told them that wouldn't even work well. LLVM bitcode is not really that great as an object distribution format. It's really just for use during builds.
I'd argue that Apple has skipped many opportunities to lock down the Mac, including not locking down the boot loader on the M series chips and allowing it to boot Linux or even (when supported) Windows aarch64. It's clear that they see the Mac as a pro platform and understand that pro users want flexibility.
I have no idea who you are, but IIRC that choice was made while Chris Lattner was still at Apple. I doubt that they could have made a better informed decision at the time.
It could also be that Chris Lattner made that decision based on some constraints or requests that were kind of contrived and make less sense or are no longer valid today.
Nope, they axed it because platform-wise they don't need it: they have desktop/laptop ARM now to use.
If they had x86+ARM to support in the future, they'd have kept it.
Plus, it worked for years, so there was nothing either about it being "goofy" or "not working" for them behind axing it...
There was another platform i will leave nameless. They performed additional "ahead of time" type optimization after a developer submitted a binary. That layer had bugs. I personally saw them surface. Since the AOT happened transparently on the platform vendor's machine it was very hard for a developer to test, diagnose, confirm fixed, etc. The developer still got blamed for bugs hitting the end user. That layer one can also imagine could see changes on the platform vendor's server so something could theoretically break later on and nobody would know until the bug reports came flooding to the developer.
Because it was a goofy idea. Sounds good superficially, but ill conceived at the design stage.
Moreover, that goofiness may also be why they don't need it anymore. It wasn't a solid idea to begin with, so your changing requirements wind up revealing that.
I think it's more they know the right strategy about how to shift Mac users to iOS.
The initial hope was the iPad Pro was so powerful and felt so spaceage next to the janky worst intel Macbooks ever that people would switch voluntarily. When that didn't happen they switched tactics.
It will happen, MacBooks will eventually ship with iPadOS as their main OS and MacOS as a legacy option that will eventually be deprecated entirely. You have to remember the main success of the past 10 years has been on Apple being a parasite on the work of others via app store fees and they're gonna eventually manage to capture that value on the Mac, there will be execs sat at the top who actually find it strange they don't already get a cut of say Adobe CC when running on a Mac because they're not people in love with the concept of "computing" like HN readers, oldschool Mac users and the like are.
Not sure if you realize it or not but most developers no longer have a choice.
Absolutely not.
Just from a business point of view, in the 37 year history of the Mac, it’s never sold better. Ever since Apple Silicon Macs were available for sale the end of 2019, it’s been record quarter after record quarter.
The Mac is a $10 billion—and growing—business. It’s not going anywhere [1].
[1]: https://www.apple.com/newsroom/pdfs/FY22_Q2_Consolidated_Fin...
Executives at Apple will be thinking "People love MacBooks form factor, people love iPadOS and if we ship them together we capture all the value of the Mac software market too"
Now, my personal beliefs are much closer to yours, but my belief of what will play out is what Apple execs believe is best.
If you listen to Apple execs when they speak to these issues, there’s nothing to indicate they feel this way.
You didn’t respond to the fact that Mac sales have never been better, with several record quarters in a row. Why would Apple mess around with that?
Many Mac owners also own iPads; there’s no reason to put iPadOS on MacBooks when they’ll buy an iPad anyway.
Apple Watch Series 3 support has now been discontinued by Apple. They were content to stop supporting bitcode.