Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple is providing mostly stable platform APIs, but they never shy from removing old crap. That's why both iOS and macOS are lighter than many other OSes (see Windows for example of OS where backwards compatibility is taken to the extreme).


32-bit apps require 32-bit system libraries - and the downsides are:
  • iOS has to include both 32 and 64 bit system libraries, increasing its size requirements
  • when 32-bit app is running both 32 and 64 libraries will be in memory, leaving less memory to the rest of the OS / app and increasing battery load
  • when first 32-bit app is launched the device will temporarily slow down due to iOS loading 32-bit libraries for the first time (and again, using extra battery)

Except that Swift apps include their own copy of libraries (about 20MB or so) and loading these would probably cause more batteries as well. I wonder why Apple doesn't include that warning as well (Warning: loading a Swift app may consume more battery.... ;-)
 
Except it also means that app developers are effectively prohibited from making or updating apps for the iPhone 5, iPhone 5C, and any iPad older than the Air. I can't really say how many of those devices are still being used, but I didn't switch off my 5C all that long ago, and it's not like it was performing badly or anything. Those are all otherwise perfectly capable devices being forced into obsolescence through software policies.
Your app can still be both 32- and 64-bit compatible.
 
  • Like
Reactions: firewood
I wonder when Apple will get off their ass and start forcing developers to submit apps that support the iPhone 6/7 resolutions.

It's been 2+ years, and still there are apps that are being regularly updated are still using the scaling feature...

When the iPhone 4 retina came out, pretty much all apps updated within several months. Same when the iPhone 5 came out with the taller aspect ratio. Why are some devs slacking with this? It makes the apps look like crap, especially on the Plus phones, and you don't gain any extra screen real estate from the higher resolutions.
 
  • Like
Reactions: jessejarvi
Even Apple hasn't bothered to update all their apps to support the newer resolutions yet - granted Field Test isn't the most important, but it's still a rough edge.
Field Test isn’t something that should be accessible for end users. Some other secret applications haven’t been updated either, but that shouldn’t be a problem because they’re hidden for a reason.
 
Oh my good, what is this? A normal customer would think: who is the app developer? compatibility, for what? The customer doesn't mind this things. Apple should contact the developers one by one directly and this process must be transparent for the user. I can't believe things like these coming from Apple.
 
i find it unprofessional and arrogant to shame it onto "the developer of the app" and there's not so much the final user can do about this message. but if they think that's necessary, then let it be.
 
They have no problem breaking apps here and there, but they don't have the courage yet to do it outright for large classes of popular apps.

Er... Are you talking about the same Apple who didn't mind to kick out Flash, or its own Aperture and classic Final Cut Pro? Heck, ever heard of what they did to the 3.5 audio jack?

Apple not kicking out the old? You must be new here.
 
  • Like
Reactions: jessejarvi
Apple is providing mostly stable platform APIs, but they never shy from removing old crap. That's why both iOS and macOS are lighter than many other OSes (see Windows for example of OS where backwards compatibility is taken to the extreme).


32-bit apps require 32-bit system libraries - and the downsides are:
  • iOS has to include both 32 and 64 bit system libraries, increasing its size requirements
  • when 32-bit app is running both 32 and 64 libraries will be in memory, leaving less memory to the rest of the OS / app and increasing battery load
  • when first 32-bit app is launched the device will temporarily slow down due to iOS loading 32-bit libraries for the first time (and again, using extra battery)

Exactly! It took 43 comments until someone answered that question correctly...
 
  • Like
Reactions: pcmacgamer
Just got this notice today, and of all apps, Appshopper.
Isn't that a MacRumors app?

dont buy.jpg
 
  • Like
Reactions: dotnet
Lots of great apps that have been abandoned. This is a way to require developers to update.

Or force you to buy an expensive upgrade. Exactly what one of my most frequently used app's developer is doing. He's gone to an expensive subscription model and abandoned the 32 bit predecessor, with no real enhancement to the new app requiring the subscription.

Probably going to end up in a lawsuit.
 
The transistors needed to run 32-bit ARM code are possibly not even powered up when running arm64 code, as the instruction sets (ISAs) are almost completely different. Whereas for 32-bit apps, both instruction sets are needed (since the iOS kernel itself is 64-bit code), so both sets of instruction set decoders (etc.) are needed.

Plus, the 32-bit code usually runs slower than 64 bit ARM code (see the benchmarked difference reported when the iPhone 5s first came out).

This results in a double hardware power and performance penalty, in addition to the memory penalty of having to load extra 32-bit frameworks.
 
[MOD NOTE]
A number of posts were removed due to arguing and bickering.
 
Or force you to buy an expensive upgrade. Exactly what one of my most frequently used app's developer is doing. He's gone to an expensive subscription model and abandoned the 32 bit predecessor, with no real enhancement to the new app requiring the subscription.

Probably going to end up in a lawsuit.

I doubt many people will buy it if it's not worth it. Although if it's a really useful app, you can't expect it to be free either. I've given up on lots of of freemium apps/games. Evernote and Amazon Prime have lost me.
 
This one was $29.99 at the beginning and required buying a sister Mac app for data syncing at $49.99. The dev required upgrade fees in the same range when new iOS's were released, and then went to a $29.99 subscription fee when iOS 9 dropped. Mutiny raged at that point.

The old apps still work, just no upgrades. He'll use this to kill the old apps and force upgrades. I don't do it, but it is a small market pro app that will be a nightmare to transfer data to a different platform.

Oh well.
 
