App dies on startup but not crash report

Question

I\'ve given an ad hoc version of my app to some users. Two of them have the app die on start up while one user has no issues. I can also install the ad hoc without issue...but

Answer 1

Ad-hoc distribution is notoriously tricky. If you've missed one thing, the whole chain fails. Here's what I can think of, off the top of my head, based on the fact that it works for at least one of your users:

1. Are you certain that the mobile ad-hoc provisioning certificate contains the UDID for the users who are seeing it fail?
2. Do those users have an old certificate on their device? (i.e. did you delete the existing certificate before installing a new one? Settings->General->Profiles)
3. Are you certain the code-signed .app bundle contains the UDIDs for those users, inside the file named embedded.mobileprovisioning? (Under the ProvisionedDevices key)
4. Is the mobile provisioning certificate expired?
5. Is your developer code-sign certificate expired?
6. Was the application package renamed by the user before installation?
7. Did you try doing a clean before doing the distribution build?

Answer 2

The key word I think you have used is the word 'dropbox'. I've just spent the last 2 weeks trying to work out my app would not work on other machines and I have worked out that is because I have been distributing the app via DropBox with out zipping it.

Try putting the app in a zip file before uploading to DropBox. Instruct the users to download the zip file, unzip it and install the app.

My guess is that DropBox is stuffing up some of the files in the app package.

Answer 3

Try using the iPhone Configuration Utility, a free download from Apple. I had the same problem, uninstalled and installed using the iPCU and now it works perfectly.

It's somewhat unintuitive to use, try googling for provisioning profile iCPU. I found detailed instructions on a "redfin's developper blog".

Answer 4

Sun Dec 13 12:35:04 unknown SpringBoard[24] : Failed to spawn myapp. Unable to obtain a task name port right for pid 179: (os/kern) failure

I've been fighting this for some time, and in my case it was a result of our build system using a different zip routine which did not respect OSX's resource forks. I don't know much about them, but in short they are an HFS construct for storing extra metadata about a file/dir which is hidden from most tools. Compressing with finder seems to work, as well as ditto. More info here: http://xahlee.org/UnixResource_dir/macosx.html

Answer 5

Ensure the executable has the same name in the updated version. I found if these don't match up, I get the exact same error messages as the asker. This is defined in the info.plist.

My team was trying to simulate the user upgrading an old version of our app to a new one. The new version was very different and we'd created a whole new project with new target and everything. Unfortunately this changed the executable name. Changing this back to the original made the upgrade work perfectly.

Answer 6

Dropbox for me as well, zipped and it worked fine.