EDIT: Thanks to Ashley and the Ejecta team the issue is now resolved. You may want to skip most thread and go directly to the beautiful memory graph at the bottom of page 3.
In the last few months I've been working on a pretty big pre-ordered mobile app for toddlers. The app contains ten different games and three lobby screens (for navigation between games).
This http://www.malanapps.com/klalit/ is the app at its current state. So far there are only two screens implemented for each game, but on the final app I'm supposed to have ten screens for each game.
It took tons of reading and consulting (THNX MUCH jayderyu !!!) to optimize the app so it is now running perfectly on android devices. Optimization focused mostly on merging graphics into combined sprites and down-scaling the entire app from 2048 to 1028. IntelXDK was used to create the apk for android.
Since the Ejecta path to iOS was under extensive development recently, I've waited with testing and building for iOS until memory management issue will be declared as resolved.
And it was... So I moved on... But from the moment I started dealing with iOS, this project has become a nightmare I made more than 30 ipa builds of different sections of the app. When installing the ipa's on my iPad Mini I keep getting frequent crashes, some of them on inconsistent basis. My largest layout is less than 60Mb, so layout size is not the reason for crashing.
* C2 r168 (64-bit)
* Ashley 's Ejecta template (https://github.com/AshleyScirra/C2Ejecta
* Xcode 5.1.1 via MacInCloud (no direct iOS Device debugging )
* ipa installed on iPad Mini iOS7 and running on WebGL
Export and build procedure:
1. C2 > Export to Ejecta
2. On Xcode > rename project (with auto rename for elements), rename bundle; ans set orientation (on info.plist)
3. On most versions the app worked on the iOSsimulator perfectly. While launching the simulator Xcode suggested me to approve some automatic adjustments on the architectures and I did so.
4. Archive as AdHock > ipa
When I stated testing the app, not even one game was functional on the iPad. I broke down the app into “clean” separate games, excluding navigation and most audio, and started to fight them one by one… After quite a lot of work few games are functional and some more games are functional but crash at end animation or at feedback animation (boy with res shirt popping in).
Current status of the different games can be viewed here https://docs.google.com/spreadsheets/d/1bo6YoPjmHqvfamxPKTr7352WDY0Kdi4dvM9qoL4T2Ig/edit#gid=0 I will keep this report up-to-date as I go along.
While I believe it would only take precise optimization and debugging to get each of the games working, I have a strong doubt if the entire app is going to run on iOS. And this why:
I wanted to exclude the possibility that the crashes are caused by a bug or a memory leak in the logical mechanism of the games. So I created this https://www.dropbox.com/s/klqdp4abc7006du/AllNoEvents_W_Transition.capx version. All game logic was removed, only layouts, assets and navigation event sheet are there. On top I added a “clear transition” – an empty layout including only a text object saying “clear”. This layout is loaded upon any change of layout, pauses for a short while and after it continues to the next layout. I was suggested that such transition layout will help to get a good view of mem management.
Upon testing, some of the layouts load alright and some of them cause the app to crash. But this is not the issue. The issue is that layouts that do load when accessed at app start, crashes later, after some other layouts have been loaded. To the best of my understanding this is a memory management issue.
As my deadline is coming in few weeks this has became a MAKE IT OR BREAK IT SITUATION. Ashley – I hope you can take a look into this problem. I’m really hurting here; spending endless hours and not really sure if thisproject can be finalized and handed to my client using Construct2 .
If you (or anyone else) would like to review the capx file of the entire app I will be happy to share it by PM.