[HN Gopher] Xcode 14 deprecates bitcode for watchOS and tvOS
___________________________________________________________________
Xcode 14 deprecates bitcode for watchOS and tvOS
Author : pjmlp
Score : 60 points
Date : 2022-07-01 07:47 UTC (15 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| socialdemocrat wrote:
| Why could they not have make architecture independent Bitcode
| instead? Would that not have been useful?
| Reason077 wrote:
| Useful, certainly. But an awful lot more complex, too.
| mmastrac wrote:
| 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.
| Moto7451 wrote:
| Boosting this comment, Apple tried to make Java a first class
| citizen twice between WebObjects and a Cocoa bridge.
| Developers did not want that.
| pjmlp wrote:
| 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.
| trzeci wrote:
| Lack of support for the on-device debugging for iOS 10 is at
| least confusing.
|
| And yes, people still use iOS 10, and at scale we should be able
| to troubleshoot problems on that iOS.
| SomethingNew71 wrote:
| 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?
| plorkyeran wrote:
| 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.
| pooper wrote:
| I would like to know this as w. I would have thought most
| people (iPhone 6, iPhone 6 plus) on iOS 10 can get iOS 12?
| trzeci wrote:
| 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.
| [deleted]
| yakubin wrote:
| 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.
| eddieroger wrote:
| 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.
| citrusui wrote:
| iOS 10 is definitely not 10 years old but it is nearing 6
| years. For the iOS ecosystem, even iOS 13 is kinda old.
| jeshin wrote:
| 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.
| jffry wrote:
| 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.
|
| [1] https://en.wikipedia.org/wiki/IOS_10
| danpalmer wrote:
| 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?
| trollied wrote:
| 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.
| 0x0 wrote:
| 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?
| trollied wrote:
| >bitcode is still architecture specific
|
| Ah, I didn't know that. Thank you
| 0x0 wrote:
| 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)
| skissane wrote:
| > talks about how the NSTextAlignment enum has diverging
| definitions between archs
|
| I wonder why: was there some benefit for Apple in doing
| this?
| plorkyeran wrote:
| 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.
| DaiPlusPlus wrote:
| > the only officially supported interface to the kernel
| is libc
|
| aka "no fun allowed"
| pjmlp wrote:
| 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.
| pdpi wrote:
| 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.
| plorkyeran wrote:
| 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.
| pdpi wrote:
| 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.
| 0x0 wrote:
| 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)
| plorkyeran wrote:
| 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).
| blackoil wrote:
| Does that mean someone with gen 3 watch will not be able to
| download any new app?
| selykg wrote:
| That model is not getting the latest watchOS update this
| fall. So it's effectively end of life going forward.
| iasay wrote:
| That's crap. They still sell it.
| theplumber wrote:
| So what? People buy more useless stuff all the time
| nindalf wrote:
| Apple takes great pride in supporting their iPhones for
| years after they stop selling them. This is the exact
| opposite.
| theplumber wrote:
| That's the PR. The reality is more nuanced #Batterygate
| mastercheif wrote:
| #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.
| Dylan16807 wrote:
| 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...
| gumby wrote:
| I agree completely. Sadly, the reality doesn't generate
| clicks, so pseudo-scandal it is.
| jamesrom wrote:
| > The reality is more nuanced
|
| > #Batterygate
|
| Pick one.
| memsom wrote:
| 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.
| plorkyeran wrote:
| 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.
| hnaccount_rng wrote:
| 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
| [deleted]
| danpalmer wrote:
| Thanks. I had remembered that Bitcode was architecture
| specific and couldn't remember if that applied down to the
| 32/64 transition.
| yoz-y wrote:
| 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.
| lstamour wrote:
| Seems it's being deprecated as the relevant platforms are
| unifying on arm64:
| https://www.runway.team/blog/wwdc-2022-highlights
| Jarred wrote:
| 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?
| mwcampbell wrote:
| 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.
| api wrote:
| That might be a reason for the reversal.
|
| 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.
| bsaul wrote:
| "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.
| asveikau wrote:
| 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.
| coldtea wrote:
| > _And yet it transparently seems like a goofy idea, and
| they axed it._
|
| 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...
| asveikau wrote:
| I'm going to say it is goofy.
|
| 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.
| whywhywhywhy wrote:
| > 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.
| api wrote:
| If they do that, they'll just lose the pro and developer
| market. If that's what they want, fine.
| whywhywhywhy wrote:
| It'll still run XCode, what you gonna do? Not ship an iOS
| app?
|
| Not sure if you realize it or not but most developers no
| longer have a choice.
| api wrote:
| 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.
| alwillis wrote:
| _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].
|
| [1]: https://www.apple.com/newsroom/pdfs/FY22_Q2_Consolidat
| ed_Fin...
| AndrianV wrote:
| The most recent gadget to not support 64-bit was the Apple Watch
| Series 3. (such as armv7 or i386)
|
| Apple Watch Series 3 support has now been discontinued by Apple.
| They were content to stop supporting bitcode.
| bsaul wrote:
| Are they going to deprecate it for iOS as well ??
|
| edit : it looks like they already are, as the release note says
| so..
| mmastrac wrote:
| 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.
___________________________________________________________________
(page generated 2022-07-01 23:02 UTC)