Apple says they're removing my game because it's more than 2 years old | Hacker News Reader

Apple says they're removing my game because it's more than 2 years old

twitter.com

668 pointskeleftheriou410 comments

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.

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.

You need to recompile/submit with the newest xcode, which is not feasible for games as that would mean having to upgrade the engine.

You are spot on, but that might even be the best case scenario. Thing can quickly turn south and cost quite a bit of time.

What does it cost to republish them?

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.

If only it where only that simple.

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.

Can you share your game?

Yeah sure thing, this is Kanso on iOS (its also on Steam)

https://apps.apple.com/app/id1384257762

What do you use to write mobile games in C++?

A computer for the most part.

Xcode, I use Xcode for the most part and visual studio for the Steam version.

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.

Exactly why apple requires this

To cause developer pain?

To remove deprecated APIs, and to be able to force certain things like new capabilities.

The price for high levels of consistency. This is why Apple doesn't have the obsolete remnants problem that Windows does.

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.

This can take days. Tough ask for indie devs that are probably close to the wire, to insert a days long project, per app, into their schedule.

It can also take minutes. I had to add some screenshots, and recompile, then resubmit.

> Best case, check out your code, bump the version number, touch up your copyright date,

You missed one step: buy a new mac because the current version of xcode will not run on your old one.

I think you could achieve this on an EC2 Mac instance

Or Hetzner, or Scaleway for less draconian pricing.

Zero, just my time. And the cost of fixing all the problems with new versions of Xcode, Unity, and whatever else was used and has now changed.

It can become quite the rabbit hole, and thus quite costly.

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.

It's a real cultural loss.

Publishing only on proprietary OS in the first place is a cultural loss.

Hmmm, if only we had some cross platform framework that worked in every browser even before the iPhone was invented. /s

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.

And yet we didn’t have very complicated web apps (that didn’t use Flash). I’d like to see Slack on a 2008 PC.

Meanwhile, the Wii’s web browser supported Flash, and the Wii is a lot less powerful than an iPhone.

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.

I think it’s a combination of:

- Android itself really sucked at this point in time.

- Android and iOS in 2010 couldn’t run complex web apps either without chugging. It really had to be native code to perform well.

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.

I don't know.

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.

Are we saying those games on Nintendo, Sega, PlayStation and XBox are not part of 20 century culture?

No, we're saying that those games are not part of 21st century culture, which makes them culturally lost to time.

Time.

For a solo / indie shop, you have limited time.

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.

Were the removed apps compiled with Bitcode enabled in Xcode?

Some, most of them not.

Thanks for answering. I marked my theory disproved in another thread. Appreciated.

No problem, glad to help!

Seems like there is justification in Seperating them into an archive appstore/section at least.

Now ask how much it costs shovelware authors to republish their apps, and they probably do it all the time because the quality sucks..

Guess this ‘remove all the great apps that don’t need to be updated’ strategy is going to backfire.

Is it more profitable in the short term?

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.

It really shouldn't be my issue that Apple isn't able to maintain compatibility for two year old apps.

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.

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.

Half a decade? Wasn’t that introduced in 2010 with the iPhone 4?

The last two years feel like two months or something :D

* Fixed bugs and improved performance

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.

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?

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.

[1] https://en.wikipedia.org/wiki/The_Germans

> "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."

Given the state of the world I recently looked into this: https://www.kiwix.org/en/

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.

It lacks high-res images, category pages and I think "List of..." pages though, I think. Especially categories are a bummer.

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"

> (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.

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.

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]?

[1] - https://en.wikipedia.org/wiki/House_of_Wisdom

> It's ironic that the clay tablets we found are probably the only things that will survive another few thousand years.

It’s doubly ironic because the ones that lasted were the ones that accidentally got turned into bricks when they were in fires.

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.

Videos disappear from YouTube all the time.

Not to mention that a video is no replacement for an interactive game.

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.

YouTube could shutdown for any obvious or unforeseeable reason in the next 5-50 years.

There are several YouTube mirrors around. Clipmega and Tubidy come to mind

You must buy something new from apple every 2 years - OR ELSE

How much effort would it be for you to convert your iOS games to HTML5?

Then they can never be removed.

Very curious as we’re building an iOS/Android platform for HTML5 games. Would love to help save some of these great iOS games being removed by Apple.

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.

Meanwhile, games like Pocket God have not been updated for 7 years now: https://apps.apple.com/us/app/pocket-god/id301387274

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."

https://twitter.com/aaefiikmnnnr/status/931222777301835782

