Over 187,000 apps could become obsolete with Apple's 64-bit only 'iOS 11'

2»

Comments

  • Reply 21 of 31
    pepe779 said:

    2. I have yet to see the true benefit of 64 bit mobile apps and at least one solid reason why 32 bit apps can no longer be supported.

    4. Microsoft had many opportunities to kill 32 bit apps on their desktop OS but they never did it. Why do we need to kill them on a mobile OS?

    I'll try to answer these two together. First off, the main benefit of the 32-bit to 64-bit transition on ARM and x86 wasn't the additional address space. Both architectures had accumulated a lot of cruft over the years (x86 more than ARM). So in both cases, the transition to 64-bit was used as an opportunity to clean up this cruft. In both cases, code compiled for the new 64-bit mode ran faster than 32-bit code on the same CPU.  That was the the main reason for Apple to introduce 64-bit support in the A7 and later. Faster code means that the CPU can go back to sleep faster, which means better battery life for mobile devices. 

    The reasoning behind why Apple wants to drop support for 32-bit apps is simple - resources on mobile devices are constrained. Loading a 32-bit app on a 64-bit device means loading in 32-bit versions of all the frameworks that the app uses. Normally when a framework is loaded, only one copy has to be in memory at a time since the memory is shared between all the processes that use that framework. Having the 32-bit version means that now the memory usage is doubled for any framework used in both modes. The biggest framework being UIKit, which powers the UI for all apps on iOS. 

    Add in the fact that 32-bit code runs slower and therefore uses battery up faster than 64-bit code, it becomes obvious why Apple wants to git rid of 32-bit code. 

    Once they get rid of 32-bit code, other minor benefits are enabled - their OS gets smaller because they don't have to include 32-bit frameworks. The apps get smaller for similar reasons. They can stop maintaining 32-bit support in their development tools, along with the QA load of testing 32-bit support. And they have an opportunity to flush out apps that literally haven't been updated in years from the store. 

    As for why Microsoft didn't get rid of 32-bit support, they have much different constraints. For one, desktop machines typically have much more memory than mobile devices. Loading an extra copy of all the libraries under Windows isn't going to be as intensive as doing so on iOS. Also Microsoft was a bit late in the 64-bit game - they introduced 64-bit with XP, but most people didn't run 64-bit Windows until well into Windows 7 or possibly even 8's lifetime. Pulling support for 32-bit apps on Windows would be very premature right now. Finally, Microsoft has a history of bending over backwards to keep old apps running, while Apple prefers to keep moving the platform forward and have their developers make sure apps are updated to run on the latest. Two different approaches, both with their positive and negative aspects.  

    I totally get that it's frustrating as a user - I'm potentially going to lose a few apps that I regularly use when this happens. But Apple has to be able to move the platform forward rather than holding things up because of laggard developers. 
    Soli
  • Reply 22 of 31
    pepe779pepe779 Posts: 84member
    pepe779 said:

    2. I have yet to see the true benefit of 64 bit mobile apps and at least one solid reason why 32 bit apps can no longer be supported.

    4. Microsoft had many opportunities to kill 32 bit apps on their desktop OS but they never did it. Why do we need to kill them on a mobile OS?

    I'll try to answer these two together. First off, the main benefit of the 32-bit to 64-bit transition on ARM and x86 wasn't the additional address space. Both architectures had accumulated a lot of cruft over the years (x86 more than ARM). So in both cases, the transition to 64-bit was used as an opportunity to clean up this cruft. In both cases, code compiled for the new 64-bit mode ran faster than 32-bit code on the same CPU.  That was the the main reason for Apple to introduce 64-bit support in the A7 and later. Faster code means that the CPU can go back to sleep faster, which means better battery life for mobile devices. 

    The reasoning behind why Apple wants to drop support for 32-bit apps is simple - resources on mobile devices are constrained. Loading a 32-bit app on a 64-bit device means loading in 32-bit versions of all the frameworks that the app uses. Normally when a framework is loaded, only one copy has to be in memory at a time since the memory is shared between all the processes that use that framework. Having the 32-bit version means that now the memory usage is doubled for any framework used in both modes. The biggest framework being UIKit, which powers the UI for all apps on iOS. 

    Add in the fact that 32-bit code runs slower and therefore uses battery up faster than 64-bit code, it becomes obvious why Apple wants to git rid of 32-bit code. 

    Once they get rid of 32-bit code, other minor benefits are enabled - their OS gets smaller because they don't have to include 32-bit frameworks. The apps get smaller for similar reasons. They can stop maintaining 32-bit support in their development tools, along with the QA load of testing 32-bit support. And they have an opportunity to flush out apps that literally haven't been updated in years from the store. 

    As for why Microsoft didn't get rid of 32-bit support, they have much different constraints. For one, desktop machines typically have much more memory than mobile devices. Loading an extra copy of all the libraries under Windows isn't going to be as intensive as doing so on iOS. Also Microsoft was a bit late in the 64-bit game - they introduced 64-bit with XP, but most people didn't run 64-bit Windows until well into Windows 7 or possibly even 8's lifetime. Pulling support for 32-bit apps on Windows would be very premature right now. Finally, Microsoft has a history of bending over backwards to keep old apps running, while Apple prefers to keep moving the platform forward and have their developers make sure apps are updated to run on the latest. Two different approaches, both with their positive and negative aspects.  

    I totally get that it's frustrating as a user - I'm potentially going to lose a few apps that I regularly use when this happens. But Apple has to be able to move the platform forward rather than holding things up because of laggard developers. 
    Thank you for taking your time and posting this complex explanation, that's truly appreciated. And I do understand most of those reasons and completely agree that it's a good thing from the overall user experience perspective. However, as you also noted towards the end, the reality of this is not so black or white, we can't force devs to update their abandoned apps and there's unfortunately way too many of them. And many of these apps still serve their purpose and many of them sadly don't have any true replacement for a variety of reasons. That's why I believe Apple should leave this decision up to the users to some degree, warn them that their user experience will be degraded (which they already did), but don't just kill those apps, otherwise people who really need those apps will either switch to android (where this is not an issue) or simply never upgrade to new iOS.
  • Reply 23 of 31
    davdav Posts: 102member
    Is there an easy way to determine which apps (on my iPad) are currently 32-bit?  or which apps have been discontinued by the developer -- I have too many apps, and don't pay attention to which ones update, or how current they are.
  • Reply 24 of 31
    pepe779pepe779 Posts: 84member
    dav said:
    Is there an easy way to determine which apps (on my iPad) are currently 32-bit?  or which apps have been discontinued by the developer -- I have too many apps, and don't pay attention to which ones update, or how current they are.
    Not within iOS as far as I know, Xcode would most likely be the only source of truth I'm afraid. This is yet another problem I have with Apple's decision to cut 32 bit support - it's nice that they're providing users and devs with such a long lead time, but they should also provide some basic tools for users to actually check what apps are going to be affected, so that they can search for alternatives (if at all possible) while there's still enough time. All they did was they introduced this annoying "this app may slow down your xyz" message, which only displays once unfortunately and by the time most of us figured out what this really means it's history and you won't find out anymore which apps displayed it. All I know is in my case it was roughly half of my apps and I don't think any of them have received any 64 bit updates since then.
  • Reply 25 of 31
    Soli said:
    r00fus1 said:
    So when is Apple going to revoke the cert? I mean that's why code signing is a requirement, right?
    Unless it's a danger to the user, I don't think Apple will use their remote kill switch. I think it comes down to no longer being in the store as the first step, and if you update to iOS 11 it won't work, as the second step.
    Could purchased apps still be downloadable on 32-bit hardware? Eg iphone 5? Im not sure i uderstand correctly what apple is doing exactly. Some devices arent even 64-bit so i guess its good bye iphone5 for the kids...
  • Reply 26 of 31
    I would appreciate it if Apple would add a new listing on the App Store noting whether this app is 32 or 64 bit. That would keep us from purchasing a 32 bit app which could quit working in iOS 11 and give the developers a push to upgrade their apps.
  • Reply 27 of 31
    SoliSoli Posts: 10,030member
    Soli said:
    r00fus1 said:
    So when is Apple going to revoke the cert? I mean that's why code signing is a requirement, right?
    Unless it's a danger to the user, I don't think Apple will use their remote kill switch. I think it comes down to no longer being in the store as the first step, and if you update to iOS 11 it won't work, as the second step.
    Could purchased apps still be downloadable on 32-bit hardware? Eg iphone 5? Im not sure i uderstand correctly what apple is doing exactly. Some devices arent even 64-bit so i guess its good bye iphone5 for the kids…
    Did Apple set up a system where old versions of apps were still available to users?

    edit: Not official, and it's kludgy.

    edited March 2017
  • Reply 28 of 31
    swat671swat671 Posts: 89member
    pepe779 said:
    dav said:
    Is there an easy way to determine which apps (on my iPad) are currently 32-bit?  or which apps have been discontinued by the developer -- I have too many apps, and don't pay attention to which ones update, or how current they are.
    Not within iOS as far as I know, Xcode would most likely be the only source of truth I'm afraid. This is yet another problem I have with Apple's decision to cut 32 bit support - it's nice that they're providing users and devs with such a long lead time, but they should also provide some basic tools for users to actually check what apps are going to be affected, so that they can search for alternatives (if at all possible) while there's still enough time. All they did was they introduced this annoying "this app may slow down your xyz" message, which only displays once unfortunately and by the time most of us figured out what this really means it's history and you won't find out anymore which apps displayed it. All I know is in my case it was roughly half of my apps and I don't think any of them have received any 64 bit updates since then.
    On iOS 10.3 beta, if you go Settings > General > About >  Applications, it will tell you which apps have compatibility issues. 
    edited March 2017 Soli
  • Reply 29 of 31
    swat671swat671 Posts: 89member
    I'm assuming it wouldn't be that hard for Apple to implement something like "universal apps" on iOS like they did when the Mac switched from PPC to X86. 
  • Reply 30 of 31
    SoliSoli Posts: 10,030member
    swat671 said:
    I'm assuming it wouldn't be that hard for Apple to implement something like "universal apps" on iOS like they did when the Mac switched from PPC to X86. 
    Isn't that what they did allowing developers to offer 32-bit and 64-bit code, aka" fat binaries," in their App Store apps?
  • Reply 31 of 31
    coolfactorcoolfactor Posts: 1,833member
    I entirely agree that app developers should be held to a certain standard. Apps should require an update to support each new version of iOS. That alone would keep, or at least prune, a lot of junk apps off the platform.
Sign In or Register to comment.