What does it cost to republish them?
But usually after a few years Xcode will bitch at you about a lot of stuff, so maybe you raise the minimum OS version requirement, click "Fix it" on a lot of API respellings, find a couple that it can't automatically fix so you have to google that a bit. Then test and upload.
Maybe get in a fight with Xcode over your signing keys.
Sometimes something you were using gets deprecated and you have to use the newer replacement. That takes some coding.
It can get ugly if the 'owner' in the app store is not you or is an entity you no longer control. Then you have to get them involved to do the chain of trust signing.
If you produced it under contract, you may not be legally allowed to update it without a new contract.
␃
¹ do your testing is easy to say, but that could take an arbitrarily long time depending on how thorough you are. I expect this to be the dominant cost for most game updates.
² I pulled out one of my aging apps and just did all this to check, 10 minutes from "checkout" to "installed in TestFlight". The dreaded App Store review was 3 minutes. This isn't really a fair data point though, Xcode didn't suggest any source code changes so it was just bumping numbers and rebuilding.
There are many dependancies that require some kind of reimplementation, it's a pain.
I have made things easier (in the long run) with my last game. I wrote it all in c++ with all dependancies under my control. I was thinking >20 years ahead for that one.
Xcode, I use Xcode for the most part and visual studio for the Steam version.
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.
You missed one step: buy a new mac because the current version of xcode will not run on your old one.
It can become quite the rabbit hole, and thus quite costly.
It's a real cultural loss.
Meanwhile, the Wii’s web browser supported Flash, and the Wii is a lot less powerful than an iPhone.
The first iPhone that came out with those spec’s was in 2011.
- 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.
Cross platform frameworks like the initial poster alluded to always suck compared to native purpose built frameworks.
We see that today with Electron - a battery killing, memory inefficient, platform.
Flash on the Wii, as I recall, worked well mostly for flash games that were designed with the Wii in mind, and for very simple interstitials. Anything more complex did not work well.
I think Adobe could have done something similar on the iPhone. I don't know that it would have been what people wanted, and I think it would have exposed some of the iPhone's hardware limitations to users.
Mostly though, I think Flash was a heck of a lot better than what we have today with overly-complicated webapps and Electron, as you referenced. That's the point I was trying to make—we've ended up with something even less efficient than Flash ever was!
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.
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.
And then you go through review and they may reject your app because you get an inept reviewer who has a bad day.