4 ms·
Things like this make me wish that we could submit multiple builds to the app store with different deployment targets and have it install the highest supported
by plorkyeran 5y ago
Things like this make me wish that we could submit multiple builds to the app store with different deployment targets and have it install the highest supported one. They've made a few of these runtime improvements over the last few years that could make apps faster and smaller, but in practice very few of the apps I have installed take advantage of them because they prefer to maintain compatibility with older versions instead.
- colejohnson66 5y agoIsn’t that the idea with “bit code”? Basically, Apple keeps the LLVM IR (of sorts) and optimizes it on their end (and removes unneeded image assets (such as @2x on an @3x device)). So the build your device downloads is highly optimized specifically for your device model. Or do you mean something else?
- lanza 5y agoThis would only support optimizing for different architectures. Your code is already compiled from Swift -> IR and thus these features would not be part of the IR.
- inkyoto 5y agoArchitecture specific («post-compile» time pass) and chained fixups (link time pass) optimisations are orthogonal, and both can take place. Since a) Bitcode IR is, essentially, an object file; b) the destination platform version is known at the post-processing (i.e. download) time, it is possible to also optimise the executable binary format to make us of whatever enhacements are available, too.
- saagarjha 5y agoBitcode does not do this, unfortunately.
- plorkyeran 5y agoThere isn't much evidence that Apple has ever used bitcode for anything other than making existing watchOS apps run on the new arm64_32 architecture. It's required for app thinning (where they only install the architecture needed for the actual device rather than all of them), but if that's not just an arbitrary requirement to get people to enable bitcode it's unclear what it's being used for. I don't know if bitcode could be used to recompile your app with a higher deployment target and have useful effects, but it isn't being done in practice.
- apozem 5y agoThat's the name of the game with Apple development, unfortunately. Every year, I get excited for all these cool new SwiftUI features at WWDC and wait 2+ years to actually use them.
- srgpqt 5y agoProbably a good idea to wait regardless, gives them time to work out the issues that inevitably come with the fancy new shiny.
- apozem 5y agoOh, absolutely. I got excited for the SwiftUI .toolbar modifier last year. It was wildly broken during the betas, and they just... didn't fix it for iOS 14's launch. No idea if it works now, but definitely a lesson in the dangers of the new and shiny.
- oatmealsnap 5y agohey, just like web development.
- mmis1000 5y agoExcept on web, some madness are still using android 4.x or even ie 11. Who on the earth have to support something published 8 years ago...
- joshspankit 5y agoI actually think that Apple intentionally makes compelling features just so they can drive people to newer versions of the OS (and therefore to newer phones). But that’s just a theory. An Apple theory.
- jurmous 5y agoWell for two years in a row they did not remove support for iPhones. So iOS 15 will support the same devices as iOS 13 did. So it seems they are now less driving people to new phones. I think the emoji are more driving people updating the OS than any features. And developers will only update their minimum target if people leave behind that version.