"good luck unlocking your car with abandonware lol" https://twitter.com/SwiftOnSecurity/status/91013013057141964...
Sure, this is Ford's fault in this case, but it means that anything which has a tie-in iOS app needs to either budget for or bill for ongoing updates to make sure it keeps working.
Apple has reversed several business decisions. Error 53, in app purchase gouging through developer fees, allowing apps instead of web apps (after realizing the iphone was pretty useless without apps), allowing bitcoin apps, etc etc.
>I find it hilarious that every time Apple does anything like this, people complain and Apple still sets record sales.
I hope you are not so naive to think that buying a product implies people like every single feature/change. Also, I don't quite see the hilariousness in a company ignoring valid complaints.
For what it's worth, people who worked on the original iPhone have said that internally Apple knew that 'web apps' were always a stopgap until they could get a native SDK out the door. Time constraints preventing them from shipping one in the first year.
I'm sure Don Melton and/or Nitin Ganatra discussed this on Debug podcast a few years back https://www.imore.com/60-melton-ganatra-episode-iii-shipping...
[0] https://www.apple.com/hotnews/thoughts-on-flash/ (April 2010)
[1] https://www.wired.com/2010/09/apple-lifts-app-store-flash-ba... (September 2010)
Quite the contrary it is this behaviour which has saved Apple. It made sure they could move forward with new technology quickly.
MS moves slowely because they accumulate so much cruft pulling them down. That is the flip side of always being backwards compatible and "nice" to the customers.
Rosetta, Carbon and the Mac 68k Emulator are examples of the exact opposite.
Apple does not hesitate moving forwards, but historically they provided large amounts of backwards compatibility, just not as cruft inside the existing system.
How is that not similar? I can't still run Rosetta to this date...
4 years.
> How is that not similar? I can't still run Rosetta to this date...
iOS 11 removed 32b support to hardware which supports it, Rosetta added PPC support to hardware which did not.
Something similar to Rosetta would be emulating Aarch32 after having removed hardware support for it, not removing software support for Aarch32 despite the hardware implementing it.
Apple's cadence of releasing Mac OS upgrades was a lot slower back then. x86 Macs were introduced with 10.4. Two releases later (10.7) they dropped support for PPC apps and 32 bit Macs.
Sure it was.
In Portugal during the 90's, there were lots of CS students applying to work there.
Apple not so much, specially since they were about to close, and except for the Interlog shops in Lisbon, it was almost impossible to get an affordable device in a country where the average salary was about 400 euros on today's money.
Are we thinking of the same MS?
The latest processor doesn't support 32 bit code. All 64 bit phones can support the latest OS. Why should Apple waste time, resources, and space on the device to support 32 bit code?
Really sucks to lose 32bit support for legacy apps that used to work, especially when it might be a companion app for hardware/equipment that cost much more than the iPhone X (like your car).
I have some 32 bit apps that already don't work with newer versions of iOS.
Apple is a hardware company, and its need reason to push it. But what I do with hardware is run applications, and the applications matter more to me than the shiny (or not) box they run on, insofar as the box has the hardware to provide the UX that makes the software usable.
I am not talking in abstract; when Everyday Looper goes, iOS will lose about half its value to me.
(See https://www.youtube.com/watch?v=CzQLRPwZjIo for usage example).
Seeing that Apple is the most valuable company in the world and they have a long history of abandoning legacy software (Apple //e, 68K, PPC, and soon 32 bit x86) and moving customers with them, that statement doesn't jibe with the reality on the ground.
What are the chances that people won't upgrade their iOS devices because they want to run an abandoned 32 bit app?
But iOS being such a locked down and closed platform means there is currently no way to preserve legacy apps or the data stored within installations. This is why dropping 32bit legacy app support is such a big deal.
That said, to your point I'm sure most people who have been on iOS for a while have that one app that seems to be abandoned that they love, myself included. I'm glad 32b is going away as it really does clean up the App Store and gains some efficiency, but I'm annoyed the developer has given up on the app I like.
Don't they, though? I've seen a few people assert that, but no hard facts yet.
> Why should Apple waste time, resources, and space on the device to support 32 bit code?
Because users paid good money for 32b applications and phones which could run them at the time, and this is going to hold back users updating on iOS.
Rosetta was bundled with OSX for 4 years. That's for PPC mac software running on hardware which literally could not run it natively.
> my 68K Mac software
The Mac 68k emulator was only deprecated with the Intel transition, 68K mac software remained supported for about a decade.
> How far back should Apple go supporting older platforms?
Supporting software which runs natively on the hardware doesn't seem exactly reaching.
Apple was able to reduce the size of iOS by not having 32 bit support libraries in memory. Since iOS doesn't have paging, that saved memory benefits 64 bit apps.
Which is not my issue, have you considered reading my comments? Here, let me make it easy for you:
> the problem is that you can't play phone games from 2009 on your 2013~2016 iPhone which had been able to run them right until you updated iOS.
> Apple was able to reduce the size of iOS by not having 32 bit support libraries in memory.
Is that why capacity available went down 730MB on a 7?
> Since iOS doesn't have paging, that saved memory benefits 64 bit apps.
You could already save that memory by not using 32b software. Don't use the software, the libraries don't get loaded. Furthermore given iOS will kill background applications to reclaim memory, the "saved memory" is just about non-existant.
There is always a performance hit going from 32 bit to 64 bit processes. There is a hit to performance when running both 64 bit and 32 bit processes on Windows. Why take the hit to support some old 32 bit apps that probably haven't been updated to take advantage of even the 4" inch phones let alone the larger phones? Why take on the support and security concerns for a few old apps - many of which already don't work on iOS 10?
I guess knowing my RAM is unused helps me feel better while I'm wondering which files I've lost to the forever locked away 32bit app containers.
The developers of the apps clearly don’t think of them as essential.
I was going to play it for a little while before I updated to iOS 11. To my surprise, Epic decided to update it for the first time in 5 years and port it to 64 bit code. It couldn't be because it was still making much money, but I did appreciate it.
EDIT:
It was also updated to support the iPad Pro.
https://itunes.apple.com/us/app/infinity-blade/id387428400?m...
Or, like the vast, vast majority of games, the developer was contracted for the initial development and the publisher who owns the right to the IP and specific software has no financial incentives to pay for additional work to update it and thus won't, regardless of the developer's wishes or whims let alone the users's
Due to these updates I don't know that they would still run on Windows XP but it's nice that the code hasn't needed to change.
To run 32 bit stuff you need copies of all the system libraries. You lose a lot of RAM to that. You have to continue to ensure they don’t have bugs. All for apps that are abandoned.
I totally understand what apple is doing. I bet you a ton of those apps were never updated for iPhone 6 screen shizes either.
How far back should Apple go with backwards compatibility?
Do you also think that modern Macs should support 65C02 from the Apple II days? 68K Mac programs? PPC Mac programs?
Apple dropped 32 bit processor support in 2011. They will probably drop 32 app support in the next two years.
It's a longstanding practice at Apple. At some point hardware & software are old enough that not only are they not supported, they're pointedly ignored when some appropriate new development "breaks" them.
Other platforms garner some favor by supporting ancient software, but I've long seen the subtly crippling consequences of preserving such backwards compatibility.
But in any case Macs and iDevices are different; Macs tend to stay backwards-compatible for quite a while longer. 32-bit apps still work fine and will as long as Macs are on Intel processors. Even Carbon[1] apps still work (compiled as x86 binaries) on the latest MacOS, and those will also run (compiled as PPC binaries) on MacOS 8.1, from 1998.
CPAN is used by the perl community to make lists of modules broken by new perl releases. They use this to find how intrusive proposed intentional changes are, as well as to find accidental breakage.
* 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.
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.
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.
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.
The simple solution is for developers to recompile the apps. The developers of any apps that are truly still needed by customers, can easily convince those customers to pay for the update.
Also, they could just continue to pop up an alert saying "this app may slow down your phone" like they already did in iOS10.
Also, I doubt there is much of a performance hit anyways. For example, the current facebook app is 64bit and it is a slouch to start.
I had to keep giving Apple £100/year just to let people keep downloading the game for free. At some point I tried recompiling it for a newer iOS, and I get hundreds of message about depricated APIs that I had to change to get it accepted by Apple. Instead I let it drop.
I can't even put a copy online for people to download, the game is just dead and gone thanks to Apple. I can still run Windows games from 20 year ago and with DOSbox, DOS games from 30 years ago. My own iOS game on the other hand is dead, never to be revived.
On the other hand, thanks to this kind of "burning bridges" users are not tied to 20 year old compatibility kludges and legacy BS in the OS and libs.
>My own iOS game on the other hand is dead, never to be revived.
Which, App Store or not is the fate of tons of games -- most 8bit/16bit era games we have, we just have thanks to emulators.
I play board games and there are games nowadays that require an app to play (see for example Alchemists). I've argued that this is a bad idea since at some point the apps will probably stop working as we see happening in iOS 11. But people always argue back that someone will be sure to create a version of the app to keep it going. I may be a cynic, but I think that is incredibly naive to believe that will happen.
Sure you can.
Put the source code up on Github and anyone can download and sideload it on their device. Don't even need a developer account to do that these days.
>At some point I tried recompiling it for a newer iOS, and I get hundreds of message about depricated APIs that I had to change to get it accepted by Apple.
Games are generally funded by a publisher who retains all rights to the game, the developer is contracted for some time, then goes on to work on something else. A publisher is not going to pay for the update of a paid-upfront game from 5+ years ago, there's no ROI in that. Without a continuous revenue stream, publishers don't keep updating games.
Furthermore, both publisher and original developer can fold, leaving the game orphaned.
- apps which were abandoned
- apps which were replaced by a successor. In the absence of update fees, this is the easiest way to generate new revenue for continuous updates. I am happy to pay for app maintenance, but this scheme means, that there is no automatic data migration from the old to the new apps.
Hello, Omnigraffle. I bought this on iPad, used this something like, three times before having a need to use it over a year later and "Sorry! There is a new version to buy and your version is no longer supported, or runs!". It wasn't cheap, as apps go.
Never, ever buying anything from Omni, ever again.
Edit: To add details, I bought this for £35 on iOS 7. When iOS 8 came around, it was discontinued, left to crash on open, and you had the "opportunity" to buy version 2 all over again.
It's one of the most polished apps around. You don't owe the Developer's time indefinitely from one $5 purchase, and you're free to move to an alternative. I'm happy to continue to support the apps I love -- they generally aren't asking a whole lot.
Additionally, in the case of Twitter clients, they also can't add a lot of new customers b/c Twitter has capped their allowed clients. If they didn't charge customers again, they wouldn't be able to sustain the work with new ones.
Which part of the guidelines, specifically?
Devil's advocate: you don't have to install iOS 11 on your four-year-old iPhone.
That is in fact my plan, but is nonetheless frustrating.
I can still download older versions of apps on my first gen iPad that hasn't been supported by iOS since 9/2012.
It's actually one of the main things that keeps me in the iPhone ecosystem.
The newest version of iTunes still supports the first generation iPod as far as I know. I know it still supports the first generation iPod Touch.
Were apps previously installed as fat binaries with 64 and 32-bit architectures included, and the 32-bit chunk has now been removed?
Or was that already taken care of with the "app thinning" stuff a couple of years ago?
It should have been. And the update only removes 32b applications, not 32/64, if they were not doing so before I doubt they're going to thin fat binaries now.
It's not the free storage space that is a big deal, it's the freed memory from not having to keep 32 bit and 64 bit dll's in memory.
* iPhone which had been able to run them right until you updated iOS.*
Every OS update whether they had deprecated 32bit apps or not breaks abandoned apps. Apple also removed support from the Mac years ago for PPC apps that could run on x86 apps up to 10.6.
The developer however wasn't able to renew the license, so he can't make a new version even if he would like to do it.
Or is it some kind of API incompatibility?
The problem is not that you can't play phone games from 2009 on your 2017 iPhone, tying 32b deprecation to a hardware revision would actually have been nice (regardless of the hardware still being able to run in 32b mode).
But that's not what's happening, the problem is that you can't play phone games from 2009 on your 2013~2016 iPhone which had been able to run them right until you updated iOS.
> users (who get some free space back in iOS 11)
"Free space" which they could already have gained back by removing the applications in the first place.