> A new build requires iPhone X support.

That sounds like a valid reason to require you to submit a new build. it came out in 2017 and most iPhones follow that build style now.

Just to clarify, the tweet was a couple of months after the iPhone X came out.

This tweet seems to be dated yesterday (4/22/22)

The tweet is dated they're talking about/ linked up the thread, is dated: 10:09 AM · Nov 16, 2017

https://twitter.com/aaefiikmnnnr/status/931222777301835782

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.

Reading this increased my heart rate.

That's not really about Apple but about Unity. I've recently written about what a nightmare it was to be a Unity developer: https://news.ycombinator.com/item?id=31065208

Unity sucks, but:

> "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.

I'm not familiar with iOS devices, but..

> * Apple requires you add support to new devices to push a new build. (this is the principal policy decision).

Doesn't the original, old app run unmodified on new devices anyway?

> Doesn't the original, old app run unmodified on new devices anyway?

Only in an ugly fashion because of different aspect ratio & notch.

Apple required you to at least nominally support the iPhone X to push a new update to an app.

1, 2, and 3 are actually all Apple policies.

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.

> 1, 2, and 3 are actually all Apple policies.

I basically said that.

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.

This line of explanation is an excellent example of when C-suite types walk in and ask, "Why can't you do {simple thing X}"?

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.

Especially for people who can't be bothered to develop native applications.

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.)

> A new build requires iPhone X support

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?

Reason? Maybe. A good one? I don't think so.

For a company who sells phones, it's a pretty good one.

Jeez - this was stressful to read.

Was the removed FlickType app uploaded to the store 2 years ago with Bitcode on, or off?

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 believe the notice said that they would be delisted

Nope, "removed from Sale".

You might be thinking about the fact that users who have previously downloaded the app will still be able to do so.

“Delisted” and “removed from sale” sound like synonyms to me. How do they differ? Neither necessary means “totally removed from Apple servers.”

If an app is unlisted it could still be accessible by a direct link.

Unlisted ≠ delisted. Delisted sounds to me like removed from the App Store, and unlisted sounds to me like hidden.

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 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.

Disproven here: https://news.ycombinator.com/item?id=31137909

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.

How about using the carrot and not the stick?

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.

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.

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.

> Apple has now forced these companies to maintain their stuff

No it hasn't. They can rebuild without improving anything.

If they do Apple can just reject the update. For better or worse this also amounts to a re-review every couple years.

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."

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).

How is that Apple's problem, you should read the reviews about the company's products and see what people are saying about the apps.

> 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?

How is the age of the app relevant?

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.

This is a design flaw from Apple, not an inherent fact about software. On PC most older games scale fine to modern resolutions.

Older games sell a lot worse than freshly released ones. Non-game apps somewhat depend on freshness too, but I’d guess not so heavily.

That would make ongoing maintenance more expensive for games than for other apps. Maybe Apple should honor that and allow more slack for games.

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.

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.

Removing by sale / usage rate might be fair.

No one opened your app in 2 years? It gets the boot.

If an app is still actively being used, removing it hurts developers and users!

I have apps on my Android phone that haven't been updated in years. They work just fine.

Heck on my MacBook I use an app that wad last updated in 2016 or so, and I consider it a vital pri0 part of my daily workflow!

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.

[1] https://boisefoundry.com/scam-apps-on-apples-macos-app-store...

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 consoles only change hardware or operating systems once every six or seven years.

And the store usually stays online for another 3-4 years after the console's successor has come out

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.

It's a good thing I don't care for online gaming!

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.

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.

Yes and Apple updates the operating system for those same phones every year.

Microsoft somehow manage to maintain backwards compatibility for much longer than two years.

Windows only really works on x86 and is a mess of legacy and semi-deprecated APIs.

Too much backwards compatibility is as bad as too little.

On the other hand, trust in a random Windows download on the Internet is low, and the Microsoft Store engages in app curation.

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.

(Windows user on and off from win 3.1 to 8)

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.

> 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.

https://variety.com/2019/gaming/features/android-ios-apple-g...

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.

Just imagine this requirement on any other operating system.

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.

It is actually the oposite on Linux. You compile on older distro (e.g. CentOS 6), and it will work on later versions, (CentOS 7).

https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...

> In fact in the free and open world of Linux, backwards compatibility is even worse…

I have linux binaries from 2001 that still work fine on recent Linux kernels.

If they're CLI C ones, or statically link all deps: sure....

If they link against libstdc++, Qt or Python, good luck...

