3 ms·

I've been hearing a lot about people not wanting to upgrade. My question is, putting aside the overhead of submitting to the App Store, writing release notes, e

I've been hearing a lot about people not wanting to upgrade. My question is, putting aside the overhead of submitting to the App Store, writing release notes, etc. I thought that the only step that would actually be involved would be to recompile the app? Unless you have something like hand rolled modules of Assembly or inline functions, would it really be that difficult?

kuon 9y ago
Fetching the project from archives (most of the time, just a git clone, but you have to find it), re-familiarizing with the project build process (do I need to fetch some assets that are not in git?), Xcode updating the project and breaking everything, having a gazillion of deprecated warning, code signing certificate have to be re-issued, the SDK you had is not available anymore so you have to update the APIs... It can quickly take a day, a week... depending on the App.
- bigiain 9y ago
  Yeah, 3rd party SDKs are a problem for us. We've got a project waiting to go live, but one vendor won't give us an iOS11 "certified" SDK until 2 weeks after iOS11 ships... (And yeah, their current SDK crashes in iOS11... It's almost like they don't even know you can get access to iOS betas...)
apocalyptic0n3 9y ago
For apps that are still 32-bit only, they have to be several years old. I believe the first version to support 64 bit was iOS 7 and at that point, I think Xcode would compile with universal support by default. Most of our affected apps were built for iOS 6 (or lower) and the clients have not wanted to pay to keep them up to date. As a result, an update at this point requires quite a bit of work because of deprecated and removed APIs preventing us from recompiling. Then you have the issue of third-party libraries that may not support 32 bit, so you have to go find updated version (if they exist. If they don't, you have to completely remove it and find a replacement) You are correct, though, that in the best case, it is just a recompile.

kuon 9y ago

Fetching the project from archives (most of the time, just a git clone, but you have to find it), re-familiarizing with the project build process (do I need to fetch some assets that are not in git?), Xcode updating the project and breaking everything, having a gazillion of deprecated warning, code signing certificate have to be re-issued, the SDK you had is not available anymore so you have to update the APIs... It can quickly take a day, a week... depending on the App.

bigiain 9y ago
Yeah, 3rd party SDKs are a problem for us. We've got a project waiting to go live, but one vendor won't give us an iOS11 "certified" SDK until 2 weeks after iOS11 ships... (And yeah, their current SDK crashes in iOS11... It's almost like they don't even know you can get access to iOS betas...)

apocalyptic0n3 9y ago

For apps that are still 32-bit only, they have to be several years old. I believe the first version to support 64 bit was iOS 7 and at that point, I think Xcode would compile with universal support by default. Most of our affected apps were built for iOS 6 (or lower) and the clients have not wanted to pay to keep them up to date. As a result, an update at this point requires quite a bit of work because of deprecated and removed APIs preventing us from recompiling. Then you have the issue of third-party libraries that may not support 32 bit, so you have to go find updated version (if they exist. If they don't, you have to completely remove it and find a replacement) You are correct, though, that in the best case, it is just a recompile.