Where’s Auro for iOS?!

Back in September, we launched Auro! Only, there was a minor problem with the iOS version. Turns out that that minor problem was – as far as we can tell – a huge problem, one that we’ve been dealing with ever since.

Broadly, here’s the issue: since iOS 8.0 came out, we’ve had trouble getting the game to work *and* be accepted by Apple for submission. We’ve more or less been stonewalled over and over in our attempts to fix the problem, and so now we’re coming to the community for help.

For more technical details – or to just support us in the hopes of finding a solution, please click on these links and upvote!

On  /r/iOSProgramming)

On stackoverflow

On Google Groups

OpenFL Community

We’re hoping that someone will be able to give us a reasonable solution. We really, really don’t want to have to port the game from scratch to something else, and it seems like that shouldn’t be necessary.

Once we have this ironed out and we can get the game out, we can get back to making the game better and better. It really, really sucks to not have the game out yet on iOS, where the vast majority of our fans are likely to be. We thank you for your patience!

Thanks everyone,

– Dinofarm Games


Here’s the full text of Oren’s post.

So, I inherited a game project with the following setup:

*A core SWF of the game itself, written in Haxe (3.0)/NME (4.0.2), utilizing the Starling framework, compiled to a Flash target using FlashDevelop

*An AS3 wrapper which deals with assorted device communication needs (e.g. detecting device capabilities, managing phone lock state and pausing game/muting music, etc). This is compiled into own SWF (AIR 3.6), which is what is actually launched, and subsequently loads the “core” SWF and adds it the stage.

*This AS3 SWF is subsequently packaged into the target formats (APK/IPA) using ADT (also AIR 3.6), along with its assets (including the core SWF).

Despite the odd complexity, the whole thing worked just fine; we created functional, usable apps that a)worked on both Android and iOS devices, and b) passed submission criteria.

Flash forward several months; the game has now passed beta and is ready for initial release. Android, everything goes fine. iOS, the other hand… Just days before we attempted to upload 1.0 to iTunes Connect, Apple changed their requirements. Suddenly, we were getting the error “Apps and app updates submitted to the App Store must be built with the public (GM) versions of Xcode 5.1.1 or later, and iOS 7 SDK or later. Don’t submit apps built with beta software.” Fine, an error that tripped up many a developer back in September. Eventually Adobe released AIR 15, and packaged IPAs once again met Apple’s submission requirements.

Unfortunately, updating to AIR 15 upset the applecart. We were now able to upload the IPA, but, ironically, it would not work on iOS devices. The loading screen (generated by the pure AS3 “wrapper” SWF) comes up, but then when the title screen (generated by the “core” SWF) should be appearing, there’s nothing. Black screen, no activity, or alternatively (on some later attempts), instant, message-less app disappearance). No errors generated on the iOS console, nothing untoward happening when stepping through the app in FDB (right up until the app evaporates and FDB loses its connection to the remote host).

Other salient information:

I have tried updating literally every component involved in the process, assorted updates of AIR 15, and 16 beta. All of the listed haxelibs. We’ve even tried porting the “core” project (in the most cursory of manners) to OpenFL. All of these have resulted in versions that work on Windows (desktop, not phone), work on Android, but do not work on iOS.

Haxelib libraries: Original:

actuate: 1.6.4 [1.6.5]

air3: [0.0.1]

haxelib_client: [3.1.0-rc.3]

hxcpp: [3.0.2]

nme: [4.0.2]

openfl: [1.0.6]

openfl-tools: [1.0.10] 1.0.8

starling: [1.2.2]

swf: [1.0.2]

Extra tasty crashy:

actuate: 1.7.0 [1.7.5]

air3: [0.0.1]

haxelib_client: 3.1.0-rc.3 [3.1.0-rc.4]

hxcpp: 3.0.2 [3.1.39]

hxcs: [3.1.1]

lime: [2.0.0-alpha.4]

nme: [4.0.2] 5.1.8

openfl-compatibility: [1.0.1]

openfl-html5: [1.4.2-beta]

openfl-native: [1.4.0]

openfl-tools: [1.0.10]

openfl: 1.1.1 2.0.1 [2.1.2]

starling: [1.2.2]

swf: 1.0.2 [1.5.2]

tl;dr: Old version of AIR app works on iOS but can’t be submitted to iTunes. New version can be submitted, but does not work on iOS (resulting in either a frozen black screen or a crash)

Any help whatsoever– suggestions of what the problem might be, other ways we might be able to figure out the problem, or even ways to get the working app through the submission blockage (e.g. re-signing)– would be greatly appreciated. Having to rework the entire game in some other framework, etc, is an extremely untenable solution at this time. This is basically a life or death situation for a very promising indie game dev company. ( x-posted to (StackOverflow)[http://stackoverflow.com/questions/27916075/haxe-nme-game-failing-on-ios-devices-after-air-version-updated] )


keithburgun • 01/13/2015

Previous Post

Next Post


  1. Tapnik 01/14/2015 - 8:31 pm Reply

    I don’t know much about the AIR toolchain, can you break down what AIR is doing to generate the IPA? Can you generate a simulator build? Does that fail?

    If you can get a debug build (or even if a release build), you can run Xcode, and go into “Debug” -> Attach to process (By Process Identifier), and maybe get some idea of what happened. Even if you can only see the disassembly, it might give you some clues. Also, use the XCode “Devices” window to view the device log and see if it gives you a crashlog or prints out something like an assert message.

    Also, try building a hello world style minimal project, does that fail? Add/remove bits until you narrow down which component is causing trouble.

    Good luck!

  2. Liam 01/28/2015 - 10:13 pm Reply

    What was the resolution for this problem, in the end?

    • keithburgun 01/28/2015 - 10:34 pm Reply

      It’s kind of a long story. The short version is, we had an AS3 wrapper and we were injecting our SWF into it, which is what Apple was objecting to. Ultimately we were just like, “hey, do we… actually even need this AS3 jazz?” and found that the answer was no. In fact, the app is way better and faster without it. I’m gonna have our programmer Oren write a thing about it at some point.

  3. ‘100 Rogues’ Creator’s ‘Auro’ Finally Bumps on Over to iOS from Android | TechGump
  4. '100 Rogues' Creator's 'Auro' Finally Bumps on Over to iOS from Android – Games Reviews Updates
  5. ’100 Rogues’ Creator’s ‘Auro’ Finally Bumps on Over to iOS from Android | App Review Daddy
  6. '100 Rogues' Creator's 'Auro' Finally Bumps on Over to iOS from Android
  7. Mark DeNardo 02/28/2019 - 11:28 am Reply

    Will Auro ever return to iOS???

  8. keithburgun 02/28/2019 - 9:05 pm Reply

    Because Auro was built in Haxe NME using Flash as its graphics framework, pretty much everything about it is no longer supported. So unfortunately I feel like probably the answer is no. BUT! There is good news. We are making a spiritual sequel to Auro right now called Alakaram which is very very similar, but with a ton of improvements, and that will almost certainly be coming to iOS.

Leave a Reply

Your email address will not be published / Required fields are marked *