This has happened to me also (indie game dev) a few years ago.
The number is about 20 or so games that have been removed by Apple because they hadn't been updated in two years. The worked perfectly fine on all the new hardware/software and even work today.
On top of that, I know that there is another 30 or so apps I was involved in with clients that have also been removed.
These weren't the biggest apps/games in the world, but they were all high quality finished products that had nothing wrong with them. Its just the cost of re-publishing each one out-weighed the return, so I didn't have much of a choice sadly. I do have plans to re-publish some of them, however they have to take a back seat for current work.
All that to say, I have a large part of my portfolio of work that is no longer available to the public, which just sucks.
A better strategy would be to allow app publishers to log in and indicate in some way that the app is still "good" and active. Now I have to make a "fake update" to a perfectly fine app because of this.
Of course the best strategy would be to just don't do this at all. I find it offensive that a single company can decide on a whim to erase my perfectly fine software from history, because it's "ancient" in their opinion (two years old).
This is more about making sure the app compiles with the latest SDK and whatever requirements that entails.
I still have a few crap apps on my phone that look zoomed in because the author never bothered to update them for HiDPI devices - that was half a decade ago.
I agree with interpol. There are always new info.plist privacy settings and the like that apps need to support. As I recall there were also some relatively recent TLS and https security requirements. Then there are things like dark mode support and... nevermind.
I'd turn the question around. Why wouldn't an Apple customer who buys a product expect it to be up to date, well-maintained, and reflect current best practices in security and privacy?
Saying that it's not convenient for the developer isn't a great answer to that question.
They do maintain compatibility, it's just obviously running in compatibility mode because of hardware changes.
If your app doesn't account for a notched display, or a retina screen, or multi-tasking or whatever, then there's nothing Apple can do aside from run it as it used to run on older hardware, without supporting the new features.
It feels like we are back in time before writing existed. I wonder if in 10,000 years from now archeologists will find any real cultural artifact from our time.
Eh, it’ll be hard to replay any iOS games in the future but most of them have screen recordings on YouTube which has been pretty good at keeping old stuff.
People joke that things on the internet last forever but I have witnessed so many things come and go and totally disappear that I doubt exist anywhere anymore. Its just a complete fallacy.
Not just youtube but soooo much content has come and gone. Its a total shame and travesty that so much wonderful content has been lost for so many different reasons.
Not unless society survives continuously because our artifacts are quite delicate. It's ironic that the clay tablets we found are probably the only things that will survive another few thousand years.
Eh, that's just survivorship bias at work. Of all the clay tablets that did survive, many many more were lost forever.
It isn't infeasible that some servers in a well-sited data center could survive. It'd take a lot of careful work to extract the data, but the potential wealth of information from a dump of, say, Wikipedia or any news archive would be massive compared to what previous lost societies left us.
Of course, it's equally possible all that survives is the logs of 4chan or Instagram or something equally embarrassing. What works future society think of us then?
You're right that many clay tablets were lost, so if we rely on an even more fragile medium than clay tablets even more will be lost – possibly even all of it.
Long-term digital storage is a somewhat tricky problem since all of our storage media lose their information over time if left lying about (usually on the order of decades) and require quite careful conditions for preservation. This is true in some sense for a lot of historical artefacts ranging from clay tablets to dinosaur bones to vellum, but getting useful information from half a clay tablet is still quite easy, whereas getting useful information from a broken digital media is a very hard – or even impossible – problem even today. In several thousand years your digital medium will need to be in a very good condition or its useless.
Turning a dump of wikipedia (the kind you get on dumps.wikimedia.org) into a running instance of wikipedia that you can browse is actually insanely hard. I put considerable effort into it a few years back and gave up. Don't know what the state of this is right now. So unless the servers that survive are the ones running wikipedia in production now, archaeologists will be out of luck.
But those won't survive, the simple reason being that the people running them now are making continuous changes to them now and there is no guarantee that those changes preserve whatever information future archaeologists will find of value (which we can't really know now).
And this is true for much simpler mediums than software as well. Take film for example. For film printed on celluloid, all you need is for a good copy of each reel of each film to survive and you've got pretty much a guarantee that this piece of culture will be preserved somehow. Nowadays films are digital thingamajigs rather than celluloid artefacts and the institutions tasked with looking after that digital cultural heritage go about it with an editorializing rather than archival mindset. (e.g. taxpayer-funded BBC removed an old episode of Fawlty Towers, itself a taxpayer-funded BBC production, from their streaming platform for being racist after the George Floyd incident [1]).
Besides: With virtualization and the various forms of infrastructure abstraction in combination with encryption-based security models, even a hypothetical scenario where all human life ceases to exist but all servers somehow survive on the bare metal layer would probably fail to preserve our digitual cultural artefacts.
Hard disks owned by private individuals with a "digital hoarder" mindset would probably make for a more useful archaeological find than servers.
> (e.g. taxpayer-funded BBC removed an old episode of Fawlty Towers, itself a taxpayer-funded BBC production, from their streaming platform for being racist after the George Floyd incident [1])
Just read up on that and am shaking my head in disbelief about the fragility of, well, everything really. Technology, emotions, interpretations, a general sense of having to pre-emptively react to anything and everything. Even at the time of creation, Basil Fawlty was a caricature of a deeply despicable man and other characters equally so. Best leave it to John Cleese himself to sum it up:
> Cleese spoke against the removal of the episode due to the Major's use of racial slurs: "The Major was an old fossil left over from decades before. We were not supporting his views, we were making fun of them. If they can't see that, if people are too stupid to see that, what can one say?"
This very much reminds one of the contemporary crusades against The Adventures of Huckleberry Finn. One of the characters, a run-away slave by the name of [pejorative] Jim, is actively railed against by much of society for being an imbecile, uneducated, and so on.
Yet throughout the story Huck runs into all sorts of people who are mostly acting like great people on the outside, yet invariably turn out to be horrible people on the inside (even including Huck himself). The one exception is Jim who actually ends up being a selfless and good person, inside out, from the start to the end.
The whole story is a reminder that what people pretend to be, and what they are - often have a rather strong disconnect. That many schools have successfully banned the book from the classroom because of the pejorative used, is perhaps one of the clearest reflections of the state of contemporary education. It'd be like if Germany had chosen to ban Schindler's List because the lead character is a Nazi.
Indeed. If you censor the past, you’re doomed to repeat it. I absolutely support mandating giving proper context, to aid understanding. That’s what school curriculums could be about. If you change the teaching of past events (or worse, the source material itself) according to contemporary tastes, consequently all of the past becomes largely meaningless and a tool to be wielded to further populist agendas.
> "Turning a dump of wikipedia (the kind you get on dumps.wikimedia.org) into a running instance of wikipedia that you can browse is actually insanely hard."
It takes 87 GB and a single click to create a local Wikipedia with pictures included. That software also has support for downloading data from a vast array of other sources as well.
You want to leave future archeologist something to do: "we could link these low-res jpegs to some high res webP even some SVG. It was a delicate task since we recovered it from an old Seagate Baracuda 2TB drive.
We even had to break some ancient pre quantum cryptography! We believe that we now have the whole collection of stylized ape pictures. Traded for their high ritual value among the Cult of Eneftee"
I'd imagine they would think we were human. Imagine we could access data from past times. Would you rather see decentralized unfiltered raw content from vast numbers of humans (who we will magically impart contemporary literacy rates to, so that such would even be possible), or the collected works from the House of Wisdom [1]?
How closely does Apple monitor for changes? Could you simply update the copyright text each year and push an "update" to remain on the store. I can't imagine they have people looking at each app for new levels or features.
Best case, check out your code, bump the version number, touch up your copyright date, hit "Run", do your testing¹, hit upload, have a sandwich, check it out in TestFlight, approve a release, maybe check a few boxes that say you aren't shipping super secret encryption technology to shunned nations.²
But usually after a few years Xcode will bitch at you about a lot of stuff, so maybe you raise the minimum OS version requirement, click "Fix it" on a lot of API respellings, find a couple that it can't automatically fix so you have to google that a bit. Then test and upload.
Maybe get in a fight with Xcode over your signing keys.
Sometimes something you were using gets deprecated and you have to use the newer replacement. That takes some coding.
It can get ugly if the 'owner' in the app store is not you or is an entity you no longer control. Then you have to get them involved to do the chain of trust signing.
If you produced it under contract, you may not be legally allowed to update it without a new contract.
␃
¹ do your testing is easy to say, but that could take an arbitrarily long time depending on how thorough you are. I expect this to be the dominant cost for most game updates.
² I pulled out one of my aging apps and just did all this to check, 10 minutes from "checkout" to "installed in TestFlight". The dreaded App Store review was 3 minutes. This isn't really a fair data point though, Xcode didn't suggest any source code changes so it was just bumping numbers and rebuilding.
There are many dependancies that require some kind of reimplementation, it's a pain.
I have made things easier (in the long run) with my last game. I wrote it all in c++ with all dependancies under my control. I was thinking >20 years ahead for that one.
Realised that was a bit snarky of a comment, I'm using a a modified version of Cocos2dx .v4.
It took way longer to create than if I was using Unity, but its a great solution for a small and performant end product. I was able to get Kanso down below 100MB and will run on a total potato. Something I highly doubt I could do in Unity without some serious effort.
Consistently not being able to run code that was just fine 2 years ago. Consistently having "quality assurance checks" that somehow always entail paying more rent to Apple.
Mostly time and hassle I would imagine. Apples requirements also shifted in the meantime so you might also be forced to provide more info/pictures/etc. which again comes down to time and hassle.
Yeah, spread that over 20 games/apps. It can really mount up, I can think of other indie game dev's that only publish on iOS that their games are now forever lost.
You mean the one that could barely run on 1Ghz phones with 1GB of RAM that the company behind it said they could have gotten it to run on a 128MB RAM first gen iPhone with a 400Mhz processor if Apple had allowed them?
I'd like to see how a web app of similar complexity would run on the same hardware. For all that people remember Flash being slow, remember the era of hardware it was running on.
By the time the iPhone was introduced, PC hardware was well into the GHz era with multiple GBs of RAM. The phone was much more constrained and didn’t have disk swapping.
In that case why were the minimum requirements for Flash for Android when it did come out in 2010 and 1GB of RAM and a 1Ghz processor and then it barely ran, ate up battery life, and was soon discontinued?
The first iPhone that came out with those spec’s was in 2011.
So doesn’t that kind of tell you the answer to how Adobe was full of it when they complained that they could have ported Flash to the 1st gen iPhone if it weren’t for Apple blocking them? The fact that they couldn’t get it working well on phone hardware four years newer, over twice as fast, with 4 times as much memory with larger batteries?
Cross platform frameworks like the initial poster alluded to always suck compared to native purpose built frameworks.
We see that today with Electron - a battery killing, memory inefficient, platform.
Flash on the Wii, as I recall, worked well mostly for flash games that were designed with the Wii in mind, and for very simple interstitials. Anything more complex did not work well.
I think Adobe could have done something similar on the iPhone. I don't know that it would have been what people wanted, and I think it would have exposed some of the iPhone's hardware limitations to users.
Mostly though, I think Flash was a heck of a lot better than what we have today with overly-complicated webapps and Electron, as you referenced. That's the point I was trying to make—we've ended up with something even less efficient than Flash ever was!
If games were designed to target a specific platform, doesn’t that lose some of the benefit of a cross platform runtime?
Of course the iPhone hardware had limitations at the time. The iPhone OS was very optimized around its known limitations and it aggressively killed apps from running that drained battery life or used too much memory (and it still does).
Native iOS apps are very efficient. Now the thought of running apps in a Java virtual machine on a phone in 2008 like Android did wasn’t a great idea. The best thing that Apple did was help rid the world of Flash.
Every time macOS/Xcode/iOS updates, some of the iOS APIs are deprecated in favor of "the new better way of doing things". You have to keep up, or else your old apps stop compiling at some point.
At the very minimum, it’s the developer fee, then it’s time and manpower to do all the certificate and notarization dances du jour that Apple keeps changing every year, because it’s more humiliating that way.
And then you go through review and they may reject your app because you get an inept reviewer who has a bad day.
Total remakes from basically scratch.
I've settled on rolling with c++ with no(minimal) external dependancies as the best solution...still using Unity for some projects, its just so fast to get stuff done!
Similar to the author of the tweet, Apple removed a working version of my FlickType Keyboard that catered specifically to the visually impaired community, just because I hadn't updated it in 2 years.
Can you just add a Marshawn Lynch-style "I'm just here so I don't get fined" line of text to the app's "about" page and call it a day? Or are you gonna have to make major changes to update to the latest versions of iOS?
Having to use the latest Xcode to build and submit the app is often already a big enough headache, due to how many things Apple changes between versions.
Another example from someone else:
"That literally happened to us. Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build."
so the existing build doesn't support iphone X? Isn't this a good reason for apple to push your app out because they want all their apps to support their latest phones?
This is of Apple madness has been my life for 6mo now. I've become the "deal with Xcode BS" guy for our cross-platform React Native app. It doesn't bother me but Apple really does create a lot of unnecessary pain.
I remember this sort of madness constantly. At that time, the Unity to iOS build process involved exporting projects to Xcode including C OpenGL code, which I would sometimes have to fix as it their compatibility would drift.
Even currently I don’t allow Visual Studio Mac to update after I learned the hard way that the new version needs new Xcode, which needs new macOS which isn’t even available on my computer.
(I only recovered a working setup using Time Machine.)
> "That literally happened to us. Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build."
* Apple requires you add support to new devices to push a new build. (this is the principal policy decision).
* This new support requires you build with new tools (Xcode 9)
* New tools require newer MacOS.
* Newer MacOS doesn't compile old Unity3D code.
* New Unity doesn't work with their codebase.
#1 is a policy decision, and solely Apple's choice. #2, #3 are (reasonable) technical pain owned by Apple's ecosystem. #4 is an annoyance that's mostly Apple's fault but is shared somewhat by Unity. #5 is "Unity's fault" for imperfect backward compatibility.
1: Native appearance on new devices is solely to prevent them from looking bad on a user's new device. Presumably the user would rather have their apps work, but Apple wants the appearance.
2: Apple only ships new SDKs with new Xcodes and new Xcodes can't run old SDKs. This is strictly a technical policy to limit Apple's development effort. People have been able to extract old SDKs from old Xcodes to run in the new version but that's become harder and harder over the years.
3. Another technical policy, this time with many parts. Apple starts a new Xcode version's life supporting the current and future macOS versions, but then removes support for what is then the previous version at some point. This lets them remove compatibility code but cuts OS support in the middle of a major version cycle. Additionally, Apple seems to be dropping arbitrary hardware support in macOS over the last few years, so many developers can't upgrade to the latest OS at all.
You echo the way I distinguished things: #2 and #3 are limitations on what Apple chooses to support (for somewhat reasonable technical reasons). I suppose you could call them "technical policy". #1 is a deliberate marketing choice to leverage the App Store to make developers improve support for new devices.
When Apple launches a new phone, they manage to keep “old” apps compatible with the new hardware/OS. After that, developers are no longer allowed to upload such apps, even though they would work perfectly fine. It would not be a big harm for apple or end users if developers were allowed to lag behind for a year or two.
I can't remember. Regardless, I don't see why they'd remove some apps (that still work fine!) and not others, eg the Pocket God example I gave above which hasn't been updated in 7 years.
Also, "unlisting" such apps would be better than removing them entirely, particularly since we have no alternative way of distribution.
I have a working theory that if Pocket God was uploaded with Bitcode, then Apple can recompile/relink it automatically for each year’s platform updates; and for projects not uploaded with Bitcode, the harsher standard is being applied to get that recompilation.
I paid $15 for the iOS version of Binding of Isaac and it disappeared from my library with no refund. Apple definitely completely removes things sometimes.
I am having trouble summoning the outrage I see in the other comment threads here. The App Store is stuffed full of abandonware. Apple should be more aggressive with this, not less. If you can't recompile your app and patch up support for recent OSes and recent devices on an ongoing basis, then your business model is not sustainable. I know, I used to sell iOS apps.
The market right now is absolutely flooded with indie games, some light pruning is probably for the best.
If you say something like “apps that are recently updated and using all of the latest APIs should be ranked higher within Apple’s search algorithm and recommendations”, that would make quite a bit of sense to me as an incentive to keep development and progress moving forward with all of the updated tech.
But it makes no sense to force devs to expend the effort to recompile and update an App just for the sake of staying on a store if everything is already working perfectly as intended with no security issues. This is especially a crap deal for small developers without endless resources to continuously be working on rebuilding and retooling projects just for the sake of Apple’s inability to do search and discovery well.
A lot of the comments here are focusing on indie developers, but honestly the worst offenders are huge companies that aren't focused on software, like HVAC, IoT, automotive. They'll hire out a subcontractor once to throw an app over the fence and let it rot. There's no market pressure up front when you are buying a washing machine to evaluate the support model for the companion apps, so this isn't a problem that solves itself. Apple has now forced these companies to maintain their stuff, and the market will be better off for it.
And then you have the other side, where the company doesn't upgrade the app (either cost savings or the company went under) and now you have an expensive brick because the app is suddenly gone from the store.
Oh, but they’ll allow you to keep already installed apps, so the only thing you need to do when you get a new phone is figure out which of your 100 apps have been unpublished in the meantime.
And then, I dunno, decide you are not going to upgrade because you don’t want devices in your house to be expensive bricks.
Not necessarily. I bought a very expensive cat toy robot that had a companion app. The company that made it didn’t just hide the app, they delisted it entirely. When I upgraded to a new phone, the download links were dead. It started me down a journey of coding my own replacement and reverse engineering the device’s firmware and BLE protocols which was a fun and rewarding experience. But, the fact that this was even necessary really stunk.
You can actually reinstall unlisted apps on a new phone They're available in the past purchase section. Not to defend Apple (especially since it's so hidden that very few users find it) but at least there's that.
No kidding. I still kick myself for a few things I bought with these types of apps (they become unusable). Ugh, you really need to buy from major vendors. Ie, a dash cam with a partial app from 6 years ago never update, lots of bugs. IoT is horrible as well. HVAC I got luckyish so far by going with Samsung (app works OK in my view).
I somehow can't believe Apple cares that much about either group, regardless of who in some manufactured statistical methodology you feel is the "worst offender." This has more to do with control than anything else, because I am unable to imagine a better fitting explanation. May be the "why" isn't really what you were addressing with your comment, but if it was, this can't be a "why."
> But it makes no sense to force devs to expend the effort to recompile and update an App just for the sake of staying on a store if everything is already working perfectly as intended with no security issues.
Sure, but realistically how does Apple tell perfectly fine apps apart from apps that are abandoned and do have security issues?
Hand-auditing every app doesn't seem realistic. I doubt a good automated solution is either.
They could just take developers' word for it, but Apple has a responsibility to protect end users. If you tell a developer, "your answer to our next question determines whether we remove your app", then you can't count on them to answer honestly because you gave them an enormous incentive to lie.
> Sure, but realistically how does Apple tell perfectly fine apps apart from apps that are abandoned and do have security issues?
Not to mention, the more apps with an inch-thick layer of dust there are on the App Store, the more they become trapped in the same kind of backwards compatibility mire that Microsoft is now stuck in. They could just hide apps that don’t run on newer versions of iOS I suppose, but with the extremely high system upgrade rate of iOS users that’s practically the same as removing them from the store.
I don't know, how does Apple tell perfectly fine new apps, that don't even have a track record of satisfied users (with telemetry that Apple has), from new apps that don't work?
Compilers and other development tools link framework code, libraries, and runtimes into binaries. Security issues get discovered, development tools get updated, binaries don't, binaries lack security fixes.
Old binaries are also built against old versions of the SDK and as a result get left behind when the OS adds or changes interactions, and if new device sizes are introduced they have to run in a blurry scaled compatability mode.
> The market right now is absolutely flooded with indie games, some light pruning is probably for the best.
By arbitrarily removing perfectly working older games? This is why indie devs such as Vlambeer that used to make quality mobile games now avoid ios and android like the plague.
The result of this is mobile games require significantly more upkeep then games on PC or consoles, and as a result the only games that are profitable in the long run are those that exploit their users with f2p microtransactions.
The end result of this is the sea of uninspired exploitative trash that makes up the games market on ios and android.
Yes, this is exactly right. And it doesn't make sense for games that have no online component (like those made by Vlambeer) to need updating for security/privacy reasons. Apple consistently misses the mark on what makes a platform good for games and then makes empty promises about "getting serious about gaming".
>Ismail said that either Apple has to start designing for backward compatibility support on their end or that people are going to have to get used to the idea of games dying and disappearing.
Not sure why you're being downvoted because that is the expectation, and honestly, it's fine for people who are software developers and not users because it guarentees they'll always have jobs.
Games in particular usually don't use a lot of system UIs or other integrations (and so are less likely to break or visibly age), are often developed on a shoestring budget (so developers will have less time and resources to keep updating them over time), and have artistic value.
Kicking them off the only store on a closed platform is erasure of artistic history. It's doubly insulting when they still work perfectly without modification.
For comparison: I've never heard of a game getting kicked off of a console's store because of a "lack of updates". The stores themselves usually shut down eventually - which is its own problem - but at least there's a reasonable business argument for why the company can't be expected to offer that service indefinitely.
And do people not keep phones that long? iPhone 7 is 6 years old now and supports the latest OS, there are surely plenty of people still using it. We are talking about 2 year old apps here. An app that I could have purchased and ran on a brand new iPhone 11 Pro. As an app developer, Apple has not given any OS updates that warrant app removal over the past two years.
And, then, after a few years, emulators become available. I just realized all but one of the ps2 games in my closet (not counting Dance Dance Revolution, for lack of a controller pad) appear to run fine on my phone.
And the App Store still works on a 1st gen iPad from 2010 running iOS 5. As of a couple of years ago, I was able to restore my old one and re download the “last compatible version” of Netflix, Crackle and Plex.
There are plenty of old 32 but apps that are “unavailable” in the App Store that are still available to older devices. Apple explicitly said that the authors app would still be available to people who already owned it.
As a dev myself, I agree. You can’t really expect to just toss a binary over the wall and forget about the project for the next decade.
Software is an ongoing commitment and periodic recompiles and fixes should factor into architecture and planning. Some decisions early on can save you a lot of pain. For instance, building your app with stock UI widgets to the greatest extent possible and limiting custom widgets and third party stuff to a minimum goes a LONG way for making your apps weather new OS versions better. These days my UIKit apps only need a handful of minor changes when a new OS version is released, making them trivial to maintain.
Choosing Unity was a big part of the problem in this case because Unity is terrible about maintaining particular versions of their engines over time. Devs need to start dumping Unity over this, because it’s the only way that Unity is ever going to fix it.
> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade.
You can on Windows. Microsoft has shown us what a three decades of maintaining an OS to that standard will do to a platform and its software ecosystem. There are definitely pros and cons to taking that approach. These days, as a user I'd much rather have decent emulators of older platforms and operating systems, rather than rely on the current OS to be completely and forever backwards compatible. But that doesn't seem like a good solution for mobile platforms or their app stores.
Windows really is the exception and not the rule, though. In fact in the free and open world of Linux, backwards compatibility is even worse… a binary compiled a year ago has a good chance of no longer working. Stuff like Flatpak is improving that situation a bit, but it’s still nowhere as backwards compatible as Windows.
An amazing sentiment calling the operating system used the most across the entire world an exception rather than it being a standard. And I don't know how you envoke the problem (yes problem) of broken dependencies on linux and think it adds to your argument on why this is a good move by Apple.
Windows may be the most commonly used OS, but nevertheless it is just one OS among many and the others have worse backwards compatibility… most considerably so.
Linux has excellent backwards compatibility if you bundle your dependencies the same way you do on Windows. Most low-level interfaces - the kernel, libc, X, GL - pay close attention to backwards compatibility.
And Windows also shows you what happens when you have layers upon layers of compatibility hacks and the security nightmares it brings. One of the first major IIS security issues happened because of the eight different string types and conversions between them to work with the various APIs.
You could “hack” a Windows server running IIS just by encoding DOS commands in the URL bar.
> Also, by Apple eventually abandoning backwards compatibility, it was able to migrate Macs to different better processors four times.
68k -> PPC actually did not break backwards compatibility at all. They realized it they had to make it good for the transition to work, so they built emulation right into the OS. A well-behaved app made for a 1984 Mac will run unmodified on the last version of old Mac OS, and on Mac OS X up to 10.4 under the Classic environment, that's over 20 years of compatibility. Apple could have maintained this level of compatibility until today, but they choose not to.
This is definitely not true. The 68K emulator didn’t support any 68K apps that required a floating point unit, apps that were not “32 bit clean”, or apps that used self modifying code. Even the introduction of the MultiFinder broke many old 68K apps.
Apple couldn’t maintain 32 bit app support with newer processors without wasting die space.
> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade.
Auugghh! This is the wrongest thing I’ve read on HN since 2021 COVID threads. Sorry you get the distinction!
Software absolutely should keep working as it did the first day it was released. The binary is the same, no cosmic rays have flipped any bits, so why should it stop executing exactly the same, but for a deliberate choice made by the platform to break backwards compatibility?
This idea that software should have to get recompiled over and over with the latest SDK simply to keep doing the same thing is maybe the worst idea ever thought of in software: and Apple leads the charge.
Software doesn’t work in isolation. It’s like you’d expect to take a tape with binary recorded on it and then expect it to use it on Mars.
And Apple ecosystem is rapidly changing. OSes are changing every year. Phones get reiterated every year. 2 years of no updates mean 2 cycles behind. And Apple is very good with pushing updates on the users.
And to be technically correct - both software on the tape brought to Mars and removed games will work in the same hardware and running context exactly the same. But for Mars context made it not runnable anymore and for Apple we’re talking about taking it down from storefront (but all existing customers can still get it).
I’d recommend checking Emacs - Elisp is very stable and some code is working well for decades and yet with all the carefulness of the developers some thing breaks due to API changes.
Much of the time decisions to break backwards compatibility are made to remove roadblocks in the OS development process. Keeping old software for the platform running forever has a high cost, and so I think that OS vendors wanting to limit how far back that compatibility goes is entirely reasonable.
If the argument is that OS vendors should include virtualized old OS environments for compatibility with old binaries to make sure OS development remains unencumbered, I could get behind that, but in that situation App Store listings of seldom updated apps should include a highly visible indicator that it’s been many years since the last update and as such expectations of significant bug fixes and support should be tempered.
This is simply false. Some software is an ongoing commitment. Other software can just be done and never need to be updated. An indie game with no online component falls squarely in the latter bucket.
Worth noting that Unity now has a system of maintaining LTS versions of each of their major yearly releases. They’re doing a LOT of stuff wrong these days but at least they’ve improved on that front.
I want to give Apple the benefit of the doubt and assume they, some of the brightest minds in the world wouldn't have thought of it (and it's possible), but the fact they didn't and chose to do it by update implies they are intending to force people to use their new APIs for that reason for the most part.
"Some of the brightest minds in the world" also leave up obvious scams[1] until the media reports on them. Perhaps competent App Store curation is just not a priority.
What is "abandonware"? Software does not have an expiration date. If it runs, if it does everything it does originally, I don't see the point for "patching support" for the sake of it.
Of course these are deliberate (and awful) policies that Apple is entirely in control of. Software doesn’t rot: operating systems deliberately choose to break backwards compatibility and their vendors deliberately choose to simply deem old software as too old.
Apple removed hardware support for 32 bit apps on ARM. Should Apple have wasted the die space instead of using it for new features?
Have you read “The Old New Thing” Microsoft blog? There are all sort of special case hacks in Windows just to keep one version of one third party app running.
Should Apple also have kept shipping its 68K emulator from 1994 in its 2022 ARM Macs?
If they actually gave any indication of what exactly they think needs to be updated other than the age of the app I would tend to agree but if an app is considered complete and running fine on current devices then it’s not abandonware.
If people are still downloading and using an app, that should be reason enough to keep it. I would understand removing apps that virtually no one has downloaded, and also actually used, in the past two years. This may conceivably have even been the case here, but then Apple should communicate exactly that.
I haven't had this experience at all. I've never had trouble finding reputable sources of windows software online, nor have I used the Microsoft store.
That is different from whether an average user would find a random piece of software trustworthy. I also have used Windows for decades and know where to look and how to tell if something is trustworthy. App stores are about expanding willingness to download and try software far beyond people like you and me.
Older games have reviews from outside of the app store, friends recommendations and brand awareness. Freshness is important to one category of user, older brands another.
Why should I lose access to an app I’ve potentially paid for and enjoy just because someone else don’t have time to do a specific dance dictated by Apple?
iOS and Android usually have perfect backwards compatibility, so there's no technical reason to require a new build. The apps work perfectly fine on new devices automatically.
It sucks, but this is what happens when platform vendors don't want to play the Microsoft's card of backwards compatibility to keep old applications going.
Also a way to force adoption of new APIs, even if they are irrelevant for many applications.
I think you mean a small, not scary warning that occurs all of once, only the very first time you install an app. I install apps from fdroid on a regular basis, and there's just a prompt, with options to cancel or install (see [0] for a screenshot):
> Do you want to install an update to this existing application? Your existing data will not be lost.
Of course, you have to allow the third party app to initiate installs to begin with the very first time you try to install from that app, but that's not much worse, really (screenshots at [1]).
This seems pretty clear cut to me, and less scary than the disclaimers in open source software on Windows.
Now, if your app wants to modify system settings, access non-media files, etc...well, it's still not scary, really; for system settings changes, the OS will pop up a prompt similar to that for installing the app, while for accessibility and other permissions most apps will directly open the appropriate section of settings where all you have to do is approve the app. I think the warning on enabling a new keyboard is scarier, tbh.
They have it on the play store too, but if you actually go to telegram.org they give you the apk download front and center with a "More comfortable with installing apps
from the Google Play Store? Download Telegram from Google Play" link all the way at the bottom.
At this point, I see no other option other than lobbying your congressmembers to regulate SV companies finally. Now companies are enforcing the uptake of new APIs for no real purpose? Half of the churn is just to pad googler pedigree and advance within the company, it is a shame they are enforcing that culture on their users.
For google, it is mostly for fighting against random api abused usage in China apps. China apps can always find a new way to abuse apis that mean to enhance the user experience to tracking and data stealing.
So you want the government to come up with “good reasons”? Would a “good reason” be that Apple stopped supporting 32 bit hardware? An app didn’t support new display sizes? The notch?
I think it has to do with swift runtime deprecations.
I have an objective-c app that is as old as the AppStore and I haven't updated it for 8 years [1], Apple even updated it once themselves somehow to support iOS 11.
Another of my apps was removed with a similar vague explanation as the OP got and it was written using Swift [2].
While I understand that they might want to drop support for old runtimes the 30-day deadline is ridiculous. And if you miss it you need to re-submit the app and lose your ratings etc.
I made nowhere near enough in the ~2 year period my app was available to justify spending the effort to modernize the project so I just let them remove it...
I have binaries from early 90s (small utilities) that I wrote back then and still use today, and they do not need changed because they are truly done and bug-free. Thank Microsoft and IBM (PC) for backwards compatibility, it's a good thing I made the choice back then to stay away from Apple. Fuck forced obolescence and this idiotic notion that constant change is somehow necessary. It's only necessary to feed out-of-control corporate greed.
If Apple had its way with everything, we'd probably all have to buy new appliances and rewire/rebuild our houses every few years because nothing would be compatible with anything older. Do not want.
This is very bad news for indies, and will help large companies push them out.
I have games in AppStore not updated for many years. They work well on all devices, I also consider them to be a piece of art. And feedback is very positive!
Getting anxious that Apple will pull it.
Releasing a new version sounds easy, but it's a significant time effort (chain of dependencies, build environments and game engines are complex) with 0 value to anyone - because it is perfect and a piece of art.
Why don't they have better options for discovery, rather than saying "old is bad".
I have comments from people saying my game is their favorite childhood game and they have they have fond memories and stuff - and they are happy to play it now once in a while even.
Apple logic makes zero sense, it's like destroying books or paintings and stuff.
Calling something "art" doesn't magically make it immune to decay.
Paintings have to be restored, books have to be reprinted.
If your art is so cherished to you and other people then surely that should give you even more motivation to spend time ensuring that it is preserved into the future, no?
"Every record has been destroyed or falsified, every book rewritten, every picture has been repainted, every statue and street building has been renamed, every date has been altered. And the process is continuing day by day and minute by minute. History has stopped. Nothing exists except an endless present in which the Party is always right."
I, as my others, tried to explain that this is not small labor. Please read the many comments related to this post before making such a incorrect statement.
If majority of games won't be around in 10-20 years, then it's a pretty good analogy of the parent post.
> I, as my others, tried to explain that this is not small labor.
The phrase "small labor" has a legal meaning. This is not a colloquial attempt to describe the workload as small.
However, also, as an author of unity iOS software who's gone through this, I do think the amount of labor being described here is pretty over the top.
Even in an extreme case I would only expect dep upgrades to take a couple days.
I've read the many comments, thanks. It's just that I don't really agree with them.
As both a developer who's been through this, and as a user, like many other people in this comment thread, I agree with this policy. I believe that abandonware doesn't really belong in store. It makes it much harder for me to use my phone, that every time I want to do task X, I can't find an app for ten minutes because I'm digging through all the shovelware.
I also don't see any moral imperative to keep games available, frankly. To me it seems like insisting that every board game ever printed should still be on sale somewhere.
I think that if people feel the need to compare this to murder and political oppression, they're kind of ceding that if they describe it correctly, nobody's going to be angry.
In general, I treat invalid comparisons to war crimes as a warning sign, internally.
.
> If majority of games won't be around in 10-20 years, then it's a pretty good analogy of the parent post.
This has always been the case with computer games.
Try to dig up some 2600 or Colecovision games. I'll wait.
I don’t believe any game/app that was/is available on one or two of many hand held computing devices is worth much “labor” from the maintainers of said game’s/app’s operating environment. I think it’s kind of hilarious to think that ANY application written to be run on a mobile device is so important that it should run forever or even X amount of time without adhering to the constraints of the runtime environment. Humanity NEEDS access to my iOS 1.0 minesweeper because <misplaced _software_ideology>
The game could easily rely on functionality that is no longer available. It may now violate some new content guideline. Either would have the effect of silencing them.
The author will eventually die, and then their work will either be modified without their oversight or deleted from the archives.
As the quote says, the problem extends beyond just video games.
What no longer available functionality, specifically, should be in the store? That story does not make sense
What things against content guidelines should still be in store? That story does not make sense
Oh no, a store doesn't carry a video game for all eternity, past an author's death? Oh no. Since Apple is the country's archivist, the phone store should probably carry every single app ever written for all time. Screw the user experience, Apple's obligation is to the author of Lizard Pong
I have never seen a perfect app or a piece of art in the App Store.
Apple isn't running an art gallery, besides. If it's a piece of art, it belongs in MOMA.
I don't understand why everyone's saying "this store can't keep abandoned stuff out because they're capital-A Art."
You know how some guy makes a painting, and he thinks it's really good, so he takes it to a gallery, and they go "we're not interested," and he starts yelling about all the study he did, and it's Art, and how dare they?
They're running a business, dude, and almost everyone who says "I'm making art" isn't
Art is super rare.
I can only think of maybe half a dozen games in all of history that I personally believe have earned that title. Maybe two dozen films, and they've been around a lot longer.
Before you start arguing that everything little Billy makes with fingerpaint is culturally important art, ask yourself one question: where are all the legitimate art museums declaring games art? As far as I know, that list starts and stops with the 2012 Smithsonian exhibit where they let the population vote and then didn't hold anything physical at the building ever.
Have you ever considered that nobody goes to the Library of Congress, for anything? Have you ever considered that cramming the record with every insignificant thought ever thunk might actually be counterproductive?
Are we really so much worse off to be missing one romance poem from Lebanon in the Bronze Age?
Do you genuinely believe that archaeologists, a thousand years from now, will be studying Hotel Mario, Sonic Boom, or Ninjabread Man?
.
"Why don't they have better options for discovery, rather than saying "old is bad"."
They aren't saying "old is bad." They're saying "unmaintained is bad."
.
> Releasing a new version sounds easy, but it's a significant time effort (chain of dependencies, build environments and game engines are complex)
I dunno. One guy got Quake 2 up and running under the browser in Emscripten in three days.
I have a hard time understanding why everyone is acting like pressing the build button can be tragically difficult, but also, their software is perfect art. Being unable to build is a pretty big red flag
I know, I know, "old Unity." That's because it was left unmaintained for years, though.
I lost two apps this way. I think that was the right thing for Apple's users.
I think that Apple should be more focused on the users than the developers.
.
"Apple logic makes zero sense, it's like destroying books or paintings and stuff."
If a bookstore stops selling a book, do you believe the book is destroyed?
If I write a book and only release it on the Kindle, and then five years later Kindle requires PDF instead of ePub, and I don't want to put in the effort to convert, has Amazon somehow harmed me?
Is it relevant that you can un-destroy the game by just recompiling it and pushing a new build?
Is it relevant that you can release your game on other platforms?
I guess I feel like there's a whole lot of misrepresentation happening here.
They're not destroying anything. They're giving you 30 days' notice to show that you're still maintaining the app, and then it stays up.
I have had many apps (over 20) on the store, since 2012.
I haven't had any that has weathered the OS changes past a couple of major steps, without having to make some code changes (sometimes, nothing more than just recompiling with the latest toolchains).
I just put out an update to my very first app, which is ten years old, but I have done a few updates, since first releasing it.
I have another app that is about two years old, and it needs a facelift. I don't have the bandwidth to give it said facelift (It still works, but looks like crap). I hope it won't get pulled before I can give it its update. I won't blame Apple, if they do pull it, however (see "looks like crap," above).
I've generally retired most of my apps, when they got long in the tooth.
I understand being upset with Apple at this arbitrary cutoff. But can we also talk about why a recompile isn’t as simple as opening the old project and hitting “compile”? I work on a large project (millions of lines of code), which has been in continuous development for 20 years. Every new compiler or IDE release results in us having to dedicate at least one engineer full time for a few days to get our project compiling again with the new tools before the team can switch over. That’s a project that previously compiled with no errors or warnings (because we set warnings are errors to true) suddenly can’t build. It’s ridiculous! I can’t imagine throwing something like Unity in on top of that.
Someone replied to the original tweet with an example of their iOS dev experience:
Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build.
Systems improve over time. Apple's privacy in iOS improved a lot. Not updating your apps makes it hard to keep up with API changes. Its normal you have todo some work to ensure it still works. Sometimes you're out of luck. But not all dependencies stay with us forever. Software is sadly enough not immutable, environment impacts how software runs... My old android game stopped working on newer devices 3 years ago due to a OpenGL bug that was fixed, i depended on the bug in order to make my app work.
While I loathe apple's moves lately, including this one, I have to agree with this comments sentiment.
Software is not free once written. You need to expend resources to keep it up to date and secure.
If you aren't keeping things up to date, you are neglecting the maintenance of your application. You wouldn't be surprised if your car stopped working if you never change the oil. Apple is taking proactive actions here, presumably to protect the end user experience. Wether or not I agree with the manner of proactive action is a different issue. We know apple loves to exert tons of control over things like this.
Apple is difficult to work with. It takes maintenance to keep apps up to date. Yes, the two year thing seems a bit over the top but remember the real issue is that this guy can't submit a new build because he hasn't added support for the last two OS versions.
The app store is hard to work with, but they payoff is immense also.
Immense - 30% they take to give you more trouble and kick you out whenever they deem it "necessary"... you know 'cuz you, their customer is the biggest threat to them and the users (Google/Apple)... honestly at this point I am all down to just go to another app store... once they let you do that without restrictions on the device Yyou paid for....
Listen, I totally agree with you. It's total BS and should be better.
That being said, I also think your frustrated and typed word salad into the reply box.
I'm not apple. I don't like apple's practices. I don't own any apple devices (beyond what's required to support an iOS app) because I take an issue with the same things you do.
The reality is, if you want to support apple devices, you have to play their game, and that means updating your apps regularly. Sorry if you don't like it. I don't either.
This is ridiculous. A game that has no online component has roughly zero maintenance burden. This is why, for example, the original Deus Ex is still one of the better ways to spend your time playing games on PC.
Network connectivity has brought along with it a certain level of toxicity around updates and maintenance and such. At the very least Apple could be shipping older runtimes, downloaded on demand similar to Steam Proton runtimes.
The more reasoned part of me says that you're totally wrong and you can boot up Windows and run software from two decades ago and the only real issue will be high dpi support which can be worked around.
There's nothing actually necessary about what Apple is doing in the least. They could even take a soft approach and simply slap a "vintage" tag on old unpatched software and call it a day. There is something profoundly stupid about automatically banning any software more than 2 years old from all Apple devices without even giving users the choice to use that old software. I'm not even saying it's morally wrong, or it's bad for consumers, I'm saying it an incredibly dumb decision.
There is SO MUCH niche software out there designed for a tiny audience which nobody will ever be able to afford regularly updating so long as it's still basically working. Trying to maintain this ideal where only well patched up to date software appears on the app store is just dumb.
Sometimes they just force you to implement feature for them, like “Sign in with Apple”
> We’ve updated the App Store Review Guidelines to provide criteria for when apps are required to use Sign in with Apple. Starting today, new apps submitted to the App Store must follow these guidelines. Existing apps and app updates must follow them by April 2020. We’ve also provided new guidelines for using Sign in with Apple on the web and other platforms.
> 4.8 Sign in with Apple
Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option.
And implementing Sign in with Apple in Unity is one of the worst experience in my career that I dedicated a blog post talking about:
- Native Sign in with Apple button not working in Unity
- Official Sign in with Apple plugin provided by Unity also not working
- Hooked up API with help from GitHub and created Sign in with Apple button by myself ended up getting `4.0 Design` rejection without explanation
- Trying crazily to contact Apple reviewer for weeks only to find out you have to use system font on that button
- Unity cannot support new Thai system font after iOS 13 and they mark it won’t fix
- Ended up building a native sample app and screenshot Sign in with Apple button from it in 12 different languages into PNGs and ask the my designer co-worker to remove background for me to import them into Unity
- After all these the update is finally accepted by App Store
- Casually downloaded games by other companies a week later, saw a totally malformed Sign in with Apple button not being nitpicked by reviewer and just went live like that
While Apple could do a Microsoft and try to keep third-party software working for decades, they've realised they can offload that work to the third parties for free.
I can easily run old x86 Linux binaries on ARM, and vice versa, automatically with binfmt_misc. User-mode emulation allows you to run x86 Windows binaries on ARM WINE, as well.
And Microsoft fully supports running x86 applications on ARM Windows[1], as well.
My raspberry pi boots Windows 3.1 just fine (through dosbox). It's more likely to run a random dos / win 3.1 program than my iPhone is to run a random piece of old iOS software.
Put another way, the raspberry pi runs all but two of the games I played in that era. I can think of 6 iOS games that no longer run, and I played at least 10x as many games on DOS as iOS.
My experience with productivity software has been similar.
Totally, but that’s not what I’m talking about. We did the move from OpenGL to Metal, for example. It was tough, but it is a huge improvement and we were glad to do it to avoid code rot. I’m talking about how something that we wrote and compiled with the last fully updated IDE a few months ago suddenly stops working in the next release and requires tweaking. This isn’t 20 year old code that we haven’t touched. It’s 20 year old code we’ve been religiously updating the entire time.
Technical debt has a cost. Raymond Chen has countless blog posts about what it takes keeping backwards compatibility working. For example, an update to some part that should not break anything actually ends up breaking an app because the developers decided to monkey patch based on a match of a byte string or whatever that ended up changed.
The only reason WINE works is because of a massive community effort to reimplement those bugs that Windows is forced to keep.
there is no reason to assume a priori that systems improve over time. if anything, the opposite is the case. the overall computing experience has been steadily declining for many years, due to the web, javascript, electron, etc
Working on games with Unity for nearly a decade, the standard approach is to defer upgrading Unity as long as possible. Generally we stay on the old LTS (Long-term support) version until it’s no longer supported. Latest version and new LTS are very unstable with game crashing bugs on certain platforms that I had to spend weeks to track down and spend weeks to convince Unity QA there is actually a problem then wait for months to get it fixed. It’s better to just stay away from the latest and greatest, having other people do the demining.
Games aren't like other software. People are still playing Psychonauts even though it hasn't been updated in a decade. Double Fine doesn't have the resources to go in and update the game engine every year.
(I'd argue there's more room for this in non-game software as well, but certainly for games...)
It is already very time consuming to stay up to date with Apples ecosystem. Swift evolves. Xcode changes. The runtime. The App Store. The APIs evolve. SwiftUI is radically different every year.
Throw something like Unity in the mix and now you have even more things to keep up to date.
You can say well that is just nonsense. My app is finished. But is it really? what if you actually need to do a critical bug fix. Or something to be compatible with new hardware?
There is no simple answer here. But one thing I’ve learned is that staying as “standard” as possible is a huge huge advantage. Apples upward path is mostly manageable.
I wonder for how many people Mojave is the last Mac OS they can use simply because Adobe stopped selling software for anything later (you can only rent), and other various 32-bit reasons.
Adobe products are sadly required for industry work.
Imagine if the tools in your shed turned to dust after 5 years. And these are analogue, physical objects. Digital objects if stored in a properly error-correcting medium, can last indefinitely. No excuse for this.
Imagine a library of books where every book over 5 years old is burned.
You deserve more upvotes, because your analogies are not far from the truth. We are living through a black hole of history, where valuable information is being destroyed at unbelievable rates by virtue of it becoming completely inaccessible through the planned obsolescence of incessant upgrades.
That's not a reasonable comparison. A more accurate one would be something like having a 25 year old 12V battery drill and expecting the manufacturer to still make and sell the NiCad battery pack it used. Sure they could do it but it doesn't make any sense. Technology has moved on and there's no consumer demand for it.
I agree that Apple and other companies are too aggressive about breaking compatibility but it's not the same thing as tried and true physical objects.
This is not a good comparison. Nobody is trying to use a new battery. They just want old battery to continue working as it has. Code does not rot like batteries wear out. Companies deliberately break compatibility, and then they blame arising problems on “code rot”.
Changing icon should not require a new build. A new build should not require iPhone X support. iPhone X build target should not require Xcode 9. Xcode 9 should not require macOS 10.12. OS update should not break old Unity3D. Upgrading Unity should not break builds.
These are all examples of shitty engineering decisions that throw backwards compatibility under the bus for shaky (expedience, mostly) reasons.
Here's the thing though—if I want one of those books that the library removed from their collection, I can do some research and track down a copy from another source.
On iOS, there is no other source. Once Apple removes an app from their store, that's it—unless you bought it already, it's gone forever, no recourse.
> Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build.
* The iPhone X was released on 2018.
* Xcode 9.0 was released on 2017, and 9.4.1 (last release) on 2018.
* macOS 10.12 was released on 2016.
I'm sorry to say, but this sort of setup does not reflect well on anyone working on the project. Apple's call out should be considered a wakeup call.
Also, doesn't Xcode 9 only support iOS releases up to iOS 11? The global market of all iOS versions lower than iOS 11 should lie in the lower single digits.
The problem here is unity (which, by the way is one of the most popular game engines, and is often sold as the indie friendly, mobile friendly engine). Standard operating procedure for Unity games is pick the latest LTS engine version as the base for your project, and don't ever update, because the updates are _so_ much work it's untenable to keep up with them. (This was official advice given to us by a unity sales rep at one point in the last 2 years).
These aren't like node updates, these are closer to Firefox removing legacy extensions, except happening quarterly. There's no guarantee that something that is "stable" in your version will work the same way in a newer version. Unfortunately, the engine is tied to specific iOS SDK versions, so in order to use a more recent iOS SDK you're forced to upgrade your unity version alongside it...
The idea that Unity (market cap $22 billion) should put in the work to stay compatible while Apple (market cap $2.64 trillion) should not is deplorable.
I'm certainly not making the claim you accuse me of, however Apple's compatibility is substantially better than Unity's. Apple's reasoning for breaking backwards compatibility is often sound; reducing the attack surface of misused APIs. The alternative is what you have on Android right now, a bunch of applications that still ask for the sun and moon and stars for permissions because they can. Unity's path is more of a scorched earth policy in my experience.
If you set warnings to errors, and upgrade your compiler from time to time, you're asking the compiler people to help find hitherto undiscovered issues in your code using the latest diagnostic tools that they have come up with.
If you don't want to be informed, then don't do that. But those issues could be real bugs.
For instance, one fine day GCC got the ability to diagnose situations when the indentation of an nested if statement is deceptive compared to the actual precedence of the clauses. So if someone had warnings as errors, and had such a statement, then their build stopped. If that was a real bug, they were grateful.
Please, please, please don’t do this for end-user compiled software, because someday they’re going to be using a more modern compiler than you and their build is going to break because of new warnings that you couldn’t anticipate.
There is a sane alterantive: keep your code free of warnings, so that they stick out like a sore thumb, so that you then take them seriously in order to ... keep your code free of warnings. Disable anything you don't intend to fix; don't leave it littering your build output.
A clean build looks like this
CC foo.o
CC bar.o
CC parser.o
parser.c:42: warning: new thing found here (-Wnew-thing).
CC lexer.o
...
you hide all the details of the compiler command line so the diagnostics stand out.
Warnings-as-errors is just a kind of negotiating hammer that is useful in team situations, when the developers have gotten used to ignoring new warnings, usually because they are hidden among reams of ignored old warnings.
Also, in a compiler that has a GCC-like interface, you can turn specific warnings into errors, which is useful. If there is something you don't tolerate in the code base, and it happens to be diagnosable as a warning, then you can error it.
GCC turns some required ISO diagnostics into mere warnings, like say assignments between incompatible pointer types. That kind of thing may be worth turning into an error.
I've had to remove deprecation warnings because downstream users enabled warnings as errors in their releases. They could fix newer versions of their software, but being able to build old versions on new dependencies was a requirement.
The solution was to introduce a deprecation message that wasn't technically a warning, and warn about the upcoming depreciation warning.
The solution with a compiler that has a GCC-like interface is to use -Werror=<specific-thing>. Not -Werror globally for all warnings that currently exist and that will exist henceforth.
The best approach I've seen is to make it easy to toggle Werror, but make sure each PR and all automated builds are built with it on. Werror off by default makes more sense if you have more non-developers building it than team members.
When the bug they're being forced to fix does not affect them. This can happen when they want to make some other change, or maybe they don't even need changes, they just need a build that doesn't exist.
New warnings usually do not indicate real bugs. Sometimes they do, but usually they are false positives. -Werror causing a build to fail is strictly worse than the alternative (working roughly as well as before, sometimes slightly better or worse due to new optimizations). This is the direct cause of "software decay" here. The software would not "decay" nearly as much without -Werror.
Often a technical linux user will want to download a source tarball for a particular version of a utility or program, and build it on or for a particular linux distro they're using. They usually do not want ad-hoc modifications done to the source of all the specific utility versions they compile for their system this way.
When that's the only way to just get the software, because there is no binary package. If it doesn't build or run, some users just give up and go onto something else.
Sometimes the package maintainers who make binaries for themselves and others don't want to fix bugs. At most some minor build things, but something actually broken is punted upstream.
You may see behaviors like the program being disabled (unavailable) for some platforms because it couldn't build or tests didn't pass. Or the package will stay on the old version of the program: 1.2.3 isn't building, so we just give up for now and stick with packaging 1.2.1. Maybe 1.2.4 will fix it. In these situations, package maintainers will not always contact upstream; the developer doesn't know unless they go into that distro's site and search the issues for activity related to their program.
Sometimes recompiling into a new version of Xcode is required and that can result in very painful edits. While locally you can do whatever, apple often requires you to be using a very recent sdk (sometimes for good reasons like OS security of privacy changes)
I was really upset when I ran into this problem with Docker. Like, I thought the whole point of virtualization was that, no matter how old it is, it will Just Work, so long as the virtualization software works, and it has enough resources. It’s supposed to sidestep the problem having to constantly patch everything that might have changed since.
Then one day, our startup brought some new employees on, who read the README and ran the indicated Docker command … and it failed with a mysterious bug requiring dev resources to debug! The exact thing you try to avoid by freezing the machine environment.
It turned out that Docker had silently pushed a backward-incompatible change in the format of docker-compose YAML files.
That's not what containerization is about as can be easily demonstrated by simply running your container on a kernel that's built without some config option you rely on.
Wait, what? So this isn’t a problem because you can just make a container for your containers that preserves the original API? Then what do you depend on for that container?
It’s like Office Space, “what would you say it is you do here?”
Containers standardize user space, and let processes think they're listening on ports that are already taken. They do some resource isolation, and provide similar security guarantees as painting the back of your laptop with snake oil.
They don't help at all with kernel API drift, and barely help with libc drift.
I didn’t say anything about security guarantees. Where did that come from?
You’re saying that using a container — which defines a specific version of an OS — shouldn’t protect against differences between that version and a new OS version? And shouldn’t save any effort whatsoever in reproducing the environment in which I got code working?
The sole purpose is so that I can leave an app configured to talk to port 8000 even though my machine is already using port 8000?
That feels like it falls short of the conventional case for virtualization or containerization.
One of the main selling points is security. (They don't do much for security, but that sort of thing doesn't matter much to sales).
The most useful feature is they reduce the pain associated having negligently-large build and runtime dependency trees.
They also add a few ulimit style tricks. Think "better than chroot, arguably worse than BSD jails", but with a standardized cross-linux-distro build system (dockerfiles)
I asked for their ostensible justification. A valid answer should not involve making up a justification I never referred to, with the implication I had done so, with you refuting said justification, even if other people proffer said justification.
And the reason that I asked, was because the first reply eye-rolled at the problem I ran into, and then (seriously, as best I can tell) suggested I should have solved it by nesting a VM within the existing VM to control the dependency chain that led to the problem — even though that was what the first VM exists to solve!
To clarify, here is that (dubious) reply again:
> That's not what containerization is about as can be easily demonstrated by simply running your container on a kernel that's built without some config option you rely on.
That is, surrounding the container by a controlled environment would avoid the problem… but I was already controlling the environment by a VM that exists to solve that problem! Hence, (sardonically) wondering what the first one is accomplishing.
> The most useful feature is they reduce the pain associated having negligently-large build and runtime dependency trees.
No, the most useful feature is locking down a machine spec that Just Works. When I have to go and debug things about that machine that suddenly fail, for reasons Docker (not the machine) introduced, I lost the most useful feature.
Sating my desire to have my app point at port 8000 and no other … is way, way down the list.
Justification? For what? Seems like you're the one who feels entitled for something, it's you who needs justification.
> and then (seriously, as best I can tell) suggested I should have solved it by nesting a VM within the existing VM
You were the first to suggest anything like that. My answer did not offer any suggestion for solution at all, read it again.
> No, the most useful feature is locking down a machine spec that Just Works.
That's not a feature Docker ever had or intended to have. Seems you have misunderstood something about what containers actually are. They're very explicitly not "virtual machines lite", and it sounds like you want an actual virtual machine instead.
There are things that containers acually do (I discussed those above, and won't repeat), and things they ostensibly do, but do not actually do, such as security sandboxing, or providing a fixed, "just works" environment for your binaries, like a VM would.
As far as I know, the people making the incorrect claims/assumptions are distinct from the people that built commonly-used containerization software.
If you want to understand what containers are, start with the mental model that it is a chroot with /dev, /sys and /proc mounted, and with processes running with uid=0. Their sandboxing isn't quite that bad, but they are closer to chroot environments (or bsd jails) than a VM. Next, package a few things by writing dockerfiles, then deploy them to a raspberry pi or something.
If you still care, then follow up by reading the kubernetes tutorials.
> shouldn’t protect against differences between that version and a new OS version
What does "should" in this context even mean? They don't, because they're not meant to do that. They can be used to shield you from some differences, and for many use cases that subset is all that matters, but they don't and can't shield you from all of them.
I was asking to clarify what your very confusing sentence meant. Because it seemed to be saying that, if I define a VM to use OS 1.2.3, because I know my app will work with that version, then my app on that VM should cease to work when 1.3.0 is released. And that seems dubious.
You seem to confuse containers with virtual machines. Those are very different concepts that solve different problems.
You can't rely on containers alone if your goal is to ensure that your app will work on future operating systems. That's not something containers do. They only let you provide your own user space to run in a quasi-isolated environment, no more than that. You're still using the host's kernel which can still screw you up in multitude of ways (which is exactly what I said in my earlier comment), and you're still limited by API guarantees that the tools you use to make containers are providing you.
-Werror is your mistake here. You can still fix warnings when you see them with a new compiler, without using -Werror to cause complete build failures except with a specific set of specially accommodated compiler versions.
LOL! If only. We started out that way and nobody fixed their warnings. The only way to make it happen was to make it so they couldn’t compile with warnings. (And we do selectively turn off certain warnings that aren’t helpful and give false positives.)
To be clear, I’m not talking about having to clean up a few new warnings with a new compiler release. That’s fine and probably a good thing. We really have to have one of our top engineers dive into it for several days to get things in shape. It just seems really weird to me.
A code review tool should display warnings, and reviewers should expect fixes for real problems that show up that way (and suppression of false positives).
^ feels key. as a perpetual old device user it feels like platforms are continuously degrading the value of my hardware with updates, perhaps unintentionally through changes to hardware acceleration, sometimes intentionally like apple's throttling
This is/has always been obvious to everyone that works with Apple hardware/software, it's not really a secret.
They move this fast to keep people on their toes - they know that everyone will just have to keep running after them, otherwise you lose a huge part of your userbase.
I assume this isn't as much of a problem for regular apps, but games are finished pieces of art and recompiling them with a new engine version is often unfeasible.
I was using a 2011 12" MacBook Air until recently, for work, music making and personal usage. Only traded for an M1 because thought it was cool. If anything it's 3rd party dev stuff that requires bleeding edge machines (eg: Docker).
My 2007 17" MBP works fine, and I pull it out when something strange happens with my router, since it has an actual ethernet port. However, the battery has bulged so that the trackpad is difficult to click.
I have a 2012 MBP that still works just fine. Better than some of the newer Apple devices work has thrust upon me. I also have a g3 imac that turns on just fine.
No, actually, upgrading X Code requires a trip to Apple's website. On Apple's website, mobile application developers are likely to come across previews of great new content on Apple TV+, thus enticing them to sign up for Apple's streaming offerings.
I think it has. On Windows, famous for its backwards compatibility, you still have software that shows ancient dialogs, have graphics at a resolution for 640×480 monitors, or that work with 8.3 file names, and only with those (so, you can’t save docs with long names, and have to guess at the short names of files and directories with long names)
Yes, banning such apps is a loss for the customer experience of being able to run such applications, but there are disadvantages, too. For many of those applications, users would be happier _if_ those applications were maintained and adjusted to modern hardware and new OS capabilities.
Now, of course, that’s an _if_. Apple makes a different choice than Microsoft there. They think losing applications isn’t a big problem (presumably as long as replacements exist, but even that isn’t strictly necessary for some tools. The public at large can do without a Kermit program or RSS reader, for example, because it has alternative ways to download files or access news)
1) The customer who does not need a Kermit app is not forced to use one. Nor even are they forced to live with a crappy OS just so that old apos can keep working. The customer who does need a Kermit app, is forced to live without.
2) Even worse, they are forced to live without even though the work was done to create one and they had it yesterday.
This is not all explained my mere inevitable and unavoidable compatibility creep, nor by the sensible goal not to be Microsoft with their mountains of Rube Goldberg code to deal with countless obscure backwards compatibility quirks.
That will make things break eventually, but this an arbitrary and voluntary choice driven by goals other than serving the needs of users as well as possible in trade for their money.
Apple values their appearance and their revenue stream above all else.
Setting aside malware and other demonstrably legitimate security topics, because we aren't talking about apps that are no longer safe to use for some reason, or that are no longer compatible with the OS because of security-related changes in the OS.:
Purging all apps that are "ugly" or have any sort of undesired ux, or that aren't generating income for Apple one way or another, benefits Apple, not the users.
The users would prfectly happily simply not use an app that sucked. If any are using it, then it must be supplying some function that the user wants. Whatever that function is, obviously it matters more to the user than any of the excuses for removing it. It only benefits Apple to purge them, not the user, and it's not a case of "What's good for Apple is good for is good for all Apple users"
I don't claim it's just Apple either. Google increasingly does the same thing, just a bit less.
2 years is definitely too early, especially considering they're doing this to developers who are continuing to pay them $99/year to keep their apps up. The iPhone X came out 5 years ago, that was about the last time an update was needed to not look bad on newer devices. Some other commenters here fail to understand that many games are simply completed and don't need much updates to keep working on newer devices, especially if they purposely use minimalistic graphics. Even for regular apps pruning them after 2 years is a bit excessive but it's slightly more understandable there as they'll feel dated more quickly.
At some point it makes sense to update even if the content itself is "complete": supporting newer screen resolutions natively (instead of going with some kind of fallback behavior), making sure all the outdated and long since sunset 3rd party SDK calls don't cause crashes etc.
Also if you managed to build, prepare (App Store metadata in different resolutions etc), submit and finally get your app shipped to the end user that was no small feat a couple of years ago. Probably not a very useful skillset to have if you only do it very infrequently (read: waste of time).
Requiring additional screenshots, icon sizes, universal app (iPhone+iPad, also supporting split view), new copy for different types of meta (e.g app sub title) for all the locales you probably had translated externally at some point, new privacy guidelines etc.. all not very attractive to get into even if not forced to update like this, especially if you lose your ratings in the process.
As with so many Apple policies this is perfectly understandable but becomes unacceptable because they monopolize access to applications on their platform.
This is exactly why I wanted to leave Apple's ecosysyem for my games and go pure HTML5. Attention and updates (XCode, OS) needed just to keep an app up, not worth the time for me.
Yeah, HTML5 is incredible in that way. How much effort would it be for you to convert your iOS games to HTML5?
Very curious as we’re building a mobile-focused platform for HTML5 games that make it easy to make your game social. I’d love to help save some of these great iOS games being removed.
As a game developer I’ve always been saddened by the ephemeral nature of games. It seems impossible to make a game that would last 20, 50, 100 years. Books, paintings, even movies have such an advantage
That’s not strictly true. There are multiple examples of e.g. Sony and Nintendo re-re-re-releasing old games that are easily 20 years old.
But the comparison isn’t entirely fair. If you were to compare a game to a concert or a festival, as an “ephemeral cultural performance by a large group of people” you could also argue that a festival lasts for a set number of days, until it’s gone, forever.
Arguably the best way to make a game that'll last "forever" is to target some old console that has plenty of emulators available. If you make a PS1 game in 2022, I guarantee there will still be an emulator that can run it 20 years from now.
It’s not hard to do a recompile with a slightly newer SDK, check things still work, update the version and copyright and re-upload. That’s how I keep all my apps in the store.
Often you find a cheap update you ought to make, like add dark mode support which wasn’t a thing when the app was written. Sometimes you take the app across a tech boundary, like adding ARM code to a Mac app. I can see Apple’s motivation to keep fresh goods on their shelves that work with current OS versions and hardware.
Games are immensely more complex than your average run-of-the-mill smartphone application. As the author of the submission tweet themselves say:
> Now I need to dig up my project file, update the Unity version to make sure it meets the App Store requirements, rebuild, retest, resubmit all to get the exact same game in the exact same place it was before.
From my own experience, updating the Unity version tends to not be hassle-free, especially if it's a major version. Updating xcode tends to be a hassle as well, if not outright impossible unless you keep buying new Apple hardware too.
And why is the onus on the developers to update apps just for the sake of updating them? Can things not just be "done" anymore? There doesn't seem to be any specific reasons except "we like fresh updates" provided for why the updates should be done.
If it works, why remove it? Are they running out of space? Are people being fooled by the application somehow?
Updates should be required only when specific apis or features are deprecated and the app in question uses those.
But there probably isn't an easy way to test whether an app uses them. Aside from literally going through the binary, looking for those calls or something.
>> Updates should be required only when specific apis or
>> features are deprecated and the app in question uses those.
>> But there probably isn't an easy way to test whether an app
>> uses them.
Xcode tells you what deprecated calls you are using every time you do a fresh build. The list varies by which minimum iOS version you state.
Xcode also tells you if your project settings need an update, and will do it for you.
You should always be able to do a fresh build, or your app is effectively abandoned.
It's hours of work - recompile, test, publish, test again once new versions hits the App Store. Upgrades and maintenance are a bigger time sink than most consider.
And this assumes there aren't any new issues that need fixing during the maintenance.
Only if you're doing it constantly for every SDK update. But if your game is complete then you have no reason to do it, and if you haven't updated your SDKs in 2 years, chances are that you will not be able to do it without re-writing a huge part of the software.
No app is feature complete on a changing platform. The OS changes and the new hardware is different. Assumptions made years ago no longer hold.
One of my apps has been in the store for 10 years (Mac & iOS) and I have had to make many updates to keep it fresh. (Adding Retina support to the 3d rendering code and the picture assets, going 64 bit on iOS, dark mode, adding ARM to Mac, replacing deprecated API use, etc, etc.).
These changes are in addition to updates that fixed bugs or added actual new app features and are part of the cost of doing business.
I considered going into phone apps, and reversed course after Jobs' attempt to limit the set of languages one could code in. I have never regretted the decision, and wish other devs would stop building on such unstable foundations.
The worst part of all of this is that their stores DO have heaping mountains of apps that should be removed: the outright scams, the useless apps full of trackers, etc. Absolutely no effort whatsoever is being placed into removing things that are truly harmful.
There is a very clear hierarchy here, and it isn’t “developers first” or even “developers 7th”. Instead, it is: whatever makes an absurdly rich company even richer is A-OK, the “curated experience” will be sure of that.
This has also happened to me with three games I have worked on (published 2010, 2012, and 2015)
I updated the most popular one to keep it on the store, and made it much better in the process. It didn't support modern iPads with rounded corners, and I updated some of the menus and fixed a few small but long-standing bugs
In all it was a good thing that something got me to make an effort on keeping my stuff polished. It took about two days, but I ended up with a much cleaner git repo, fixed build issues, and better media and copy for the store presence
As for the other two games? I was happy to let them go. They were beyond my ability to update for modern hardware. I'd rather not have them publicly available than running in some half-assed compatibility mode for modern hardware
I suspect I'm in the minority, but I like being forced to keep my active software actually actively maintained
I’m personally banned from selling on Amazon “due to inactivity”.
In college Amazon advertised on campus that you could sell your textbooks, so I did that. Now, years later, they advertise “Sell Your Stuff”—but too bad, in the interim my account was closed without notice and there’s no appeal, and no way to open a new one.
This is exactly why I refuse to buy any ios apple that cost more than $1. They're inevitably going away.
This is also why the iPad is never going to replace a computer for me. Any productivity ecosystem I create for myself is just going to break after a couple of OS updates.
Generally, even if an app gets removed from the App Store, you can still redownload it anytime if you've previously purchased it. The only exception is egregious cases where the developer's account gets terminated. But even then, if you backed up the app's IPA in advance, you can reinstall it anytime. (This is distinct from sideloading, as an Apple-signed IPA is encrypted and tied to your Apple ID but has no expiry date.)
But what's the rationale behind this specific $1 limit? If something were to keep me entertained for several hours with no advertising, I'd certainly consider that worth $1. Going down the free route would likely end me drowning in a sea of advertisements.
If you want to make stuff for the people who chose to impose the Apple platform between you and them, that's what you deal with. It's a choice.
Maybe the breaking churn in Apple is what brings the novelty seekers, and their money.
Unity and whatever breaking and not running well on older hardware has to do with people buying new hardware. Those are the people who bring the money to the table, which is what you must want a piece of if you have your neck in that toilet bowl.
Just append “2022” to your game’s name and update the copyright.
I just played a “new” Pool & Snooker 2022 game in Apple Arcade and it looks and plays like Pool & Snooker 2012. The copyright says 2012-2022 so I assume the devs just lazily update the name each year and nothing more. Not seeing 10 years of improvement in this. Some of the graphics still don’t even have anti-aliasing…
As an experiment i tried an iphone4. Apple support helped register an account which didnt work any more for multiple reasons, the app store works just fine, you just cant get any software. Clicking on download does dl the apps but then it says you must upgrade your OS.
There is no software!
Developers say they have a version for it but you may not install apple says. What kind of deal is that? Its a good device, it could have all kinds of applications.
The iPhone 4 is not a “good device”. It’s 3G only and the networks have already announced that they are completely shutting down 3G networks by the end of the year.
it was revolutionary at the time. It doesn't need a sim to be useful, it needs software. Lots of software exists but new things are also an option.
say, what does a video doorbell with a screen cost?
Reducing the functionality to a single thing it would do better as a proverbial alarm clock than my flagship phone where i cant seem to figure out how to kill all sound except from the alarm.
I hope web pages are never removed from servers on the basis of last modified date!
I wonder what is the etiquette for devs in their update notes, when there's no other change except this pulse update? Describe it accurately or slap a generic 'bug fixes' label on?
I received an email this morning saying the same about one of my apps, it hasn’t got any crash reports, still gets downloads after 5 years, doesn’t need a v2 and Apple decide it’s time to go. Due to swift version changes I don’t have time to push a meaningful change as it doesn’t compile any more.
Yeah I used to have a bunch of (mostly Android Wear) apps on the Google store but they started getting deleted one by one, they kept having new policies that you needed to follow to have your app stay up. I have a dayjob and don't have time for that shit. Pay me and I'll do it.
Could it be easier just to rewrite this game on web technologies and build a hybrid app for App Store? As a bonus it will work as PWA on any device (if author wishes to publish is like that), and future updates will be much easier.
> I'm sitting here on a Friday night, working myself to to bone after my day job, trying my best to scrape a living from my indie games, trying to keep up with Apple, Google, Unity, Xcode, MacOS changes that happen so fast my head spins while performing worse on older devices.
I can’t help but shake my head when Indie game devs unload these sob stories trying to garner support. If it’s so hard for you then just stop making games.
I often get this whiff of entitlement from indies that we should be supporting them because they are small, often one man operations. Or that because they invested so much time and money building a game, they should deserve to get that back through sales.
But the world doesn’t need more indie game devs, the world needs better games. I doubt a game that hasn’t been updated in 2 years is any good or doesn’t have a million competitor clones by now.
> I doubt a game that hasn’t been updated in 2 years is any good or doesn’t have a million competitor clones by now.
That statement doesn't make any sense whatsoever. Games can be "finished products". Do you also think that movies and songs that haven't been updated aren't good?
There are plenty of games from the 80s, 90s, 2000s that are still selling today, in unmodified form, running via emulators.
And clones are 99.9% pure garbage that don't replace the real thing.
But at that point, a bunch of us moved our game purchases to indie games, specifically because they still act like products and not services.
Honestly, I'd rather play the original binary instead of some slapped together port to current unity + xcode. At best, the physics or something are slightly off. At worst, the game has major regressions that were introduced by the latest build.
I'm probably weird, but I like buying consoles toward the end of their lifecycles. That lets me limit myself to the top fraction of a percent of the games released over the last five-ish years, and still have a dozen titles to play.
“Finished product” games make most their money at the beginning of their life then peter out into a long tail of revenue that drips in slowly day by day, until it stops altogether or becomes negligible. This game dev has likely made as much as he will make from his game and it’s time to put it out to pasture and build a new game.
I was disappointed when I had to stop using the iSSH app because it wasn’t ported to 64 bits, since the author had died. Now I guess it wouldn’t have helped much if the app had already been 64 bits. Stuff like this is why I would be in favor of alternative app stores.
A company could be perfectly capable of running a market without taking an unfair advantage on their own products. Apple is using terrible business practices here.
Valve as an example runs steam with their own games, and also with paid community created remakes of their games sold on their same platform, they exemplify what I would expect from Apple, epic, Google, etc.
The number is about 20 or so games that have been removed by Apple because they hadn't been updated in two years. The worked perfectly fine on all the new hardware/software and even work today.
On top of that, I know that there is another 30 or so apps I was involved in with clients that have also been removed.
These weren't the biggest apps/games in the world, but they were all high quality finished products that had nothing wrong with them. Its just the cost of re-publishing each one out-weighed the return, so I didn't have much of a choice sadly. I do have plans to re-publish some of them, however they have to take a back seat for current work.
All that to say, I have a large part of my portfolio of work that is no longer available to the public, which just sucks.