The Future of iOS is 64-Bit Only -- Apple To Stop Support For 32-Bit Apps (computerworld.in)

← Back to Stories (view on slashdot.org)

The Future of iOS is 64-Bit Only -- Apple To Stop Support For 32-Bit Apps (computerworld.in)

Posted by msmash on Wednesday February 1, 2017 @02:40AM from the shape-of-things-to-come dept.

Your ability to run 32-bit apps on an iOS device is coming to an end. As several other Apple news sites have reported, Apple has updated the pop-up warning in the iOS 10.3 beta to say that the 32-bit app you're running "will not work with future versions of iOS." The warning goes on to say that the "developer of this app needs to update it to improve its compatibility." From a ComputerWorld article (edited for clarity): In October 2014, Apple told developers that all new apps created after February 1, 2015 must have 64-bit support. Shortly after, Apple announced that all updates to apps must also be 64-bit compatible. Any 32-bit apps submitted to Apple after June 2015 would be rejected. Last September, Apple announced that it was going to remove apps from the App Store that did not "function as intended, don't follow current review guidelines, or are outdated." Presumably, this would include apps that did not meet the 64-bit requirement. Apple does not state which version of iOS will be 64-bit only, but since this is a major development, you can probably assume that this will happen in iOS 11. An announcement will likely be made during Apple's Worldwide Developer Conference this summer. The switch to 64-bit only support means that older iOS devices built on 32-bit architecture will not be able to upgrade to the new iOS. This includes the iPhone 5, 5c, and older, the standard version of the iPad (so not the Air or the Pro), and the first iPad mini.

73 of 105 comments (clear)

Min score:

Reason:

Sort:

Assumption by mccalli · 2017-02-01 02:43 · Score: 4, Informative

Apple has said no such thing and this is assumption based on extrapolation of some dialog text. I think it is likely, but this is being presented as fact when it's still assumption at this point.
1. Re:Assumption by NatasRevol · 2017-02-01 02:51 · Score: 1
  
  Well, did you see the ComputerWorld artilce copied in TFS? Because it says Apple did say that.
  
  --
  There are two types of people in the world: Those who crave closure
2. Re:Assumption by mccalli · 2017-02-01 02:54 · Score: 1
  
  It doesn't. Apple have said you must support 64bit. They haven't said you must drop 32bit. Universal apps could still be supported.
3. Re:Assumption by NatasRevol · 2017-02-01 02:56 · Score: 1
  
  So in your world, 'must support 64bit' isn't 'must drop 32bit'?
  
  --
  There are two types of people in the world: Those who crave closure
4. Re:Assumption by mccalli · 2017-02-01 02:58 · Score: 1
  
  Correct. Universal apps, or fat binaries or whatever you want to call them, are the norm in Appleland and have been for quite some time. You distribute a single application and the system picks which binary to actually run.
5. Re:Assumption by TheRaven64 · 2017-02-01 03:01 · Score: 3, Informative
  
  Correct. Previously you were allowed 64-bit only, 32-bit only, and 32- or 64-bit universal. Now you are not allowed 32-bit only. That said, 64-bit does have some quite significant advantages for iOS, so I don't imagine Apple wanting to keep the 32-bit code around in the OS for longer than they have to. If you've got an iOS device with a 32-bit processor, your days of updates are probably numbered.
  
  --
  I am TheRaven on Soylent News
6. Re:Assumption by squiggleslash · 2017-02-01 03:22 · Score: 2
  
  The flaw in your argument is that supporting 64 bit and 32 bit binaries on OS X derived operating systems is not mutually exclusive. Indeed, at one point (one small point, lasting a year or two during the transition to Intel) most desktop apps on OS X were shipped supporting 32 bit PPC, 64 bit PPC, 32 bit ix86, and 64 bit amd64 architectures - all in the same package.
  OS X derived OSes use a system called "fat binaries" that contain two or more binaries compiled - usually from the same source code - for each CPU architecture the app supports. The operating system chooses which to run. Interestingly I believe ELF has the same capability, but nobody ever uses it.
  Don't worry, I suspect your misapprehension is common and is why the article is misleading to begin with...
  
  --
  You are not alone. This is not normal. None of this is normal.
