.app does not have an executable path after instal

问题:

I have a TestFlight build that one user has downloaded, then we released a new version and they installed over that build. They got this error when trying to launch the app:

Wed Aug 31 20:13:28 unknown SpringBoard[1176] : The 'X' bundle at /private/var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/X.app does not have an executable path. Please check the bundle's Info.plist file.

I checked the app's plist using PhoneDisk and the executable matched the app name. Any ideas?

回答1:

In my case, I wasn't updating the CFBundleShortVersionString between the versions I was trying to download. Once I updated the version from 1.1.9.1 to 1.1.9.2 and re-downloaded the adhoc build, it stopped crashing.

I'd guess Apple is caching some of the information in the Info.plist for adhoc builds, and bumping just the CFBundleVersion isn't enough to blow the cache.

回答2:

From "Core Foundation Keys": "CFBundleShortVersionString (String - iOS, Mac OS X) specifies the release version number of the bundle, which identifies a released iteration of the application. The release version number is a string comprised of three period-separated integers. The first integer represents major revisions to the application, such as revisions that implement new features or major changes. The second integer denotes revisions that implement less prominent features. The third integer represents maintenance releases. The value for this key differs from the value for “CFBundleVersion,” which identifies an iteration (released or unreleased) of the application. This key can be localized by including it in your InfoPlist.strings files."

CFBundleShortVersionString also mustn't contain any letters, only integers are allowed. So if you have something like 1.2.5b1 the app won't start, strangely with an error like "...does not have an executable path...".

回答3:

I encountered this particular error in a case where our normal app version were n.n.n and in the update we went to an app version that was n.n.n.n

We didn't have time to delve into it deeply but simply moving back to the original number scheme resolved the issue.

回答4:

You should specify two keys (CFBundleVersion & CFBundleShortVersionString) in Info.plist.

CFBundleVersion (String - iOS, OS X) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle. The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero. The string should only contain numeric (0-9) and period (.) characters. Leading zeros are truncated from each integer and will be ignored (that is, 1.02.3 is equivalent to 1.2.3). This key is not localizable.

CFBundleShortVersionString specifies the release version number of the bundle, which identifies a released iteration of the app.

You can add the CFBundleVersion by 1 every time when you build an adhoc version for your test or user with the same release version(CFBundleShortVersionString)

For example : your CFBundleShortVersionString is 1.2.3, your CFBundleVersion is 1000. when you fix a bug and build an adhoc version for testing, you can change CFBundleShortVersionString to 1001.