Those three you listed have definitely been the most problematic by far when trying to run things on Linux.

Games usually bundle or statically link their dependencies (just like most software on 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.

http://cd.textfiles.com/hmatrix/Tutorials/hTut_0239.htm

Also, by Apple eventually abandoning backwards compatibility, it was able to migrate Macs to different better processors four times.

By abandoning 32 bit software support, it was able to save space on its processors.

> 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.

Gesturing towards an IIS bug discovered twenty years ago does not bolster your argument.

The 20 year old bug was caused by Microsoft not testing compatibility hacks and old deprecated code from 25+ years ago.

According to Raymond Chen (author of “The Old New Thing”) there was literally code scattered all through Windows of the affect:

   if app == “SimCity 2000” then doCompatibilityHack()

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 build my software to last.

Almost no one else seems to care, but I am too stubborn and lazy to do it any other way.

> 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.

Can people with older phones still buy a new copy of it though?

I've quoted you in the past [0] and usually align with your takes. Consider attending our conference sometime :)

[0] https://media.handmade-seattle.com/self-hosted-conference/

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.

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.

iOS does not have “perfect backward compatibility”.

I hope that boot's tasty.

> then your business model is not sustainable

As if that was the concern there at all. Most people who publish free games consider them "art", not "business model".

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.

Apple removed all support for 32 bit code from the hardware that’s one thing.

But even more recently, there were deprecated APIs that eventually Apple stopped supporting.

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?

Yes.

Excellent logic for a curation platform. Unfortunately, the App Store is a monopoly on app distribution, not a curation platform.

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?

On the other side the grass has the same colour.

https://android-developers.googleblog.com/2022/04/expanding-...

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.

Yes, anything written for these platforms is not likely to be around in the same form for the long term. It's disposable software.

Except the use of Google Play is not a requirement. You can do your own distribution on your own terms and act as if Google doesn't exist.

In principle yes, in practice Google makes it much too difficult and scary for typical users.

It literally takes three taps to allow apps from an "unknown source".

No regular consumer bothers with that.

It seems to work for Telegram.

Nope,

https://play.google.com/store/apps/details?id=org.telegram.m...

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.

Normal people use the store.

When you have big games not on the appstore like Fornite it teaches a new generation how to do this. The warning becomes meaningless.

Apparently you missed the news that Google has placed Epic on its place.

With multiple big scary warnings.

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.

[0]: https://gist.github.com/Efreak/b754063c18c8749aa339baffeab9f...

[1]: https://gist.github.com/Efreak/b754063c18c8749aa339baffeab9f... and https://gist.github.com/Efreak/b754063c18c8749aa339baffeab9f...

Kind of but it's not a practical option, Google made it as painful as possible

According to Google, that's changing soon (probably in an attempt to ward off pending app store regulation).

It is pretty easy to turn this on. The ability to alter settings is much greater for the average android user than in 2015.

Only if you don't care about making money with apps.

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.

So you want the government to come in and force software platforms to maintain backwards compatibility forever?

No, just ban software stores from removing working apps for no good reason.

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?

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.

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...

[1]: https://apps.apple.com/us/app/seismometer/id288966259 [2]: https://github.com/jnordberg/triggy

Does anyone have a Swift app without updates for more than 2 years on the App Store?

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.

Yes, Apple should have built in emulators for 68K, PPC, 32 bit x86 and 64 bit x86 applications.

I have many games and apps built for older versions of Windows that do not work.

How is this forcrd obolescense? This has 0 impact on those who already have the software downloaded onto their device.

It's worth noting that Google do the same thing on the play store.

It seems your issue is less about the facts of the matter at hand, and more broadly a dislike of Apple.

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?

They only comparable decay is bit rot.

"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."

Try to remember that you're talking about a video game that's considered abandoned, and that the author is allowed to re-upload it to keep it up

This is actually because the author doesn't want to do small labor, not because people are being silenced or murdered

He has to be alive to do that.

The poster of the article is alive, as is the person I'm talking to

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

There is no problem

"because it is perfect and a piece of art."

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.

"They're giving you 30 days' notice to show that you're still maintaining the app, and then it stays up."

Which would have been more than enough time... if the app had in fact been maintained.

And which doesn't change the fact that the developer agreement clearly states that apps must stay current and maintain compatibility.

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.

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)

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.

When do end users compile software but don't want to fix bugs?

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.

Is there any reason why the user in question couldn't turn off warnings at that point if they don't want to bother with it?

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.

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.

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.

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.

