4 ms·

I think you have no experience with updating legacy iOS applications to modern SDKs. It is not just a matter of "recompile and push", it is: * Ensuring your co

by 0x0 9y ago

I think you have no experience with updating legacy iOS applications to modern SDKs. It is not just a matter of "recompile and push", it is: * Ensuring your code still works now that CGFloat and ints change size (can easily trip up code, I've seen things fail subtly and then grow into huge errors with combinations of NSInteger and "-1" etc) * Updating all UI to handle new behavior (yes, just linking with a new compiler will automatically opt-in to new behavior that might totally break interactions and taps) * If your app is really old, rewrite all UI to not assume a 320px wide screen (this can be brutal) * Handling new restrictions and requirements such as supporting IPv6-only network (fun if your app is used to configure an IoT device over IPv4 LAN), and Transport Security (fun if your app allows users to connect to random servers around the world) * Handling new permission models for camera/gps/contacts/photo library/audio library access, including refactoring your code to deal with asynchronous results * Updating all your graphic assets for @2x and @3x resolution as well as new app icon sizes (hope you still have those .PSD files, and hope your designer wasn't doing pixel-perfect painting for your bitmaps!) * The original developer must still be in business, still pay the $100/year developer fee, and still have the source code and the talent to fix it.

arrty88 9y ago
On top of all the technical details, you also have to abide by all the new AppStore policies to even get approved.
cjf101 9y ago
And this is the relatively easy case of an app built using Apple technologies. It can be much more difficult if you built a game using a cross platform game engine filled with binary 32bit libraries. If the engine is still around, you might be able to pay for a license for a newer version of the engine, but then you likely also need to deal with the SDK and format changes in the new engine as well as any iOS specific things you have. Still, if software is your business and this software in particular makes you money, it's really not _that_ expensive to do.
H1Supreme 9y ago
Exactly. I had a legacy app like this that was generating next to nothing in revenue. I lol'd at all the work I would have had to do to bring it up two versions of iOS, and left it alone.
valuearb 9y ago
As someone who has been developing iOS apps for 8 years, it’s preetty easy. If you wrote code that depended upon sizes of fundamental types, you didn’t write good code. if you weren’t using resources to lay out UI, you didn’t think ahead. 2x and 3x graphics can be created from your originals with OSX preview. It’s far easier to rewrite old apps today than ever. The tools are far better. The APIs are far better. Asynchronous code is trivial to implement with GCD nowadays. The real truth is you won’t pay the developer for their time, so they won’t give it to you. It has nothing to do with Apple.
- 0x0 9y ago
  I didn’t say it was impossible, I was just argung that updating legacy apps is a lot more work than clicking a recompile button and uploading the result. The loser here is the end-user, who can’t access their files inside legacy apps or control devices that depend on legacy apps or even just enjoy a paid-for game. And that’s all on Apple, who surely could have offered 32bit support for several more years, even if they froze the api level on 32bit uikit/corefoundation to iOS10, and as an optional on-first-use download, for existing app-owners only (so obviously they get to hold their app store storefront clean).
  - valuearb 9y ago
    No the winner is the user who doesn't have to host hundreds of megabytes of 32 bit libraries in memory on their device.
    - 0x0 9y ago
      That could easily be solved by offering 32bit support as an optional download, just like how 32bit windows10 prompts to install the 16bit ntvdm support libraries on first use. Or just like how iOS itself mounts a developer disk image provided on-demand by xcode during the first debug session, adding more items to the general ios settings menu in the process A few hundred megabytes is certainly a small price to pay for users who need those legacy apps to unlock files/documents stored inside or the features the app might to provide to interface with legacy IoT devices or even a car.

by 0x0 9y ago

arrty88 9y ago

On top of all the technical details, you also have to abide by all the new AppStore policies to even get approved.

cjf101 9y ago

And this is the relatively easy case of an app built using Apple technologies. It can be much more difficult if you built a game using a cross platform game engine filled with binary 32bit libraries. If the engine is still around, you might be able to pay for a license for a newer version of the engine, but then you likely also need to deal with the SDK and format changes in the new engine as well as any iOS specific things you have. Still, if software is your business and this software in particular makes you money, it's really not _that_ expensive to do.

H1Supreme 9y ago

Exactly. I had a legacy app like this that was generating next to nothing in revenue. I lol'd at all the work I would have had to do to bring it up two versions of iOS, and left it alone.

valuearb 9y ago

As someone who has been developing iOS apps for 8 years, it’s preetty easy. If you wrote code that depended upon sizes of fundamental types, you didn’t write good code. if you weren’t using resources to lay out UI, you didn’t think ahead. 2x and 3x graphics can be created from your originals with OSX preview. It’s far easier to rewrite old apps today than ever. The tools are far better. The APIs are far better. Asynchronous code is trivial to implement with GCD nowadays. The real truth is you won’t pay the developer for their time, so they won’t give it to you. It has nothing to do with Apple.

0x0 9y ago
I didn’t say it was impossible, I was just argung that updating legacy apps is a lot more work than clicking a recompile button and uploading the result. The loser here is the end-user, who can’t access their files inside legacy apps or control devices that depend on legacy apps or even just enjoy a paid-for game. And that’s all on Apple, who surely could have offered 32bit support for several more years, even if they froze the api level on 32bit uikit/corefoundation to iOS10, and as an optional on-first-use download, for existing app-owners only (so obviously they get to hold their app store storefront clean).
- valuearb 9y ago
  No the winner is the user who doesn't have to host hundreds of megabytes of 32 bit libraries in memory on their device.
  - 0x0 9y ago
    That could easily be solved by offering 32bit support as an optional download, just like how 32bit windows10 prompts to install the 16bit ntvdm support libraries on first use. Or just like how iOS itself mounts a developer disk image provided on-demand by xcode during the first debug session, adding more items to the general ios settings menu in the process A few hundred megabytes is certainly a small price to pay for users who need those legacy apps to unlock files/documents stored inside or the features the app might to provide to interface with legacy IoT devices or even a car.