Hacker News Reader

Comment by plorkyeran | Hacker News Reader

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.

View on HN

That'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.

Probably a good idea to wait regardless, gives them time to work out the issues that inevitably come with the fancy new shiny.

Oh, 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.

hey, just like web development.

Except 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...

I 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.

Well 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.

The jury is still out on "less driving" (though my intuition agrees with you).

Here are some things that they are doing to "softly drive" people to newer phones:

- Emoji

- iMessage features (like Memoji stickers)

- Non-resource-intensive privacy features (such as choosing individual photos for an app to access)

- Pushing app developers to newer SDKs (which makes them change code and put in more work to support older iOS versions even if they can after making use of a new API)

- Extra RAM usage for the iOS versions due to additional background tasks that cannot be disabled

There are more (as a long-time device user I regularly see examples), but I'm limiting myself to 15min on this reply.

Isn’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?

This 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.

Architecture 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.

Bitcode does not do this, unfortunately.

There 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.

Reply on news.ycombinator.com