Just out of curiosity, are you using any technologies that would ask for the users privacy permission? Location, Microphone, Camera, Photos, Touch or FaceID, etc? If so, have you included the relevant plist entries?
Also, in your crash log, theres usually one or two lines of info between the header and thread stack that you posted. If there is, could you post that?
[quote=492703:@Olivier Colard]The app.UnhandledException event is implemented with Return False
Is it bad practice to ‘Return True’ in app.UnhandledException event ?[/quote]
I wouldn’t say there is good or bad practice to return True in UnhandledException event.
But returning False will let the app crash whenever there is an exception. Returning True prevents that but the app may become unresponsive or not behave as expected.
In my apps, the UnhandledException event logs the error in an online database and sends me an email directly. Then it returns True to let the app continue.
From what I read in the crash log, the exception seems to be in App.Open event.
A couple of times, after receiving such reason (crash at start) for rejection, I just resubmitted a new binary (with increased “Non release version”); and the crash did not happen anymore.
I guess something had gone wrong during the uploading process.
Edited: I just resubmitted the same binary with increased…; obviously a binary with increased number is no more “the same”.
[quote=492759:@Jeremie Leroy]In my apps, the UnhandledException event logs the error in an online database and sends me an email directly. Then it returns True to let the app continue.
From what I read in the crash log, the exception seems to be in App.Open event.[/quote]
Im storing the info in a log file and the user can send it thru the contact form. Useless if the apps doesnt even start.
Ill send a mail directly in UnhandledException.
Ill also double check the Open event.
Also, FYI, Il using the ImprovediOSApplication class to handle DidBecomeActive & WillResignActive events. Ill check that again.
I still haven’t solve this. Same problem. Runs on all physical devices and simulators. Crashes at startup with reviewers.
They don’t want to tell which devices, physical or simulator they are using.
I don’t have more time to lose now, maybe later this year.
First the device type is shown in the crash report.
Second, what you need to do is set yourself up as a beta tester in TestFlight and then test the .ipa file that comes from the store. I found my crash doing this.
The problem is that I had a file that I copied over to the Resources folder and was using Xojo.io.GetResource to access. This works fine with the .app files that you use when you install the app using Xcode. But it does NOT work with the .ipa files. It’s yet another significant bug in the Xojo iOS framework. I’ll be filing a bug report once I get my app released.
But yeah, test with TestFlight. I am sure you will find the problem.
Hi @Jon_Ogden I think I am having the same issue. All is working fine on test devices and simulator but rejected 3 times from the store. I too am loading text files from CopyFiles in Resources. Did you find a solution?
Yes. Set yourself up in TestFlight so you are actually loading/running the IPA. It is likely a file signing issue or something like that. Once I was able to duplicate the crash it was an easy fix. Don’t assume that the .app file generated and copied to your device in XCode works the same way as the install of the IPa from the store or TestFlight.
I believe it was a signing issue. The copy was happening after the signing step in the build process. This doesn’t affect things when copying the .app file in Xcode but it does matter when using the IPA installed by TestFlight or the AppStore.
Yes, it was definitely a signing issue. I just had a chance to go back and look at the code. I still use Xojo.IO.SpecialFolder.GetResource. What had to be changed was that the build step of the file copy to the resource folder HAS to take place BEFORE the signing step of the build process. Otherwise the file is not signed and iOS pukes.