I am trying to create a new release for our iPad app. The build runs fine in the simulator and even when I run a live build. When I compile it to an .IPA and transfer it to an iPad via xcode it installs fine but when I launch it via the icon on the ipad, it displays the launch screen then closes immediately.
I am not getting any crash log on the iPad.
Any advice as to how to troubleshoot this problem further or anyone have similar problems?
So as it turns out the messages sent to the Corona system event listener have changed.
Runtime:addEventListener( “system”, handleSystemEvent )
On launch the application now receives the messages as follows
applicationStart
applicationStart
applicationSuspend
applicationResume
This has changed from
Why was this an issue for our app?
Historically our app has never supported suspend. We are maintaining
a lot of time delayed call backs that manage communications to multiple devices on the network,
these are cancelled on suspend by Corona and not restarted automatically on resume. Instead of
spending the time to implement code to manage the timers we used an os.exit() command on “applicationSuspend” event to force the application to close.
Another thing to note that for some reason the applicationSuspend was not fired in the simulator
and was also not fired when running in live build mode.
Resolution
After removing the os.exit command the application now starts up correctly on a development build.
We are testing what the side effects will be for all of our timers that may not have gotten started and I think we will now be incurring the development cost for those efforts.
I
There is no such thing as os.exit. I think you mean native.requestExit which is only supported on Android and certainly not on iOS. More info here - https://docs.coronalabs.com/api/library/os/exit.html
“__Historically our app has never supported suspend” - well obviously apps do not suspend themselves but the OS does and it should absolutely be accounted for. Phone rings whilst playing… this is mobile app development 101.
_"_After removing the os.exit command the application now starts up correctly" - why would ever have an unsupported hard exit command on start up?
Absolutely timers that are stopped on applicationSuspend are restarted properly on applicationResume in both simulator and devices. My game has hundreds of timers that perfectly respect this schema.
Thank you for the reply.
IMO, It’s helpful when someone challenges the assumptions that you are making because you can possibly get
a better perspective.
To summarize / paraphrase your concerns as I understand them:
This application was developed back in 2011 for iPad. The documentation, apis and behaviors have changed since then.
I do not believe that os.exit had much of a description back when it was used. Admittedly, I have not been
following all of these changes, and basically only start reviewing them when I need to make an update to
the app so it is quite easy for me to miss something.
The decision to exit on suspend was driven by the fact that at the time in 2011, delayed callbacks were not being restarted
properly following an application suspend and we did not discover this until near release. Our application is not a game. It syncs data simultaneously to a dynamic number of hardware devices on a network. The syncing process is fairly complex as it involves negotiating with external software using multiple time sensitive delays. Interruptions by the application suspend routing required a resequencing of scheduled callbacks. The decision to add the os.exit command was to get the application out the door and working instead of building another software component to manage the restarting of timers. We knew it was not the ideal approach but it worked, until the latest update.
I could put together an example app showing that os.exit does indeed still force the iOS app to exit, but there really isn’t much point as the api now clearly states that using os.exit is not supported. So no one should be using it anyway.
One thing I find peculiar is that the application gets sent a suspend and resume event when you first launch it. Why would Apple suspend your app on launch, then resume? that doesn’t really make any sense to me.
I have lots of investigation to do still. The application no longer functions properly now that it resumed from a suspended state.
You could try pausing your timers on suspend and then restarting them on resume? Or some form of temporary state saving that you can resume when the app comes out of suspension?
Apple can reject apps that self-close but don’t quote me on that one. AFAIK they ONLY want the home button to close an app - even then that normally just suspends it anyway.
I haven’t ever seen suspend event on an app start unless the app shells out to another app for authentication - for example to request a Facebook SSO. Maybe it is a plugin you are using?
Strangely, my app does not use any plugins or libraries other than the stock lua socket and bit libraries that come with the Corona.
So far the only proofing I have done was inside the app I added a few lines of code to track all of the system messages sent to the app. Then after the app starts, I use an native alert box to print a string of all of the messages received.
What was interesting is that in the simulator and also using the live build my app reported that only the applicationStart message was received. Then when I compiled it into an .ipa and installed it on the iPad through xcode, it reported that it received 4 messages.
applicationStart
applicationStart
applicationSuspend
applicationResume
This is hardly real proof, I need to separate the code into simple app and prove it out that way too make sure something in my app is not interfering with it like in scenarios you are asking about.
FYI only. if you want to see how os.exit works the code is quite simple:
local function handleSystemEvent(event)
if(event.type==“applicationSuspend”)then
os.exit()
end
end
Runtime:addEventListener( “system”, handleSystemEvent )
that can be compiled and run on an ipad. then compared with the results of the following code
local function handleSystemEvent(event)
if(event.type==“applicationSuspend”)then
os.someMadeUpMethod()
end
end
Runtime:addEventListener( “system”, handleSystemEvent )
Anyway I will post the code / results of my independent test for system messages after they are finished.
So as it turns out the messages sent to the Corona system event listener have changed.
Runtime:addEventListener( “system”, handleSystemEvent )
On launch the application now receives the messages as follows
applicationStart
applicationStart
applicationSuspend
applicationResume
This has changed from
Why was this an issue for our app?
Historically our app has never supported suspend. We are maintaining
a lot of time delayed call backs that manage communications to multiple devices on the network,
these are cancelled on suspend by Corona and not restarted automatically on resume. Instead of
spending the time to implement code to manage the timers we used an os.exit() command on “applicationSuspend” event to force the application to close.
Another thing to note that for some reason the applicationSuspend was not fired in the simulator
and was also not fired when running in live build mode.
Resolution
After removing the os.exit command the application now starts up correctly on a development build.
We are testing what the side effects will be for all of our timers that may not have gotten started and I think we will now be incurring the development cost for those efforts.
I
There is no such thing as os.exit. I think you mean native.requestExit which is only supported on Android and certainly not on iOS. More info here - https://docs.coronalabs.com/api/library/os/exit.html
“__Historically our app has never supported suspend” - well obviously apps do not suspend themselves but the OS does and it should absolutely be accounted for. Phone rings whilst playing… this is mobile app development 101.
_"_After removing the os.exit command the application now starts up correctly" - why would ever have an unsupported hard exit command on start up?
Absolutely timers that are stopped on applicationSuspend are restarted properly on applicationResume in both simulator and devices. My game has hundreds of timers that perfectly respect this schema.
Thank you for the reply.
IMO, It’s helpful when someone challenges the assumptions that you are making because you can possibly get
a better perspective.
To summarize / paraphrase your concerns as I understand them:
This application was developed back in 2011 for iPad. The documentation, apis and behaviors have changed since then.
I do not believe that os.exit had much of a description back when it was used. Admittedly, I have not been
following all of these changes, and basically only start reviewing them when I need to make an update to
the app so it is quite easy for me to miss something.
The decision to exit on suspend was driven by the fact that at the time in 2011, delayed callbacks were not being restarted
properly following an application suspend and we did not discover this until near release. Our application is not a game. It syncs data simultaneously to a dynamic number of hardware devices on a network. The syncing process is fairly complex as it involves negotiating with external software using multiple time sensitive delays. Interruptions by the application suspend routing required a resequencing of scheduled callbacks. The decision to add the os.exit command was to get the application out the door and working instead of building another software component to manage the restarting of timers. We knew it was not the ideal approach but it worked, until the latest update.
I could put together an example app showing that os.exit does indeed still force the iOS app to exit, but there really isn’t much point as the api now clearly states that using os.exit is not supported. So no one should be using it anyway.
One thing I find peculiar is that the application gets sent a suspend and resume event when you first launch it. Why would Apple suspend your app on launch, then resume? that doesn’t really make any sense to me.
I have lots of investigation to do still. The application no longer functions properly now that it resumed from a suspended state.
You could try pausing your timers on suspend and then restarting them on resume? Or some form of temporary state saving that you can resume when the app comes out of suspension?
Apple can reject apps that self-close but don’t quote me on that one. AFAIK they ONLY want the home button to close an app - even then that normally just suspends it anyway.
I haven’t ever seen suspend event on an app start unless the app shells out to another app for authentication - for example to request a Facebook SSO. Maybe it is a plugin you are using?
Strangely, my app does not use any plugins or libraries other than the stock lua socket and bit libraries that come with the Corona.
So far the only proofing I have done was inside the app I added a few lines of code to track all of the system messages sent to the app. Then after the app starts, I use an native alert box to print a string of all of the messages received.
What was interesting is that in the simulator and also using the live build my app reported that only the applicationStart message was received. Then when I compiled it into an .ipa and installed it on the iPad through xcode, it reported that it received 4 messages.
applicationStart
applicationStart
applicationSuspend
applicationResume
This is hardly real proof, I need to separate the code into simple app and prove it out that way too make sure something in my app is not interfering with it like in scenarios you are asking about.
FYI only. if you want to see how os.exit works the code is quite simple:
local function handleSystemEvent(event)
if(event.type==“applicationSuspend”)then
os.exit()
end
end
Runtime:addEventListener( “system”, handleSystemEvent )
that can be compiled and run on an ipad. then compared with the results of the following code
local function handleSystemEvent(event)
if(event.type==“applicationSuspend”)then
os.someMadeUpMethod()
end
end
Runtime:addEventListener( “system”, handleSystemEvent )
Anyway I will post the code / results of my independent test for system messages after they are finished.