5 ms·

> it's possible to ship fixes for a new iOS version before that iOS version actually launches No it isn't. Apple doesn't permit code linking against the latest

> it's possible to ship fixes for a new iOS version before that iOS version actually launches No it isn't. Apple doesn't permit code linking against the latest SDK to be submitted until the SDK goes "GM". That happened today.

geoffpado 6y ago
To expand on this, if your app is "broken" because of changes made that require new OS features in order to "fix" them (such as the new limited permissions for photos, contacts, and location), you were completely unable to issue a new update to fix them until the end of the event. That gives you ≈24 hours to get the new GM, create a build (including setting up your CI system with the new GM, if applicable), make sure no new bugs have been introduced, submit to and get approved by App Review, and launch the update. If you couldn't get all that done in that time, you're probably going to have at least a few negative app reviews from early adopters.
- saurik 6y ago
  And even then, who is to say that users are going to instantaneously download your update before/during their upgrade to iOS 14 (even if they have automatic app upgrades turned on, which they might not).
  - saagarjha 6y ago
    Being able to point your users to an update to fix their problems when they come to you for support, or when they go to write an angry review that their app is crashing but they see “iOS 14 support” at the top of the app’s page, is likely to help there. Especially since the earliest adopters are frequently technically competent enough to do that but also frequently demanding enough that their apps work on day one.
    - ryandrake 6y ago
      So, maybe you can get to it in a couple of days. Fix what you can using the old SDK before GM build becomes available. Then you have a small amount of updates once apps using the new SDK can be submitted. The app will be temporarily broken for a few days on a brand new OS until the update goes live. Is that really a big deal? The world doesn't come to an end if you get a few bad reviews from impatient users. I remember being in the mobile app development rat race and am so glad I left that world behind. Too much daily panic about things that really don't matter much.
      - saagarjha 6y ago
        Ok, but surely you can understand why people would be upset with Apple for doing this when they had no reason to do so?
- jmull 6y ago
  The new location precision user auth seems to have been done in a backwards compatible way, at least in my testing: - app with existing location permission in iOS 13 gets precise location. - when the user prompt appears, it looks like precise location is the default in the UI. (This is with an app build against iOS 13 SDK -- not sure yet if the iOS 14 SDK changes things.) I think Apple will likely change this in the future, but right now devs are getting the time they need to adjust. (As is, this new permission does almost nothing since 99% users will accept the defaults. I think they'll probably require more explicit action on the user's part to get precise location in the future.)
metaloqui 6y ago
That isn't strictly true, several apps have launched their iOS14 ready versions ahead of the public release. All they can't do is use new SDK features.
- richardwhiuk 6y ago
  You can't link against the new SDK, but you can link against an old SDK, but fix the bugs which are associated with iOS 14. ~All of the bugs I've ever seen on a new iOS release are just where they've tightened up some behaviour.
  - saagarjha 6y ago
    You say "tightened up" and perhaps that's what they meant internally, but as it stands my (simple) app's behavior when using the search bar is different and broken on the new update even though I'm using the API in a supported way. So it's really a bug.

geoffpado 6y ago

To expand on this, if your app is "broken" because of changes made that require new OS features in order to "fix" them (such as the new limited permissions for photos, contacts, and location), you were completely unable to issue a new update to fix them until the end of the event. That gives you ≈24 hours to get the new GM, create a build (including setting up your CI system with the new GM, if applicable), make sure no new bugs have been introduced, submit to and get approved by App Review, and launch the update. If you couldn't get all that done in that time, you're probably going to have at least a few negative app reviews from early adopters.

saurik 6y ago
And even then, who is to say that users are going to instantaneously download your update before/during their upgrade to iOS 14 (even if they have automatic app upgrades turned on, which they might not).
- saagarjha 6y ago
  Being able to point your users to an update to fix their problems when they come to you for support, or when they go to write an angry review that their app is crashing but they see “iOS 14 support” at the top of the app’s page, is likely to help there. Especially since the earliest adopters are frequently technically competent enough to do that but also frequently demanding enough that their apps work on day one.
  - ryandrake 6y ago
    So, maybe you can get to it in a couple of days. Fix what you can using the old SDK before GM build becomes available. Then you have a small amount of updates once apps using the new SDK can be submitted. The app will be temporarily broken for a few days on a brand new OS until the update goes live. Is that really a big deal? The world doesn't come to an end if you get a few bad reviews from impatient users. I remember being in the mobile app development rat race and am so glad I left that world behind. Too much daily panic about things that really don't matter much.
    - saagarjha 6y ago
      Ok, but surely you can understand why people would be upset with Apple for doing this when they had no reason to do so?
jmull 6y ago
The new location precision user auth seems to have been done in a backwards compatible way, at least in my testing: - app with existing location permission in iOS 13 gets precise location. - when the user prompt appears, it looks like precise location is the default in the UI. (This is with an app build against iOS 13 SDK -- not sure yet if the iOS 14 SDK changes things.) I think Apple will likely change this in the future, but right now devs are getting the time they need to adjust. (As is, this new permission does almost nothing since 99% users will accept the defaults. I think they'll probably require more explicit action on the user's part to get precise location in the future.)

metaloqui 6y ago

That isn't strictly true, several apps have launched their iOS14 ready versions ahead of the public release. All they can't do is use new SDK features.

richardwhiuk 6y ago
You can't link against the new SDK, but you can link against an old SDK, but fix the bugs which are associated with iOS 14. ~All of the bugs I've ever seen on a new iOS release are just where they've tightened up some behaviour.
- saagarjha 6y ago
  You say "tightened up" and perhaps that's what they meant internally, but as it stands my (simple) app's behavior when using the search bar is different and broken on the new update even though I'm using the API in a supported way. So it's really a bug.