https://twitter.com/aaefiikmnnnr/status/931222777301835782?s...

The longer you leave the yak unshaved, the longer it takes to shave it.

My windows is full of bald yaks.

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...)

> OS update breaks old Unity3D.

I'm still on Mojave because I'd have to say bye bye to Adobe Fireworks if I upgraded.

You've had a decade to find an alternative to Fireworks - a vector graphics program.

It might be time to move on.

I still use EasyToon, originally published 1998. Then again, I'm on the only operating system that actually values backwards compatibility.

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.

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.

I mean they often still do …

https://www.homedepot.com/p/Milwaukee-18-Volt-NiCd-Battery-P...

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.

We basically have that with the way publishers license ebooks to libraries. :(

Libraries do cull their collection and sell books that haven't been checked out in N years, though, which is sort of similar.

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.

Couldn’t you do the same and find the author and get the .ipa file?

No, you can't sideload on iOS. IPA files are tied to your Apple ID.

Yessssss..... come to the Linux community. Become one of us... one of us. There is no better time than now. One of ussssss. =)

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.

It's called code-rot..

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.

Welcome to the real world

Meanwhile in the real world:

Windows software still runs 20 years after in compatibility mode

The binary still runs, but can you re-compile from source?

As long as you keep your old tool chains and old dependencies etc etc

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.

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

Which is great for users. I seriously love Sign in with Apple because it lets you hide your email address from random app #941245.

I always wondered why so many apps support it because it seems like they'd prefer to know your real email, but now it makes sense.

Linux runs thirty-year-old binaries because of kernel and hardware compatibility.

I can still run 20+ year old demoscene binaries on Windows and WINE. Linux binaries from that period still work, as well.

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.

Apple has also transitioned their entire platform from 680x0 to PowerPC to x86 to ARM.

Whereas Microsoft has been basically stuck on x86.

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.

[1] https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...

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.

> Systems improve over time.

They at least change over time. Not all of them improve.

Thanks to the magic of emulation, some systems keep improving after they stop changing.

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.

Welcome to the real world.

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.

Again, welcome to the real world.

It's a game though. What security does it need?

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.

> Systems improve over time

They do, but Apple intentionally harms older systems.

> It's called code-rot..

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.

My gut feeling is to agree with you.

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.

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

code-rot sounds like an appropriate way of describing what's happened to the OS and build tools.

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.

> 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.

You do realise the tweet you're replying to is from 2017?

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.

I don't see why API misuse is an issue for an indie game with no online component.

-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).

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.

> 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.

This can definetly happen in both directions (kernel too old, app too old).

For example, apache can no longer run with SSL enabled on current synology NAS's docker environments.

You asked what they do.

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)

>You asked what they do.

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.

Edit: This message is directed to SilasX.

What. I still play Super Hexagon occasionally and I’ve had that game on my phone for like 10 years.

Checked, was last updated in 2018: https://apps.apple.com/us/app/super-hexagon/id549027629

> while performing worse on old devices

^ 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

not surprised developers feel just as squeezed

LowStakesConspiracy: Apple needs to keep developers buying newer Macbooks / iPhones.

Or they don't want customers downloading apps that don't properly support their devices. makes the customer experience suck.

The customer-breaking changes are coming from Apple, not the app developers.

If Apple is so concerned about customer experience, they can just as well choose not to break existing apps.

The "customer experience" excuse hasn't held water in decades.

"If Apple is so concerned about customer experience, they should stop making their products better." is an interesting take.

What's interesting is no one said that.

Inventing your own false statement so that you can point out how false it is, is an utterly uninteresting approach.

> The customer-breaking changes are coming from Apple, not the app developers.

They literally said that. Form factor changes will break apps if devs refuse to update.

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.

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 disagree. The latest version of Xcode ran on my 2013 MBP, until a recent upgrade. Using the latest hardware is much faster, but not required.

I intend to keep my new MBP for another 8-10 years.

I'm surprised a 2013 Apple anything even turns on.

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.

From what I know, older Apple hardware(<2013) is vastly more repairable/durable. Wouldn't be surprised if quite a few people are still running that.

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.

You need to take care of the battery unless you enjoy it when your things catch on fire.

A new battery in 2021 helped get me through to the M1 Max release.

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.

This is untrue. Xcode is available in the App Store on Mac. You don't go to the website to get it.

You can get it from either

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.

> supporting newer screen resolutions natively

That's not the case anymore, but yes during the first ten years of iOS you had to recompile and resubmit your app to support new screen resolutions.