7. Re:Assumption by hattig · 2017-02-01 04:06 · Score: 1
  
  An old (as updated apps have mandated a 64-bit binary alongside the 32-bit one for a while now) 32-bit app would still work if the OS supported 32-bit apps.
  Therefore, logically, support for 32-bit-only apps is going. This may be an iOS 11 thing, or it may be an Apple A11 thing (remove AArch32 support in hardware).
  It's likely an OS thing - maintaining two sets of OS APIs must have quite some overhead, when there are so many.
8. Re:Assumption by Khyber · 2017-02-01 04:06 · Score: 2, Funny
  
  "That said, 64-bit does have some quite significant advantages for iOS, so I don't imagine Apple wanting to keep the 32-bit code around in the OS for longer than they have to."
  64-bit is nothing but extended 32-bit x86 (at least, as far as Intel/AMD goes.) There's literally no reason for essentially basic x86 code to not fucking run. There are tons of programs that simply do not benefit from having a 64-bit address space and forcing them to code for it is just adding unnecessary bloat and vulnerability.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
9. Re:Assumption by Half-pint+HAL · 2017-02-01 04:14 · Score: 1
  
  This article is about iOS, not Mac OS/OS X. There are no fat binaries on iOS -- it is an either/or proposition.
  
  --
  Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
10. Re:Assumption by Archibald+Buttle · 2017-02-01 04:22 · Score: 2
  
  iOS devices are not x86 based - they're ARM - so no "basic x86 code" will run on them at all.
  The only place that iOS runs on x86 is in the simulator on OS X and such x86 code is not included in builds for iOS devices.
  64-bit ARM is different from 32-bit ARM, and not even remotely like "extended 32-bit x86".
11. Re:Assumption by MachineShedFred · 2017-02-01 04:24 · Score: 1
  
  No, it isn't. Have you heard of a "fat binary" that can contain both 32-bit and 64-bit versions of the app? Does that concept not exist in "your world", as you put it?
  it's only been a thing for like 10+ years now in the rest of "our world." Such a package would "support 64-bit" while not dropping 32-bit.
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
12. Re:Assumption by Khyber · 2017-02-01 04:26 · Score: 1
  
  Okay, so basic 32-bit ARM code doesn't run on 64-bit ARM hardware.
  Way to kill ARM's usefulness, Apple. Meanwhile, on my Android phone, I can run whatever the fuck I want without issue.
  Further proof that Apple isn't about giving people what they need, only what they want, and they take advantage of it to the degradation of the computing community.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
13. Re:Assumption by MachineShedFred · 2017-02-01 04:27 · Score: 1
  
  Article is still talking about iOS here, which is not x86 in any way. It's ARM.
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
14. Re:Assumption by TurboStar · 2017-02-01 04:34 · Score: 2
  
  \There's literally no reason for essentially basic x86 code to not fucking run.
  You believe that because you don't understand how powerful an MMU can be when coupled with non-volatile storage and how difficult and resource intensive maintaining a 32-bit compatibility layer can be.
15. Re:Assumption by Dog-Cow · 2017-02-01 04:53 · Score: 2
  
  You are completely ignorant. Developers have been shipping fat binaries on iOS for years. Even before the 5s added 64bit support. Virtually every iOS ships with three slices today: armv7, armv7s and arm64.
16. Re:Assumption by squiggleslash · 2017-02-01 05:05 · Score: 1
  
  FFS, why do you think I used the term "OS X derived operating system" throughout my comment? Or do you think iOS isn't derived from OS X?
  And yes, there are fat binaries in iOS. There always have been. You think Apple thought "Nah, we're never going to use anything but 32 bit ARM for our iDevices?" when they built iOS and wasted huge amounts of time removing the functionality? How do you think developers handle the situation today? Do they just ship 32 bit executables, because if they ship 64 bit executables then anyone with an older device will be unable to use their apps?
  
  --
  You are not alone. This is not normal. None of this is normal.
