Critical Showstopper - Cannot upload Corona build app to the app store

Solar2D General Questions/Discussion
#1

I posted the ITMS-9000 error a while ago to which I did not get any solution. I thought it would have been something to do with me and after 3/4 days of trying everything, I recreated the certificates right from the private/public keys to the .cer and the .mobileprovision files almost like a new install.

Then after building the executable, which passed the test earlier and even now after a couple of minutes with the app store came back with the same ITMS-9000 error.

The bundle <bundle> at bundle path <application.app> is not signed using an Apple submission Certificate

My system and applications are as follows

MAC OSX 10.9.2

xCode 5.1.1 (5B1008)

CoronaSDK 2014.2189 (2014.3.6) with the xcode 5.1 fix

Which as I can see here (https://developer.coronalabs.com/downloads/corona-sdk) is the latest public build

I was a pro-subscriber and now that the client wants an update and my subscription has ended I am left in the lurch unable to upload the changes the client requested. While you might want to focus on your paying clients, you cannot simply break the builds for older clients that had supported Corona.

I am sure that if I create a dummy xcode executable and try to upload it to the app store with this certificate, it will work. So the issue is somewhere with the workflow of Corona builds.

Could you please issue a fix as soon as possible, don’t want your new features just want that what I had works.

#2

I’m sorry you’re having troubles 007, I would suggest dropping back to the last build that worked for you, except that Apple has changed the requirements so our public build has been updated to comply.  While you pointed this thread out in another, I’m not sure you and that poster are having the same issue, and others are successfully uploading with this build.

What does your build.settings look llke?

Did you reboot after clearing out your Key Chain?

Rob

#3

Hi Rob, Thanks for the quick response, that helps in building some confidence.

The last build that I had used was 2013.1202 which apparently will not work as it does not support the iOS7 whatever required for xcode 5.1.x compatibility, so I had to move to the current public build of 2014.2189

My Build.settings looks like this

settings =
{
    orientation =
    {
        content = “portrait”,
        supported =
        {
            “portrait”,
        },
    },
    iphone =
    {
        plist =
        {
            --CFBundleVersion                = “1.1”,
            --CFBundleName                 = “APPNAME”,
            --CFBundleIdentifier         = “BUNDLEID”,
            --CFBundleDisplayName         = “APPNAME”,
            --CFBundleShortVersionString    = “1.1”,
            UIStatusBarHidden             = true,
            UIApplicationExitsOnSuspend = true,
            UISupportedInterfaceOrientations = “UIInterfaceOrientationPortrait”,
            UIAppFonts = {
                “HelveticaNeue-LigCond.ttf”,
                “HelveticaNeue-UltraLigCond.ttf”,
                “HelveticaNeue-ThinCond.ttf”,
                “HelveticaNeue-HeavyCond.ttf”,
                },
            --CFBundleIconFile = “Icon.png”,
            --CFBundleIconFiles = {
            –        “Icon.png”,
            --}
        },
    },
    android =
    {
        usesPermissions                 =
        {
            “android.permission.CAMERA”,
            “android.permission.WRITE_EXTERNAL_STORAGE”,
            “android.permission.RECEIVE_BOOT_COMPLETED”,
            “android.permission.INTERNET”,
        },
        usesFeatures                     =
        {
            { name = “android.hardware.camera”, required = true },
            { name = “android.hardware.telephony”, required = true},
        },
    },
}
 

All of the CFBundle plist settings are commented to avoid any issues still…

I have rebooted the machine and am trying to update it with he OSX 10.9.3 update and the iTunes 11.2.1 update after which I will try one last time. I have wasted more time and stressed on this than getting some work done.

Things did not used to be like this, they just worked.

#4

Unfortunately, the Apple provisioning process is quite difficult and ever since I started using the product, at least some one about once every couple of weeks have these issues.  Its not tied to what build we are on.  It seems like it bites everyone at least once.  Its bitten me before and it took me a couple of days to finally get it straightened out.

Did you clean out your  Your /User/yourname/Library/MobileDevice/Provisioning Profiles/ folder?  Did you make sure to get everything of yours in the KeyChain folder (any junk certs laying around can byte you.  Sometimes you have to open up things to find hidden gems.

#5

update: Tried a new build after restarting and updating… still the same issue.

I so want it to be some silliness from my side but when the only two things involved are BUILD and selecting the Distribution Cert, there is not much that I can do wrong.

#6

So does that mean I am out to swim with the sharks till a miracle (no pun intended) occurs? I thought there would be a solution to this where there could be a way to sign the .app using xcode and create the .xarchive so that xcode signs it and does not give errors. or something that resolves this issue than hang us out to dry.

#7

@007

What Rob is trying to say is that sometimes it’s our local Xcode/certificate setup that’s causing the issue, and not Corona itself.

I’ve been bitten by Xcode’s quirkiness regarding certificates that I suspect could cause the issues you’re seeing. If it *is* a provisioning profile issue, they can unfortunately be tricky to track down.

Rob’s suggestions above are fully valid in this context, and I’d suggest you try them if you haven’t already.

When I had a similar problem there were duplicate certificates in the keychain that had to be removed before things got back to normal.

#8

@ingemar, thanks for the pitch-in, I have tried all that Rob has suggested and can confirm that it is not the xcode certificate. I would so much want it to be a small silly thing that I have overlooked, but in this case sadly it isn’t.

#9

I think I may have found something. It looks like the new 2189 still isn’t compiling with Xcode 5.1.1.

I’m getting that confirmed.

I’ll post back when I know more.

#10

007,

Just to be clear, when you say you did the steps Rob recommended … did you just clear the profiles from the Xcode organizer window (provisioning profiles) and then re-added them there. 

The one way to really eliminate that the issue is not with the apple provisional profiles, is to go to the directory path Rob listed above, and see what you have there.  There was a post on the forum a while back that lists the steps fairly well on how to ‘Completely’ clear out the provisional profiles, you may have to ‘re-do’ them at iTunes Connect and then re-enter them into your computer.  Then remove and re-enter them in your Xcode and then be sure to select the correct ‘distribution’ profile when you build the app.  The there are some steps involving the keychain, but you will have to find that post(I do not recall who posted that).

It is a pain and time consuming series of steps to do all that.  If you did not do all those things, and only removed and re-entered the profiles in the Xcode organizer window, then you have not really did the clean up of the provisioning profiles that a few other users have had to do to get ‘what appears to be similar problem you have’ corrected.  This possibly includes totally re-doing them provisioning profiles and maybe certificates in iTunes Connect.

*** you should call *apple for any cautions before deleting any provision profiles  or certificates you have and re-creating new clean ones.  

I hope this helps!

#11

@007.

It’s fixed now!

You’ll have to re-download the public build though as the old one compiles with Xcode 5.0.2, which Apple will reject according to their new policies. 

After re-compiling, re-submit to Apple and you should be fine.

#12

@Ingemar, when you say fixed, is it just as simple as download the dmg from https://developer.coronalabs.com/downloads/corona-sdk and then build and upload??

I am doing all the jugglery and leaps of faith that all are suggesting, though I do not see any new dates on the files, etc. So not sure where the update/changes have been applied.

While I await your reply, I am downloading and trying that… thanks in advance (if it works) I did say a couple of times that it is the _ Corona Workflow _ seems to be the problem.

Update: On creating a build after downloading the Public Build now and attempting to upload it to the app store, … The Same Error

Could you please point me to the new updated Public Build that you mentioned, the one found above is definitely not it.

#13

is it just as simple as download the dmg from https://developer.coronalabs.com/downloads/corona-sdk and then build and upload??

Yes, I believe so.

When I tested 2189a yesterday I saw it was still building with Xcode 5.0.2 internally.

I reported it and this morning they said it was fixed.

My testing shows that it *now* builds with Xcode 5.1.1 which should get rid of the “ITMS-9000” error.

#14

How can I see that and post the report / console log here (if it helps to debug and fix the issue)

#15

You’re still getting the “ITMS-9000” error?

#16

It’s OK if the dates of the 2189a files are the same. The build change is done on Corona’s server. 

When I was referring to the “old 2189” I meant the one without the added “a” at the end. That version still compiles with the previous versions of Xcode that get rejected by Apple.

With 2189a you should be able to go ahead and build and upload to Apple now.

To be on the safe side install the one you downloaded today “just in case” :slight_smile:

#17

Unfortunately Yes :frowning:

The certificates are all new, re-created, new build made, config file as outlined above, the only thing left to try is making a blank dummy .app and try to upload it to the app store to check the certificate, since it is for a client I am not very daring to try that.

this is just so frustrating

I will try again and see if it works…

#18

If you have control over the upload process, uploading a dummy app isn’t much of a problem as I see it, as you can reject the app yourself immediately (if it gets accepted)

To check if it’s building with Xcode 5.1.1, use Finder to locate the app bundle.

Right click it and choose “Show package contents”.

In there you’ll find “Info.plist”. open it and look for DTXcodeBuild and DTXcode, they should be 5B1008 and 0511 respectively.

If you have something else then Corona is compiling with the wrong version.

#19

Engineering’s fix was on the server side, so you should not have to download a new 2189a.  If you’re running the older 2189, you will need to get 2189a.  They are saying (and have tested in the office) that this is working.

I however expect that you are NOT getting the same error this is trying to fix.  That error produces this error message:

"ERROR ITMS-9000: "This bundle is invalid. …Do not submit apps using beta software"

with build 2303

The error you are getting is about a bad provisioning profile.  The error you are getting reads (at least according to your post above):

The bundle <bundle> at bundle path <application.app> is not signed using an Apple submission Certificate

I’d like to see the exact error you’re getting.  But this message means that when you hit build you either built using a Developer profile or an AdHoc distribution profile instead of a Store distribution profile.   This is is something you have to solve with KeyChain Access and the Provisioning Portal.  You may need to clean out everything.

Rob

#20

@Rob

OMG, How did I miss that??

I got hung up on “ERROR ITMS-9000” and the fact that DTXcodeBuild was incorrect for builds that were compiled with 2189a when it was first released. At least one issue was fixed, but it was the wrong one as far as this case is concerned… bummer.

Re-reading the first post (*thoroughly* this time  ;)) it’s definitely a nasty certificate problem.