That was incredibly dumb. Even Android did not do this mistake.

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.

There is one thing worse than government regulation: having your market regulated by a company.

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

It is possible. Just¹ make a free software game. The community will support it forever if there is any interest.

¹ I know, it may harm your profit, but...

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.

Almost all commercially released games that are over 20 years old run fine on current cell phones or one of these:

https://retrododo.com/best-retro-handhelds/

Software archival is not that hard unless the ecosystem is specifically designed to prevent it.

Klondike has been running on Macs since 1984 and iOS since 2009 as iKlondike.

Source:

https://casteel.org/Pages/Narrative.html

you just gotta develop a game for a stable platform.

N64, GC, Wii, NES, all of their games still run on modern hardware.

Webapps will probably fair pretty well too.

As does Win32, Wine, Proton.

Your choice of stable platforms is actually pretty big in the game world! Pretty much every platform except native mobile!

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.

Some apps are feature-complete.

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.

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.

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.

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.

This happened to my sticker app. Simple iMessage stickers. The stickers are done and I have no desire to add more. What is there to update? …

I can’t wait until Apple is forced to add third party stores.

If Apple were cool they would have a boneyard section of the App Store where digital archeologists could sift through every abandoned app.

Maybe they could implement a 20 year policy where it becomes possible for the community to try to fix things that Apple breaks through forced updates.

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.

only a user having the choice to sideload or not can solve the issues of the AppStore.

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.

Similar current Twitter thread on the same issue:

https://twitter.com/lazerwalker/status/1517849201148932096?s...

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.

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.

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.)

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.

https://news.ycombinator.com/item?id=31135278

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…

Stop tending other peoples' gardens. Especially trillion dollar companies' ones. No sympathy here, we all know the drill by now.

> Stop targeting the two largest mobile platforms to gain customers and revenue.

That’s my paraphrasing of your statements. If the customers are in the garden, you have to go to the garden. That’s easier than building your own.

I will the day the US gets serious about cracking down on monopolies and I have several gardens to choose from or can start my own.

Its just rude to support such eco system.

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.

Sure, but it could still be used as a wifi-only device. I have an old iPhone 8 that I keep around for music and streaming to a TV.

And an iPhone 4 running iOS 7 can still stream your personal music collection that you can either sync via iTunes or download on your phone.

iWorks still works on my first gen iPad.

Only some networks. I'm not worried that 3G will stop working where I live anytime soon.

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.

> Stop tending other peoples' gardens. Especially trillion dollar companies' ones.

Meanwhile, Apple built their castle in TSMC's kingdom ...

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.

We need independent appstores where developers can distribute their work as they see fit.

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.

Games stopped acting like products long ago, and are now expected to be as a service.

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.

Obviously not the ones that are "finished products".

Or are you claiming that only "games as a service" are good enough, and all "finished product" games should be removed?

“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.

Expecting to be an unpopular opinion, but this also seems like an effective way to enforce maintenance and progress.

If a good app is no longer maintained, this will release space for new enterprising developers to come in and fill.

It’s fine. I mean Apple refunds you if the App you bought gets removed, right?

How much is this about being 'fresh' or using new OS features vs running old apps through their changed policies and app submission screening process?

Maybe a change in IP legals that can force corporations to open source deprecated platforms can help preserving these cultural artefacts.

Requiring software to use the latest versions of their SDK is not an excessive request.

You're welcome to not publishing your apps on App store.

Looks like Apple is exposing nasty bugs in Unity's failures to maintain compatibility with old source code.

Is there any effort going into iOS game preservation? Or current mobile games are just not worth it?

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.

Or switch to Prompt, which is actively maintained by one of the best iOS/macOS developers out there.

I have, out of necessity, but there were some features I liked iSSH better for.

The other “important” app I lost to the 64-bit transition was Mr. Driller. ;)

Uh, well... I bought prompt. Version 1. Which they quickly discontinued and delisted. I'm not paying again for prompt 2.

by analogy, youtube should pull all the videos that are not at least 1080p

live by the store, die by the store

Meanwhile, some of Apple's own apps haven't been updated for much longer than that – example: https://apps.apple.com/us/app/itunes-movie-trailers/id471966...

Rules for thee, but not for me!

It's almost like actively creating and running a market while also participating in it makes you gain unfair advantage. Who would have thought?

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.

App not available for me

I see the data feed is stale, but how do you know the build is stale?

The version history mentions the last update.

>1.4.4 Nov 3, 2017

For my friends, everything. For my enemies, the law!

Reply on news.ycombinator.com