Search form

Not So Fast!

Apple reviewed NEO Scavenger's release build, and found a flaw. They're saying it has in-app purchases but lacks a "Restore Purchases" button. The thing is, we have an "IAP Restore" button for this, but it's on the Main Menu->Options sub page. So it's unclear to me if they missed this button, don't like the name, or if the button needs to be moved. I've replied to their message for clarification, but it could be a while before they reply.

Fortunately/unfortunately, testing this revealed that we left a debug button in the release build for iOS. Just below said IAP Restore button. So I think no matter what, we're uploading a new build. Just gotta wait to see what Apple's advice is about the IAP button before pulling the trigger.

They probably just want it to either be more visible/accessible (e.g. move it to main menu instead of options) and/or more clearly labeled (e.g. "restore purchases" instead of "iap restore").
Or maybe they just didn't bother to look at the options considering that you found the debug thingie there. :) Shouldn't be much of a problem anyway if that's their only complaint.

As a huge fan of this game and an android user it's frustrating to know that the release on the play store is being hindered by the inefficiencies of the itunes app process. I suppose release parity is something a developer has to consider but, its quite dumb. I guess ill just wait a bit longer for apple to figure this out before i can play on my android device..... cool

@Chrisskates, believe me when I tell you I have a disdain for the iOS app process I normally only reserve for mortal enemies. The iOS on-boarding process is downright adversarial.

And if I had known this going in...nah. There's be no mobile version. At all.

Mind you, Google/Android has its fair share of quirks, too. But I don't feel like Google actively impedes developers the way Apple does. Unfortunately, word on the street is that the Android market can't match iOS in terms of revenue.

Which is a rock-and-hard-place that, in the end, probably means I'll never do this again.

The language wasn't too bad, to be honest. Haxe has an Actionscript-like library called OpenFL, and its own Flixel-like called HaxeFlixel. So porting the code to work in Haxe wasn't hard. We were able to automate a good chunk.

The hardest part of actual game dev on it was the UI. Making that work on touchscreen, and on small screens, was a lot of work. And making it not crash/glitch/render wrong on a large number of devices was a close second.

The complaining I doing here is more about the administrative aspect of making a mobile game. Jumping through all the hoops presented by the platform-holders. (Some of which are hard requirements, like this IAP Restore button. While others are "soft" requirements which, while not technically required, will hurt your game if not addressed.)

@Keker228, they should release simultaneously, since I can directly control launching on iOS.

That's actually one of the cases where Apple beats Google. On Apple, I can choose "manually launch" so that, when the app is approved, it doesn't appear on the store until I okay it.

Google, unfortunately, has no such option (for the initial release, anyway). I submit it for review at Google, and when they approve it (2-? hours later), the game immediately appears on the store.

So I had to submit to Apple first, wait for them to approve, and once they do, submit to Google. And once I get it approved on Google, I can manually launch the Apple version to be (near) simultaneous.