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.

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

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.

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.

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.