Xcode 14 deprecates bitcode for watchOS and tvOS
developer.apple.com
developer.apple.com
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 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.
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.
Not sure if you realize it or not but most developers no longer have a choice.
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.
Is this already gone for iOS, or is it sticking around longer for iOS?
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.
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.
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.
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"
edit : it looks like they already are, as the release note says so..
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.
Apple Watch Series 3 support has now been discontinued by Apple. They were content to stop supporting bitcode.