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.
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.
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).
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.
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.
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.
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.
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.
What about submitting Bitcode when uploading to App Store Connect? Would it take advantage of the change and build an optimized binary for iOS 15 while still supporting the old way on pre-iOS 15 and deliver the appropriate binary upon download?
The mach-o format supports a “fat binary” that contains multiple architectures and then the App Store can only deliver one of those architectures to a particular device. Bitcode lets Apple recompile a different architecture slice using this format. However, since this change is unrelated to the architecture it can’t take advantage of this format.
But only if you make your app incompatible with all older iOS versions? Seems to me like not many people will benefit from this.m for some time to come.
That’s always been true of these sorts of changes. But new apps often target the latest OS, and it’s common for existing apps to target “current minus one”, so it will only take a year or two for existing maintained apps to start benefitting from this.
There’s also a linker flag that lets you use this format on older OS versions. It seems to work (I tested as far back as iOS 13.4.1) but couldn’t find any documentation to guarantee it won’t cause issues https://developer.apple.com/forums/thread/683596
This. Hell, most corporate users are still using Windows 7 (I try to avoid working some place I can't have a Mac, but despite Windows 8 having been released in 2012 and 20 in 2015, I have never seen either in a corporate environment).
It is best to make your own decisions there based on some telemetry tbh. It will likely depend on your demographics but also upgrades may depend on your business model. For instance, you may be motivated to upgrade if you realize users who are on older iOS versions don't generate revenue.
As someone with a device locked on iOS 10 this makes me very happy. I have a desktop computer I bought in 2008 which is running Windows 10 and happy as a clam - and yet all my apple devices from before 2018 are essentially now bricks.
Limited to iOS 10 means an iPhone 5 or 5C. So you're talking about a phone which is eight or nine years old. Tell me, what non-Apple phone from 2012 would have given you better long term support?
I feel like you think this means munk-a is merely refusing to update past iOS 10, but there are devices that simply can't. (The ones stuck specifically on iOS 10 forever are the iPhone 5 and 5c.)
Claiming devices from before 2018 are essentially bricks is still hyperbole because the iPhone 5c was released long before that, 2013. The iPhone 6s, released in 2015, will run iOS 15.
I think the original message was poorly worded, I think they were imagining that devices that can't run iOS 15 would essentially be bricks because every app maker would build their apps in this way that only works on iOS 15 devices. Of course, this will not happen. It has long been the case that developers need to balance the advantages of using techniques enabled in newer OS versions against the advantage of supporting a wider range of OS versions.
Well, as someone who stays on slightly old versions of iOS, that I can't even order food off of DoorDash is pretty frustrating. The reality is that people do in fact derelict these old devices under an expectation that everyone is rich enough to throw out perfectly functional equipment and replace it all the time. It is sad that Apple is actually the best at this :/.
I don't care about 3rd party delivery services but it looks like like DoorDash has a website so you can still be their customer.
It looks like their app requires iOS 13 which requires an iPhone 6s or newer (though it can run iOS 14 and will run iOS 15). The iPhone 6 won't run iOS 13, it had five years between its release and the release of an OS it can't run, that still seems like a respectable amount for a phone.
Apple is way better at supporting the longevity of their devices, through build quality and continued OS support, than the Android world is.
Given that my iPhone 6 cost $200 and I break a screen every 1-2 years, 5 years is more than enough. I’d never pay to replace a screen or battery on an old phone. I’d imagine a significant portion of devices have been accidentally smashed or dropped in a lake by that time.
>Well, as someone who stays on slightly old versions of iOS, that I can't even order food off of DoorDash is pretty frustrating.
Well, the idea with iOS/macOS is "Have a recent OS+Device, we change things all the time and demand that everyone moves along in 5-6 years or so".
With Windows it's "We support 20+ years old programs just fine. If you're OK with having to deal with 8+ layers of GUI code and legacy cruft, we're your thing".
It's not like this hasn't been the case for decades, for it to be a suprise...
Calling them 'essentially bricks' is calling them functionless, which they are not.
The iPhone 5/5c was released nine years ago. I'm just not crying for it. If your app dev isn't updating for iOS 15, you're stuck with the old version anyway. Sorry your decade-old device can't use the latest technology.
Well, I'll claim they are potentially worse than bricks, as they are riddled with remotely exploitable security holes (such as the various iMessage ones that come out every year)... like some kind of dangerous land mine in the shape of a brick.
This is a real problem for my device - I essentially can't download any "new" software since the app store only appears to make versions incompatible with the newest OS available - and my device (a 2012 iPad 4 Retina to be precise) refuses to update past iOS 10.3.3
Oh sorry to clarify 2018 is when my partner got their most recent Apple device which will be able to run this update fine - our previous device is a Retina iPad from 2012. Re-reading my wording yea, I can see how that read as hyperbolic, sorry about that!
>and yet all my apple devices from before 2018 are essentially now bricks.
I doubt many 2017 and 2016 models are "now bricks", though "before 2018" might also mean "2012" or so.
In any case, none of them is a "brick". Even the unreleased Monterey version, post AS reveal, still supports tons of pre-2018 models:
MacBook: Early 2016 and newer
MacBook Air: Early 2015 and newer
MacBook Pro: Early 2015 and newer
Mac Mini: Late 2014 and newer
iMac: Late 2015 and newer
iMac Pro: Late 2017
Mac Pro: Late 2013 and newer
And of course Big Sur continues to work on even earlier models.
A very similar story is true for iOS devices - which is in fact a much better story than vendor Android support (which usually is 3 years max) or Windows Phone (which was discontinued altogether).
I have an iPhone 6 and while it doesn’t have the new iOS it still has all sorts of useful functionality. Apple does great in this regard compared to say, Samsung. With Android devices you’re also dependent upon the carrier for updates, which is obviously not what anyone sane would desire.
My iPad Pro from 2017 works like the first day, I wanted to update but besides a nicer design there is not need to update it’s just super fast at everything
Are you me? Same here, except mine is from 2015. Apart from a small chip on the edge of the screen, as a result of overzealous cabin crew, it works as well as it did on Day 1.
Kind-of related because this article is on medium... Any downside to me blocking `||accounts.google.com/gsi/iframe/select` via ublock origin? Will this break my use of google drive or search engine?
I hope not because I'm doing it anyway. Medium.com makes me barf. Which is sad because it hosts some great content.
It appears to be related to sign-in flow[1], but may not affect signing in via Google.com or other Google-hosted services directly. It's the API for "Sign in with Google", far as I can tell here.
If you go to https://myaccount.google.com/permissions, you can turn off "Google Account sign-in prompts" on each of your Google Accounts and then you won't see any more of those prompts.
Don't know if Facebook has a similar option for their accounts though; I've seen a similar sign-in prompt elsewhere for Facebook.
