iOS How to avoid publishing broken iOS builds?

[Toxic Tom]

I have hit upon a very serious issue in my iOS deployment workflow with GMS2.

Normally I would test the app on an iPhone using the play button (built using the VM), then when I'm happy everything is working as expected, I would clean the build folder (using the brush icon), switch to the YYC compiler, then click Build > Create Executable. The Xcode deployment wizard then signs the app and sends it to Apple for review (using App Store Connect).

Last time I pushed an update for my iOS app, I followed that routine, and once the new version was accepted by Apple, I downloaded it from the App Store to test it on my device. I was very disappointed to see that the app crashed immediately due to a dodgy build:



The build is also crashing for all of my users. I would like to reiterate that there are no errors in the code, as the app is running just fine on the test device when testing in GMS2. There was clearly some problem during compilation that has broken the build.

Once I realised the problem I pushed a fix immediately, which is still waiting for review from Apple. In the meantime my iOS users are completely unable to use the app! This is clearly unacceptable for my users.

So my question is - how can I avoid this pitfall? When building for Android I always first build a .apk file, then immediately build a .aab file so that I can test the .apk on my device, and upload the .aab to Google Play. This seems to work well and I have never experienced an issue with the .aab build that was not present in the .apk build, so I have much more confidence in pushing updates for Android. Is there any way to use a similar workflow when publishing for iOS? That is, some way to test the actual application package that is being sent to App Store Connect. It seems to me that this feature should exist.

Thanks for any suggestions you guys may have!

 

[FrostyCat]

You avoid this pitfall by testing the YYC build after you make it, and recognizing what REALLY happens matters more than what SHOULD happen. Or just release on VM.

The VM and YYC exports have completely different underlying architectures, and it's not unusual for things to run fine in VM but not in YYC. Ideally both should handle the same way except for compiled speed, but in reality they will always be different in minute ways. In particular, YYC is much stricter with scope and type casting than VM. If you've only tested with VM, then you should only ever release with VM.

 

[Toxic Tom]

You avoid this pitfall by testing the YYC build after you make it, and recognizing what REALLY happens matters more than what SHOULD happen. Or just release on VM.

The VM and YYC exports have completely different underlying architectures, and it's not unusual for things to run fine in VM but not in YYC. Ideally both should handle the same way except for compiled speed, but in reality they will always be different in minute ways. In particular, YYC is much stricter with scope and type casting than VM. If you've only tested with VM, then you should only ever release with VM.

So are you saying that if I test on an iPhone using the "play" button, using YYC, and everything runs OK, then click Build > Create Executable, that the resultant application package will definitely also run OK? Should I be clearing the build folder between these stages or not?

 

[FrostyCat]

Take out the cache first, then switch to YYC and click play. Then do an exit test of that. Once you've confirmed that, then you can go ahead with building the final product. The problem you had looks like a case of YYC being stricter than VM on some line in your project, not a case of stale cached content.

Alternatively, there's nothing wrong with releasing straight on VM if that's where all your previous testing efforts have gone into. You sacrifice a little performance for assurance that it's the exact same architecture you originally tested with.

 

[Toxic Tom]

Take out the cache first, then switch to YYC and click play. Then do an exit test of that. Once you've confirmed that, then you can go ahead with building the final product. The problem you had looks like a case of YYC being stricter than VM on some line in your project, not a case of stale cached content.

Alternatively, there's nothing wrong with releasing straight on VM if that's where all your previous testing efforts have gone into. You sacrifice a little performance for assurance that it's the exact same architecture you originally tested with.

OK so I will try this method next time:

1. Clean build folder
2. Test using YYC
3. Create executable

As for the specific exception that occurred in the screenshot, I don't think it is to do with "strictness" but it seems the object (or room?) identifiers got muddled, as there should never be a backgroundDisplayer_furnace or a Obj_WebView in the first room of my game! So either the wrong objects got instantiated, or the wrong room was loaded on startup. I see similar issues with resources getting muddled at least 10 times a day when I am developing for Android & iOS, for example objects drawing the wrong sprites, or the wrong sound effects playing. Fortunately this is usually fixed by cleaning the build folder, although I would be very happy to see this issue resolved by YoYoGames!