3 ms·
Well you can always ship updates with the old iOS 13 SDK toolchain (Xcode 11) the entire time. You could have tested on the iOS 14 betas, and if you found a cra
by 0x0 6y ago
Well you can always ship updates with the old iOS 13 SDK toolchain (Xcode 11) the entire time. You could have tested on the iOS 14 betas, and if you found a crash, you could try to implement a workaround and resubmit in the weeks and months leading up to today.
Sometimes your crash is because of bad assumptions in your code, or sometimes your crash is due to real Apple bugs creeping into the iOS APIs. Not saying it's always possible to implement a workaround, but it's not as bad as the blog post makes it out to be.
- saagarjha 6y agoThat is correct. But I know for many apps building for iOS 14 is a requirement or bad things will happen™.
- 0x0 6y agoCare to elaborate? Did Apple break backwards compatibility with apps built on the iOS 13 SDK with no way to work around it? Seems hard to believe that everyone upgrading to iOS 14 will end up with no functional third party apps today?
- saurik 6y agoApple does a lot of weird "quirks mode"-like BS by checking for what version of a library or toolchain was linked against at build time (and with multiple kinds of checks, which is annoying). I absolutely have experienced cases numerous times where my app was fine if it just was allowed to run, but Apple insisted "no, this app was compiled against an iOS SDK so it should get a shitty and broken simulation of the older skeuomorphic properties panel, and should do some ridiculous reverse display scaling on this new iPad we just released"... and to be clear that this is merely the quirks mode BS, my solution finally to not have to keep updating my copy of Xcode was to get angry and write a tool to edit my binaries and update their load command version references. I have no clue what Apple thinks they are accomplishing with these checks.
- saagarjha 6y ago> to be clear that this is merely the quirks mode Most of the problems I hear this year are not the compatibility checks that Apple had out in but UIKit just being broken for certain things. The difference being of course that “compatibility quirks” is Apple knowingly trying to fix something and doing a poor job as opposed to what’s happening here where they just changed random stuff and thought it was compatible but it the observed behavior is now different and breaks apps. For example, I have a bog-standard navigation bar that’s been broken since iOS 13 (if I build for that SDK) because Apple evidently thinks that they did their implementation correctly but somehow the way I have put my table view in a navigation view in a tab view (real complicated, I know) is something they couldn’t keep consistent.
- jonas21 6y agoOne example is the new photos permission API. If you don't rebuild for iOS 14, your app will continue to work... but your users get a horrendous experience where they're presented with a confusing permissions popup every time they launch your app. I'm sure there are other examples as well.
- coldtea 6y agoThat's FUD
- matwood 6y ago> Well you can always ship updates with the old iOS 13 SDK toolchain (Xcode 11) the entire time. You could have tested on the iOS 14 betas, and if you found a crash, you could try to implement a workaround and resubmit in the weeks and months leading up to today. When I was an iOS developer, this is exactly what I did. Install iOS beta, find any show stopper bugs, fix them in the current SDK and get the bug fix out. Most of the time it was just the beta OS highlighting an existing bug that the current OS ignored. Once the bugs are fixed, then start adding beta OS features. These features often have to be gated anyway since it's normal to want to support current version -1 or -2. So yeah, Apple should have given more than a day, but it's not nearly as serious as the hot takes want to make it out to be.