provisioning profile hell

Question

once in a while I run across a problem with provisioning a device with a dev version of an app . The error message is usually "a valid provisioning profile for this executable was not found".

I have followed all the Apple instructions: I have a valid dev certificate, the developer provisioning profile includes the device ID of the device in question, codesigning works during build. I have the signing identity set for my developer identity, which Xcode matches up with the development provisioning profile just like it should.

Then, when I try to install the app on the device by doing a 'build/run' in xcode, I get the error described above, and I'm at a total loss. It works just fine on any number of other devices, but for some reason, there are a few devices for which this process bombs.

Here's the console log for the failed install on the device:

Sat Sep 18 11:41:14 unknown SpringBoard[27] <Warning>: Reloading and rendering all application icons.
Sat Sep 18 11:41:36 unknown installd[820] <Error>: 00503000 verify_signer_identity: Could not copy validate signature: -402620395
Sat Sep 18 11:41:36 unknown installd[820] <Error>: 00503000 preflight_application_install: Could not verify executable at /var/tmp/install_staging.pJ8ST8/MyApp.app
Sat Sep 18 11:41:36 unknown installd[820] <Error>: 00503000 install_application: Could not preflight application install
Sat Sep 18 11:41:36 unknown mobile_installation_proxy[855] <Error>: handle_install: Installation failed
Sat Sep 18 11:41:36 unknown installd[820] <Error>: 00503000 handle_install: API failed
Sat Sep 18 11:41:36 unknown installd[820] <Error>: 00503000 send_message: failed to send mach message of 64 bytes: 10000003
Sat Sep 18 11:41:36 unknown installd[820] <Error>: 00503000 send_error: Could not send error response to client
Sat Sep 18 11:42:32 unknown MobileMail[809] <Warning>: SecItemCopyMatching result: -25300
Sat Sep 18 11:42:37 unknown MobileMail[809] <Warning>: SecItemCopyMatching result: -25300
Sat Sep 18 11:43:32 unknown CommCenter[31] <Notice>: com.apple.persistentconnection[MobileMail,809] is releasing its assertion on PDP context 0.
Sat Sep 18 11:44:53 unknown installd[866] <Error>: 00503000 verify_signer_identity: Could not copy validate signature: -402620395
Sat Sep 18 11:44:53 unknown installd[866] <Error>: 00503000 preflight_application_install: Could not verify executable at /var/tmp/install_staging.cgJjHu/MyApp.app
Sat Sep 18 11:44:53 unknown installd[866] <Error>: 00503000 install_application: Could not preflight application install
Sat Sep 18 11:44:53 unknown mobile_installation_proxy[867] <Error>: handle_install: Installation failed
Sat Sep 18 11:44:53 unknown installd[866] <Error>: 00503000 handle_install: API failed
Sat Sep 18 11:44:53 unknown installd[866] <Error>: 00503000 send_message: failed to send mach message of 64 bytes: 10000003
Sat Sep 18 11:44:53 unknown installd[866] <Error>: 00503000 send_error: Could not send error response to client

Solution

Team and I ran into same issue as you. It work fine with many device except the customer iPod. We try to create everything from scratch. App ID, Provision, Build. No Luck.

So, after review great article at http://boga.wordpress.com/2008/07/16/debugging-ipod-provision-profilescertificates/

so, I use the Organize to sync provision with iTunes Connect site. then check provision file with TextEdit (Vim).

this line should be appear. After that my deploy with Adhoc success.

<key>Entitlements</key>
    <dict>
        <key>application-identifier</key>
        <string>H33HFFQMS8.icpsstock</string>
        <key>get-task-allow</key>
        <false/>
        <key>keychain-access-groups</key>
        <array>
            <string>H33HFFQMS8.*</string>
        </array>
    </dict>

Hope this help, my configuration looks like this.

1. Target iOS 3.1.3
2. Base SDK 4.2
3. LLVM GCC 4.2 Build
4. get-task-allow in Entitlement.plist must be false
5. Sync Organizer's provision with iTunes Connect

Comments

[Evan Nagle]

Ultimately, we never got this to work at my client's site, and I've since moved on (so we'll probably never actually resolve the issue), but this is the best answer, so you get the green check ;-)