17. Re:Assumption by Solandri · 2017-02-01 05:06 · Score: 1
  That said, 64-bit does have some quite significant advantages for iOS, so I don't imagine Apple wanting to keep the 32-bit code around in the OS for longer than they have to.
  Microsoft ran the same hyped up 64-bit campaign when switching from 32-bit to 64-bit Windows.
  
  64-bit basically gets you three things.
  
  A flat memory space above 4 GB of RAM. This is convenient (especially if a single program actually needs to store more than 4GB of data), but not necessary. 8-bit could only address 256 bytes of memory, 16-bit only 64kB. We got around in those days with segmented memory. Given a choice I would always pick flat memory over segmented, but it's not a show-stopper.
  
  double floats and long ints (long long int in the old days) can be loaded and handled in one instruction instead of two. Regular floats are 32-bit, as are regular ints (long int in the old days). Those are handled exactly the same as on a 32-bit processor. The vast majority of programs do just fine with a 4 billion int range, and single point floating point.
  
  Char types can be handled 8 bytes at a time instead of 4 bytes at a time. This isn't as useful as it sounds - it mostly affects data compression where you're handling a long, continuous stream of chars. Most other operations are not bottlenecked by the speed at which you can handle chars.
  
  That's it. The vast majority of programs run exactly the same speed in 32-bit as they do in 64-bit, except they take up a bit more memory. So there's no advantage to 64-bit, and a slight disadvantage. The only programs which benefit from 64-bit are ones which need more than 4GB of RAM (no iOS device yet has more than 4GB of RAM), ones which need double floats or long ints (mostly scientific applications large accounting databases and spreadsheets - stuff you wouldn't want running on an iOS device), and ones which do a lot of data processing like compression. Most of the speed advantages of Apples 64-bit processors in iOS device benchmarks was due to new instructions and hardware functions they added, not due to it being 64-bit.
  
  As practically no iOS program can actually use 64-bit to its advantage on their current hardware, right now it's mostly marketing hype to get people with older hardware to feel bad and upgrade (even though the upgrade provides no advantage). Long-term, Apple is being proactive about trying to avoid falling into the trap Office fell into. A lot of the extensions written for Office are 32-bit, so Microsoft still recommends installing 32-bit Office instead of 64-bit Office a decade after we transitioned to 64-bit Windows.
18. Re:Assumption by Guspaz · 2017-02-01 05:14 · Score: 1
  
  32-bit code runs fine on 64-bit ARM processors: Apple has been doing it for years. 64-bit ARM is not not a minor extension to 32-bit ARM as is the case on x86, though. Apple may have decided they want to slim down iOS by removing all the 32-bit binaries/libraries, or they may have decided that they want to drop the 32-bit instruction set from their processors to spend the transistors on something else. Or perhaps they've decided to do no such thing, since this is all based on assumptions from a textbox in a beta OS that says such a thing might happen in the future.
19. Re:Assumption by Anonymous Coward · 2017-02-01 05:16 · Score: 1
  
  64bit is clearly the way forward with the memory sizes in mobile devices.
  It makes little sense to maintain the compatablity/interop part of your operating system if you're working away from 32bit. Apple has tight control of their environment and there isn't any good legacy reason to keep 32bit applications.
  Apple shipped the 5s, their flagship phone, with a 64bit arm CPU when nobody was even /sampling/ 64bit arm silicon. Apple has a big jump on 64bit and they've been working towards this for years.. When the last 32bit only iOS devices fall off of extended support, so will 32bit iOS apps.
20. Re:Assumption by the_B0fh · 2017-02-01 06:05 · Score: 1
  
  Seriously? How do you think 32bit and 64bit binaries exist in a package? Do you think Apple, having developed this for OS X, would then turn around and do something else on iOS, which is basically running on top of the OS X kernel?
21. Re:Assumption by the_B0fh · 2017-02-01 06:08 · Score: 2
  
  Apple is forcing the app developers to keep their applications updated. On the source code side, they have to do some minor work.
  Apparently you think this is a bad thing. Why?
22. Re:Assumption by UnknowingFool · 2017-02-01 06:10 · Score: 1
  
  Way to kill ARM's usefulness, Apple. Meanwhile, on my Android phone, I can run whatever the fuck I want without issue.
  Assuming what you said is true (which it isn't), I don't think Apple, even with their architectural license from ARM, can fundamentally change how ARM 32 bit APIs work. By the way, you do realize that Android suffers from the same problem because your Android OS makes the same ARM API calls.
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
23. Re:Assumption by the_B0fh · 2017-02-01 06:10 · Score: 2
  
  You are really such an expert on 64 bit arm architecture and iOS architecture aren't you? Have you even looked up any of the discussions that happened when Apple first delivered a 64bit CPU on a phone back in the iPhone 5S days, when none of the other manufacturers even had a solid roadmap? And why do you think things that are true in the wintel x86 world applies to iOS on ARM?
24. Re:Assumption by UnknowingFool · 2017-02-01 06:24 · Score: 1
  
  The only programs which benefit from 64-bit are ones which need more than 4GB of RAM (no iOS device yet has more than 4GB of RAM), ones which need double floats or long ints (mostly scientific applications large accounting databases and spreadsheets - stuff you wouldn't want running on an iOS device),
  That's not true. There are many advantages to using a 64 bit processor including cryptography. One of the main reasons is ARM itself will stop developing architectures for 32 bit processors. While you could buy and use 32 bit ARM legacy chips in the future, it is unlikely that ARM will continue to develop them further.
  
  As practically no iOS program can actually use 64-bit to its advantage on their current hardware, right now it's mostly marketing hype to get people with older hardware to feel bad and upgrade (even though the upgrade provides no advantage).
  How do you know this?
  
  Long-term, Apple is being proactive about trying to avoid falling into the trap Office fell into. A lot of the extensions written for Office are 32-bit, so Microsoft still recommends installing 32-bit Office instead of 64-bit Office a decade after we transitioned to 64-bit Windows.
  The problem for Office isn't just that legacy was 32 bit. The problem is that Office hasn't advanced too many features that most people feel are worth paying for a new version 32 bit or 64 bit.
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
25. Re:Assumption by tlhIngan · 2017-02-01 06:41 · Score: 2
  
  While you could buy and use 32 bit ARM legacy chips in the future, it is unlikely that ARM will continue to develop them further.
  True, 32-bit ARMs have stopped at armv7.
  However, ARM will still have 32-bit cores based on it for a simple reason - ARM is used in a variety of locations. In fact, ARM has 3 separate families of processors. You have the A series ("application", or what most users see) which are the powerful processor line. You also have the M series ("microcontroller") which is a 32-bit small core typically running in Thumb mode (it's quite something to program a 32 bit processor knowing you have 8/16K of flash and 1-64k of RAM).
  There's also an R lineup for real-time processors, though I haven't personally dealt with them.
  The only 64 bit cores belong to the A family with no roadmap to add them to the M or R families.
26. Re:Assumption by Just+Some+Guy · 2017-02-01 06:44 · Score: 4, Insightful
  
  There's literally no reason for essentially basic x86 code to not fucking run.
  ISA aside, there sure is: a tiny computer with limited resources is spending quite a bit of them on providing a 32bit compatibility layer of libraries, etc. Tossing that would allow those resources to more efficiently run the other applications, save battery, use less of the small and finite flash storage, and so on. In the specific case of an iPhone, it likely also means that the apps in question are probably using ancient API versions that Apple would like to deprecate, low-res graphics, have fixed-size and fixed-ratio display canvases, and aren't taking advantage of any modern features.
  None of those matter so much on a PC with (comparatively) enormous storage, huge amounts of RAM, and unlimited power drawn from a wall outlet. They're a pretty big deal on a phone, though.
  
  --
  Dewey, what part of this looks like authorities should be involved?
27. Re: Assumption by WarJolt · 2017-02-01 08:12 · Score: 1
  
  Android binaries are not native apps(with a few exceptions like ndk). 32 vs 64 bit argument is not really relevant for Android.
28. Re:Assumption by Applehu+Akbar · 2017-02-01 09:26 · Score: 1
  
  "Well, did you see the ComputerWorld artilce copied in TFS? Because it says Apple did say that."
  The warning is in an iOS beta, not the current release version.
29. Re:Assumption by Khyber · 2017-02-01 10:36 · Score: 1
  
  If it isn't broken (example, a guitar tuning program) why the fuck fix it?
  You fail at living up to your name, give it up.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
30. Re: Assumption by UnknowingFool · 2017-02-01 11:56 · Score: 1
  
  It is relevant because a 32 bit ARM processor simply won't run 64 bit applications whether it runs on Android or iOS. The OS itself makes the calls not the Apps in Android, but the Apps cannot suddenly do 64 bit operations without some major tweaking.
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
31. Re:Assumption by UnknowingFool · 2017-02-01 12:02 · Score: 1
  
  Again while 32-bit ARM will still be used for all sorts of applications in the future, I don't see them being used for smart phones any longer. Dumb phones maybe. Thus app developers will need to move to 64 bit now.
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
32. Re:Assumption by Half-pint+HAL · 2017-02-01 12:33 · Score: 1
  
  You are completely ignorant.
  Yes, I am.. or rather I was. Ignorance is cured by informing, so thank you for correcting me.
  
  --
  Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
33. Re:Assumption by Waccoon · 2017-02-01 15:30 · Score: 2
  
  Tossing that would allow those resources to more efficiently run the other applications, save battery, use less of the small and finite flash storage, and so on
  Not to mention other revolutionary modernizations, such as 6GB of new graphics, cutting-edge UX nonsense, and a thinner case with a smaller battery.
  I'd rather have the compatibility, thank you. I'm sick of living in a world where things more than a few years are forced to die because reasons.
34. Re:Assumption by TheRaven64 · 2017-02-02 02:12 · Score: 1
  
  That's it. The vast majority of programs run exactly the same speed in 32-bit as they do in 64-bit, except they take up a bit more memory
  
  That's not it at all. First, on a 64-bit system ASLR has a lot more bits to play with. In a 32-bit system, you're lucky to get 12 bits of entropy (Android gets 8 bits on 32-bit systems, which is one of the reasons StageFright was so bad: 256 probes took well under a second from JavaScript and pretty much guaranteed breaking ASLR). On a 64-bit system you can easily make the search space large enough to be infeasible to probe without the OS noticing something odd is going on.
  When running Objective-C code, you can store small objects inside pointers. On 32-bit systems this basically lets you store small ints, which isn't that useful (I don't think Apple even bothers). With 64-bit systems, you can store 7-character ASCII strings, which is enough for a lot of dictionary keys. This makes comparisons cheaper, reduces memory consumption, and improves cache usage (when I added this optimisation to the GNUstep Objective-C implementations, I found that 5-20% of total object allocations were stored inside the pointers instead of on the heap for typical desktop workloads). Apple also stores the refcount embedded in the class pointer for objects on 64-bit systems which, again, improves performance and cache usage.
  Supporting both AArch32 and AArch64 comes with several costs. ARMv8 makes both AArch32 and AArch64 optional (though they've now fixed the spec so you must implement at least one - until then I had the world's simplest ARMv8 compliant core...). Removing the AArch32 parts simplifies the silicon and improves power consumption. Not having to have 32-bit versions of all of the shared libraries installed means that you can dramatically reduce memory usage.
  
  --
  I am TheRaven on Soylent News
35. Re:Assumption by TheRaven64 · 2017-02-02 02:13 · Score: 1
  
  True, 32-bit ARMs have stopped at armv7.
  Not true. ARMv8 contains both AArch32 and AArch64. AArch32 ARMv8 is not the same as ARMv7, it adds several new instructions. M and R profile ARMv8 chips are all AArch32.
  
  --
  I am TheRaven on Soylent News
36. Re: Assumption by jeremyp · 2017-02-02 06:05 · Score: 1
  
  Aren't most Android apps essentially some form of Java byte code which is agnostic in terms of the word width of the virtual machine in which it is running?
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
you can still use your old apps by known_coward_69 · 2017-02-01 02:50 · Score: 3, Informative

your old phone will still work and even if you reset it you can download old versions of apps from the app store
you can stop hysterically crying now
1. Re: you can still use your old apps by HTH+NE1 · 2017-02-01 03:04 · Score: 1
  
  But if your apps are revealed to have a security flaw, those flaws will not get fixed for you. If the backend server supporting your app requires an upgrade that makes the old version incompatible, you lose access to that app's functionality. Unless you migrate to new hardware, your software will be forced into early obsolescence.
  
  --
  Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
2. Re:you can still use your old apps by The-Ixian · 2017-02-01 03:44 · Score: 1
  
  Alternative facts!
  I prefer to be outraged!
  
  --
  My eyes reflect the stars and a smile lights up my face.
3. Re:you can still use your old apps by known_coward_69 · 2017-02-01 03:47 · Score: 1
  
  then your device won't get the latest IOS and you will continue to use what you have
  i still have an ipad 2 that's on some old IOS and if i ever download an app on there it just downloads the latest version that works on that hardware and IOS level
4. Re: you can still use your old apps by known_coward_69 · 2017-02-01 03:50 · Score: 1
  
  so? same with everything
  nice thing about IOS is that apps run in their sandbox so that security issues most likely won't affect the whole system
5. Re:you can still use your old apps by Khyber · 2017-02-01 04:07 · Score: 1
  
  Wrong. I've already checked and 32-bit versions of Camfrog no longer exist for my fiance's old iPhone. So once that phone gets wiped, that's fucking it.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
6. Re: you can still use your old apps by Karlt1 · 2017-02-01 04:20 · Score: 1
  
  But if your apps are revealed to have a security flaw, those flaws will not get fixed for you. If the backend server supporting your app requires an upgrade that makes the old version incompatible, you lose access to that app's functionality. Unless you migrate to new hardware, your software will be forced into early obsolescence.
  In the real (not hypothetical) world, when I unpacked late last year, I found my old 1st generation iPad that stopped being officially supported with OS updates in 2012. I reset it because I forgot the password and started downloading apps, I got prompts that I can download an older version. I tried Facebook, Hulu, Plex, Netflix, Google Drive (for my technical PDFs), Crackle, and I believe the CW app. They all worked..
7. Re:you can still use your old apps by Karlt1 · 2017-02-01 04:23 · Score: 1
  
  And I just redownloaded DeadSpace that I bought years ago and was pulled from the app store over a year ago for new purchases.....
8. Re:you can still use your old apps by MachineShedFred · 2017-02-01 04:29 · Score: 1
  
  If you have a 32-bit processor, why would you be able to update to a 64-bit only OS? Why would Apple release an OS for a 32-bit device that can't run 32-bit apps?
  This is such a non-issue it's not even funny.
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
9. Re: you can still use your old apps by MachineShedFred · 2017-02-01 04:34 · Score: 1
  
  How is that any different from any other software publisher on any other platform, ever?
  Example: Microsoft releases a new version of Windows, which cuts off minimum support for otherwise perfectly working hardware. App developer X targets new version of Windows because it has a new spiffy API that allows them to cut out huge chunks of ass-pain code, causing their minimum OS requirement to be the new version of windows. Customer Y who has a PC that won't run the new version of Windows is stuck with old version of app X, which couldhave any of the issues above.
  The world moves on, and backwards compatibility must be cut off at some point in order to do it.
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
10. Re:you can still use your old apps by Guspaz · 2017-02-01 05:17 · Score: 1
  
  And the iPad 2 will never have this problem, both because it has a 32-bit processor, and because it doesn't run anything newer than iOS 9.3.5.
11. Re:you can still use your old apps by UnknowingFool · 2017-02-01 06:07 · Score: 1
  
  Presumably you won't be able to run 10.3 and newer.
  
  --
  Well, there's spam egg sausage and spam, that's not got much spam in it.
12. Re: you can still use your old apps by Just+Some+Guy · 2017-02-01 06:52 · Score: 1
  
  AFAIK, all Apple devices introduced in 2013 and later have been 64-bit. I don't think you can reasonably call mobile devices older than that "early obsoleted".
  In before "I still use my Amiga and a Palm IIIxe, and these modern kids with their wasteful ways, upgrading every decade argh warble". That's nice, Grandpa. But in the real world, people upgrade their mobile devices at least every 4 years. That might not be as true now as we're approaching "good enough" in a lot of ways, but I sure as hell wouldn't want to be saddled with an iPhone 5 (the last 32-bit model) today.
  
  --
  Dewey, what part of this looks like authorities should be involved?
13. Re:you can still use your old apps by unixisc · 2017-02-01 08:04 · Score: 1
  
  That's not how it works. I had the first or second generation of iPod touch and had some neat apps on it. Unfortunately, that thing could only upgrade upto iOS 4.3, so after a while, there were no apps in the app store that would work w/ that version. Best one can do is back it up on iTunes, which I did.
14. Re: you can still use your old apps by Blaskowicz · 2017-02-01 08:08 · Score: 1
  
  saddled with an iphone 5?, lol a couple years ago iphone 4S still was popular.
  It's all just Game Boys with a touch screen and a modem anyway. What are people doing with them, running Crysis?
15. Re:you can still use your old apps by Schnapple · 2017-02-01 10:05 · Score: 1
  
  Presumably you won't be able to run 10.3 and newer.
  
  Looks like 10.3 will still be usable, the "future version" of iOS is likely iOS 11.
  
  --
  Schnapple
Re:32 bit emulator App by UnknowingFool · 2017-02-01 03:32 · Score: 1

And how will they get rich? They'll have to run it somewhere. It's unlikely Apple will allow it to run in iOS. While it might run on other devices, the apps will not as they are locked to iOS.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Good.jpg by bigdady92 · 2017-02-01 03:47 · Score: 1

Even more reason to toss your Iphone 5 in the trash and get an Iphone X.

--
Wheel of Time: Book by Book and Sumview (summary review) Bigdady92 style: http://bigdady92.blogspot.com/
Re:32 bit emulator App by Anonymous Coward · 2017-02-01 03:59 · Score: 1

Good luck with that. Apple would never allow one to get into iStore, as it would contradict with their planned obsolescence strategy.
Not true! by edxwelch · 2017-02-01 04:04 · Score: 1

It doesn't matter if that you can download old apps from the App store. The restriction is being enforced by the operating system. If you have iOS 10.3 installed on your device it will not run 32-bit apps, as the article states.
Also not many people realise that this has happened before. iOS 9 broke old versions of apps by inforcing requirement of root viewcontroller, which hadn't been inforced before.
1. Re:Not true! by RandyHill · 2017-02-01 07:36 · Score: 1
  
  Uh, 10.3 already runs 32 bit apps. I am running them now on it.
2. Re:Not true! by edxwelch · 2017-02-01 08:26 · Score: 1
  
  it gives you a warning though. In 10.4 it'll be disabled.
Aren't 32-bit devices off support anyway...? by Half-pint+HAL · 2017-02-01 04:21 · Score: 1

I'm a bit confused about this "stopping" support for 32-bit devices, because as of iOS 10, all non-retina devices are already unsupported, and I didn't think there was a single 32-bit retina iOS device anyway.
What we're looking at here is Apple slowly phasing out the last remnants of sales to old devices. It has been impossible for over a year to release new software targeted at people with old devices through the App Store, and it is about to become impossible to sell them new copies of software that was previously released.
This is what gets me about the Apple model (I'm an iPad Mini user -- non-retina) -- the walled garden does an awful lot to preserve the security of the device, but they then brick us old users up in a tiny corner when us and the devices we bought are of no interest to them. If they want to rent us iPads, rent us them. Don't sell them to us then make them useless when the hardware is still working perfectly well.

--
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
1. Re:Aren't 32-bit devices off support anyway...? by angryargus · 2017-02-01 05:13 · Score: 3, Informative
  
  I didn't think there was a single 32-bit retina iOS device anyway.
  The iPhone 5 is a 32-bit retina device.
2. Re:Aren't 32-bit devices off support anyway...? by edxwelch · 2017-02-01 05:15 · Score: 2
  
  No. They're stopping support of running 32-bit apps on 64-bit devices.
3. Re:Aren't 32-bit devices off support anyway...? by Guspaz · 2017-02-01 05:23 · Score: 1
  
  It's more about users with modern devices that are still using 32-bit apps that haven't been updated in ages. Those apps may not even support retina displays.
  In terms of 32-bit retina devices, the iPhone 4 was the first retina iPhone, while the iPhone 5S was the first 64-bit iPhone. Ditto for the iPad, there were a bunch of retina 32-bit devices.
  Apple has tended to offer software support for their older devices for years longer than Google/Microsoft/RIM/etc have. While you could definitely argue that they're still not doing enough in that regard, they're already doing far more than any of the other smartphone manufacturers are.
4. Re:Aren't 32-bit devices off support anyway...? by RailRide · 2017-02-01 06:10 · Score: 1
  
  What we're looking at here is Apple slowly phasing out the last remnants of sales to old devices. It has been impossible for over a year to release new software targeted at people with old devices through the App Store, and it is about to become impossible to sell them new copies of software that was previously released.
  This is what gets me about the Apple model (I'm an iPad Mini user -- non-retina) -- the walled garden does an awful lot to preserve the security of the device, but they then brick us old users up in a tiny corner when us and the devices we bought are of no interest to them. If they want to rent us iPads, rent us them. Don't sell them to us then make them useless when the hardware is still working perfectly well.
  
  Obligatory Transformers clip
  ---PCJ
5. Re:Aren't 32-bit devices off support anyway...? by Half-pint+HAL · 2017-02-01 12:32 · Score: 1
  
  It's more about users with modern devices that are still using 32-bit apps that haven't been updated in ages.
  Yes, I'm thinking the summary writer may have misunderstood.
  
  Apple has tended to offer software support for their older devices for years longer than Google/Microsoft/RIM/etc have. While you could definitely argue that they're still not doing enough in that regard, they're already doing far more than any of the other smartphone manufacturers are.
  Accepted. However, the difference is that when Google walks away from support, you can still produce and procure new software for the device, if there's demand. When Apple walks away, you're left locked in an empty garden.
  
  --
  Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Arch Linux Did It First by Grady+Martin · 2017-02-01 04:56 · Score: 1

One week ago: https://www.archlinux.org/news/phasing-out-i686-support/
Classic games and apps have been killed by edxwelch · 2017-02-01 05:25 · Score: 1

What's really happened here is that Apple has killed all old classic games and apps.
A similiar thing happened when Microsoft released Windows 7. A lot of old games (like the origonal Xcom) didn't work on the new OS. However, because Windows is more or less open system, the comunity was able to get them working using DosBox.
But iOS unfortunately is a closed system. All those classic games are dead forever.
1. Re:Classic games and apps have been killed by RandyHill · 2017-02-01 07:39 · Score: 1
  
  Nope, you will still be able to download them and play them on iOS 10 and previous. Apple has not said they'd be removed from the store.
  And developers have this thing called Xcode, if they click the "compile" button it spits out a 64 bit version of their classic games they can put on the store.
  And windows isn't an open system. it's bloatware because it supports terribly dated old apps that require hacks to run. IT's so bloated the first Surface couldn't offer 16 gigs as entry level system because the OS required all of it.
2. Re:Classic games and apps have been killed by edxwelch · 2017-02-01 08:34 · Score: 1
  
  > play them on iOS 10 and previous
  You're being a bit disengenuous. If you buy a new device it comes with the latest iOS with no option to downgrade. Also iOS warns you every day that you have to upgrade. Plus the fact that other apps only support the latest version. Not upgrading is not really an option.
Abandoned Apps by Sherman+Peabody · 2017-02-01 06:08 · Score: 2

One of my main apps has been abandoned by the developer, mostly because they now sell it as a yearly subscription. They will never update my pre-subscription full functionality app. Am I supposed to delete that? Why should I when I purchased a fully functional app in good faith?
1. Re:Abandoned Apps by Neuroelectronic · 2017-02-01 06:18 · Score: 2
  
  Apple has always and relentlessly enforced their right to not only remove your access to "Apps" but to delete them from your phone remotely.
64 bit for mobile apps? by Neuroelectronic · 2017-02-01 06:20 · Score: 1

What is the conceivable benefit to having apps that can address 2TB of ram? Do any apps use more then a gigabyte that aren't leaking XML all over the place?
Loses good old apps on new devices by FlaSheridn · 2017-02-05 05:13 · Score: 1

The real tragedy in TFA for owners of current devices ("Your ability to run that 32-bit app is coming to an end.") would be that you could no longer run the last good version (if it's 32-bit) of apps that have gotten worse, e.g., AppBox Pro 1.8.4, Facebook 6.9.1, Foursquare 7.0.7, GoodReader 3.21.7, iStanford 5.9.1, Pulse News 2.9.4.