SeattleBus Diary: ongoing update saga

I’d really hoped to be able to post that I’ve got the updates for SeattleBus into Apple and they’re pending review. Alas, right now, I can’t. It’s quite the saga of things I’ve tried – lists I’ve following and checked off, line by line, from the instructions. I’m not sure where I’m going wrong, but the AppStore back end isn’t currently accepting my signed applications.

I finally opened a ticket with Developer Technical Support today – I’ve got two from my “Select” membership, so I might as well use one. I usually don’t use them – it’s as good a place as any, and I could really use the help right now. DTS reports that it is usually a couple of days for a response, so assuming everything goes swimmingly from this point forward – it’ll still likely be the middle of next week before I get something signed that the AppStore will accept. Anecdotally, I’ve heard DTS is even more backed up than usual – so we’ll just have to see.

The worst part about all this is I’m not sure how to even diagnose what’s going wrong. The AppStore wants a signed bundle – everything I can see in the logs shows that it’s getting signed. (A digital signature – not my handwriting. Everything in this set up uses digital signatures for verifying all sorts of bits about the code). I’ve become significantly more comfortable with Apple’s code signing program, learning the command line bits just to understand what’s happening. It all looks good – but when I upload it, I get the error

The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.

It’s a fine error message, except as far as I can tell all the diagnostics need to happen on the receiving end of this process – where I can’t see anything.

I wasn’t sure if something got suckered up in the databases or such, so I even went to the trouble of removing all the current keys, certificates, provisioning profiles, and what-not – recreating them all from scratch and setting up my entire environment again. That was a pain and in the end it didn’t do the trick. At this point I’m stepping away for a little bit. I think it might be best if I wait for someone from DTS to get involved to help me with this, because I’m sure not making progress on my own.

5 thoughts on “SeattleBus Diary: ongoing update saga

  1. Did you get anywhere with this?

    I’m in the *exact* same situation… every detail of yours is the same as mine.

    So… ever figure it out?

    -hampton.

    Like

  2. Hey Hampton –

    Yeah, I got past this. It was incredibly frustrating because that error is so damn vague. For me, the solution was found in target specific build settings that was using an invalid distribution profile. Once I reset all those, it worked properly. I wrote about it briefly at http://www.rhonabwy.com/wp/2008/07/22/seattlebus-diary-update-is-pending-review/.

    The fundamental problem was that a file called “mobileprovision.embedded” wasn’t being included in the resulting distribution package, and without it the upload will always fail. Get your build working to generate that file (in my case, it was a broken distribution profile link) and it’ll work like a champ.

    Like

  3. Greetings to all:

    I had this problem also (mobile provision not found when viewing package contents via finder right click – it should appear as “embedded.mobileProvision” among the images in alpha sort) – I keep my keys on a frozen volume (using Deep Freeze) so it could hardly be a key problem (reloading the app store mobile provision was no help). The fix for this (that worked for me) is as follows:

    Navigate to xCode->Project->Edit Project Settings. Under “General” tab, on the bottom use button “Rebuild Code Sense Index”
    Clean, and build. Result has the mobile provision and the upload was successful! I have no Idea why this occurred. I do maintain a separate boot volume for development (under a separate developer identity) and move graphics and source files, but never mess with the project settings for the identity, keys, certificates, or volume, so this must have been one of those “gremlins” that did it.

    – Leonard

    Like

  4. Hello again:

    I am having the missing mobile provision again. I am preparing a “lite” version of the product with a new name. I copied the complete release 1.0.1 folder and renamed it, renamed the project, set the Active SDK to device, clean, build, got CodeSign request, and checked the product – embedded.mobile povision was present.

    Change the bundle id to new product name, new bundle version. Edit target to change the product name, clean and build, Provision missing.

    Tried the Rebuild Code Sense Index – did not fix.

    Restored only the original product name, clean and build – Provisioning OK. Retried new name, provisioning missing. Note that the bundle ID still has the new product name and new versioning numbers are still present in the info.plist.

    It appears that the product name needs to be changed somewhere else. Note that I am using a wildcard certificate, so nothing new to obtain from the portal.

    Joe: on your writeup elsewhere – “I finally had someone pressure me to review the final builds steps in all configurations, where I found the offending critter and removing that config from XCode.” – can you provide some details as this appears to be my problem precisely.

    Thanks for your help.

    – Leonard

    Like

  5. I’m getting my binary rejected for the 42nd time. I too have generated scads of certificates. *HOWEVER* embedded.mobileProvision is there in the bundle. XCode 3.1.2 (iPhone 2.2.1 sdk).. any other ideas?

    Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s