Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

testflight application closes on start

I'm trying to install an ad-hoc application through testflight, so I create an ad-hoc provisioning from apple portal, I build the .ipa and then I submit it to testflight.

The problem is that I can install the application from testflight (I don't receive any errors), but when it starts the application it close without any alert or messages.

After some test, I've attached device to xcode and then I clicked on 'Configure for development' (or something like this, I don't remember correctly because I can't see again that option). After that, application didn't close on startup and it works well.

The problem is that I can't distribute application via testflight if I have to enable development with xcode for any device!

Why I have this behaviour? I'm doing something wrong?

Thank you

like image 227
Daniele Bottillo Avatar asked Nov 03 '22 22:11

Daniele Bottillo


1 Answers

If you could install the application from TestFlight without errors then your device was correctly listed in the provisioning profile. Your problem is something else.

Try looking at the crash logs from a device to see what went wrong. you can extract them and symbolicate them in Xcode.

A correction to MusiGenesis answer: It is certainly not normal for ad-hoc builds not to work with push notifications! You just have to set up and use the system correctly.

Common sources of errors when your ad-hoc builds are not receiving push notifications:

  • You did not generate a new provisioning profile after enabling push for your app. This causes the received push token to be nil.
  • You are using development certificates to connect to the APNS servers. Ad hoc builds are considered distribution builds, so you must use your production keys.
  • You are sending a mix of development tokens (from dev builds) and production tokens (from ad hoc builds) to the APNS service. This causes the whole batch of push notifications to be silently discarded by the server. Keep your development, adhoc and production token databases totally separate to avoid this. There is no way to identify which tokens are poisoning your batch, so you have to clear them all out and make sure only the right type of token is inserted.

I always keep 3 backend instances running for an app which needs to register for push. One for development builds, one for ad-hoc builds and one for App Store builds. For example you could keep separate API endpoints online at dev.mybackend.com, staging.mybackend.com and production.mybackend.com backed by different database instances to isolate them.

In the Xcode project I then have separate build configurations for these types of builds and swap the correct backend in using preprocessor macros. Separate build configurations are also handy if you want to make sure your dev builds are not reporting wrong analytics to the production account, that the correct provisioning profiles are automatically used etc. etc.

like image 133
Heiberg Avatar answered Nov 10 '22 03:11

Heiberg