32 bit apps run just fine on my iOS 8 iPhone 6, if it's slowing down using iOS 10 then the problem is with Apple's iOS developers.
First they throw 32 bit bios computers under the bus now this. What's next? All iPhone 4&5 go dark after 2017?
[doublepost=1475798612][/doublepost]It seems like Apple's code has been getting slower and slower even on new devices.
I helped my friend upgrade from OS X Snow Leopard to El Capitan and after a week he restored it back to Snow Leopard saying it was so slow and 10.6 was much snappier.

Planned obsolescence. I see my Mini 1 being incompatible with most apps sooner than I'd expect.

This is probably the intended chain of events. Old but perfectly nicely working hardware will be made useless because the only place where you can get software for it is controlled by a company that wants to make more money from hardware sales. The brand loyalty among Apple users are so strong they cheer when the master whips them!

You all should read this:


Apple is providing mostly stable platform APIs, but they never shy from removing old crap. That's why both iOS and macOS are lighter than many other OSes (see Windows for example of OS where backwards compatibility is taken to the extreme).


32-bit apps require 32-bit system libraries - and the downsides are:
  • iOS has to include both 32 and 64 bit system libraries, increasing its size requirements
  • when 32-bit app is running both 32 and 64 libraries will be in memory, leaving less memory to the rest of the OS / app and increasing battery load
  • when first 32-bit app is launched the device will temporarily slow down due to iOS loading 32-bit libraries for the first time (and again, using extra battery)

That said, everything is planned obsolescence if you want it to be.
 
  • Like
Reactions: JosephAW
Another reason, I never upgrade my iOS! All my device are running at the same speed as I first purchase my Apple devices! May not be as fast as the latest Apple devices but I am very happy using them still!
 
  • Like
Reactions: JosephAW
The main advantage of 64-bit is being able to access more than 4 GB of memory and some math operations. The actual 64-bit binaries will be larger than their 32-bit counterparts and will use more memory and disk space than the 32-bit versions. They may actually also run slower than the 32-bit versions, but it depends.

So this message seems to be intended to install FUD in the user who doesn't understand 32-bit vs 64-bit
 
The main advantage of 64-bit is being able to access more than 4 GB of memory and some math operations. The actual 64-bit binaries will be larger than their 32-bit counterparts and will use more memory and disk space than the 32-bit versions. They may actually also run slower than the 32-bit versions, but it depends.

So this message seems to be intended to install FUD in the user who doesn't understand 32-bit vs 64-bit
There are also additional registries that can be used with 64-bit that can speed up things. Things are well into 64-bit transition so 32-bit being phased out and pushed out in a sense isn't all that surprising at this point.
 
The main advantage of 64-bit is being able to access more than 4 GB of memory and some math operations. The actual 64-bit binaries will be larger than their 32-bit counterparts and will use more memory and disk space than the 32-bit versions. They may actually also run slower than the 32-bit versions, but it depends.

So this message seems to be intended to install FUD in the user who doesn't understand 32-bit vs 64-bit

That's the theoretical benefits. The practical benefits have been listed more than once.

- not loading redundant libraries in limited memory space
- not shifting between 32 and 64 bit mode
- being able to utlilise extended registers

For someone so seemingly confident in their opinion it sure seems like you failed to take the basics into account
 
That's the theoretical benefits. The practical benefits have been listed more than once.

- not loading redundant libraries in limited memory space
- not shifting between 32 and 64 bit mode
- being able to utlilise extended registers

For someone so seemingly confident in their opinion it sure seems like you failed to take the basics into account

As far as I know, the iPhone has less than 4GB of RAM.

Perhaps I am wrong?
 
You all should read this:




That said, everything is planned obsolescence if you want it to be.

The way Apple solved the coexistence of 32 and 64 bit apps is not the ontologic essence of software engineering. The problem can be solved by other solutions. Actually most compilers/IDEs can generate 32 and 64 bit versions of anything, just as easy as checking a checkbox and clicking "build" or "rebuild all".

The constraint of not allowing to run 32-bit apps in 64-bit devices could be an option in the preferences pane, so it would be up to the user this decision. The current case reminds me when I had OSX Mavericks on my rMBP and I decided installing updates of Page/Numbers/etc. Since then I started getting annoying popups saying that my OSX version didn't supported iCloud Drive every time I opened these apps. It would be better keeping the old versions, but I couldn't easily downgrade them.

My point is: all these alerts could be enabled through an option in the preferences pane. This way the user could block 32-bit apps from running if he/she desired. It's different from "educating" the user showing annoying popups. Transpose this situtation to the macOS environment and it looks even more nonsense...
 
The way Apple solved the coexistence of 32 and 64 bit apps is not the ontologic essence of software engineering. The problem can be solved by other solutions. Actually most compilers/IDEs can generate 32 and 64 bit versions of anything, just as easy as checking a checkbox and clicking "build" or "rebuild all".

The constraint of not allowing to run 32-bit apps in 64-bit devices could be an option in the preferences pane, so it would be up to the user this decision. The current case reminds me when I had OSX Mavericks on my rMBP and I decided installing updates of Page/Numbers/etc. Since then I started getting annoying popups saying that my OSX version didn't supported iCloud Drive every time I opened these apps. It would be better keeping the old versions, but I couldn't easily downgrade them.

My point is: all these alerts could be enabled through an option in the preferences pane. This way the user could block 32-bit apps from running if he/she desired. It's different from "educating" the user showing annoying popups. Transpose this situtation to the macOS environment and it looks even more nonsense...

I can certainly see how an option to turn 32-bit support on and off would work. Maybe beginning with iOS 11, Apple can have something like a "legacy mode" toggle to enable 32-bit apps. The option wouldn't appear until a user downloads a 32-bit app. Most people wouldn't ever need to use it, but those that would likely have the capability to figure out where it is.

Although, I'm pretty sure Apple would sooner remove 32-bit support altogether.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.