Inspiring

Answered

Code sign failures submitting iOS Air App

Forum|Forum|13 years ago
September 27, 2012
4 replies
33794 views

Hi folks,

I wondering if any of you might be able to point me in the right direction on this. I'm likewise having issues trying to submit an ipa file to iTunes Connect via Application Loader, and got as far as zipping the .app file and submitting. I get an error in Application Loader that: "Unable to run the lipo command: ... Can't map input file ..." and "Application failed codesign verification. The signature was invalid, contains disallowed entitlements, or was not signed with an iPhone Distribution Certificate.", and "Unable to extract codesigning entitlements from your application. Please make sure ... is a valid Mach executable that's properly codesigned".

Now, before posting here, I have done the following to no avail:

a) I've regenerated all certs and mobile provisions from the top, completely on the Mac once, and completely on Windows as well using openSSL. Both times, I started at the top, from the csr request.

b) I'm able to install and run my ipa file just fine on the test iPhones using the distribution.p12 file and the associated ad_hoc distribution mobile provision. It's always only when I compile for 'app store release', using the distribution.p12 file and the app_store mobile provision that this happens.

c) I'm using Adobe Flash Pro CS6 on Windows 7 64, with Adobe Air 3.3 SDK, and I am submitting on a real Macbook Air with OS X Mountain Lion.

d) I've also gone as far as trying both sets of cert/provisions (generated on mac and windows), by publishing the ipa from within Flash Pro CS6, and also using the adt command line, but still same.. works fine as ad_hoc on the test iPhones, but will not submit through Application Loader. Same codesign verification errors.

e) My app uses native extensions, but these compile and run perfectly fine on the ad_hoc builds.

I'm pulling out my hair at this point as to what I could possibly be missing or doing wrong, or if there is a bona fide bug with the combination of technologies I'm using? I would appreciate any tips/hints/suggestions from anyone who know what I am describing here.

If there is anyone at Adobe that can look at my ipa file build for the app_store submission, that would be wonderful as well.

with kind regards,

Alex

This topic has been closed for replies.

Correct answer alexyamane

SOLUTION

-------------

I'm posting this so others with the same problem may benefit. This makes no sense at all, but when I changed the ipa file extension to .zip on my Windows machine first (not on the Mac), transferred the .zip file to my Mac, then unzipped it on my Mac, and re-zipped the .app file on the Mac, Application Loader accepted the submission.

I was previously sending the .ipa itself to my Mac, and renaming the file to a .zip file on the Mac as the first step. This is literally the only difference, and it would have saved me 3 days of wasted time.

hope this helps,

Alex

R

rachalmers

Known Participant

Yes, this is crazy really. I can't believe this is so unnecessarily difficult. Apple charging $99 a year for the pleasure of sheer frustration....

No matter what I do now, I can not get past the Codesign Failure error.

Is this because of something in CS6? Something Apple has done? no one knows, because this discussion is not only here, but also all over the Apple forums.

I can say, I have actually got 4 apps in the store. Built right up to CS5.5, and uploaded with Apples. ApplicationLoader on a Mac.

The moment I upgraded to CS6, and the new Air skd's etc, I first of all ran into the naming problem with the localization thing, then getting past that got to the CodeSiging error - where I am now stuck.

I have no idea now what to try next. Go backwards to CS5.5 and try again? how many hours can I afford to waste on this.

alexyamaneAuthor

Inspiring

@Marius, glad to hear you got your certificate issues out of the way. I never have any certs/provision issues, but I do export my .p12 certs from the Keychain Access tool on my Macbook Air. I do work on Flash Pro CS6 on a Windows 7 64 bit machine though.

@Robert, I feel your pain. I went a week trying to figure this out when I first posted this thread. The first time, I was able to resolve it by renaming the .ipa file compiled on my Windows machine to a .zip file (not to be confused with 'zipping' the .ipa file), then, transferring that to my Mac, unzipping the .zip file there, and then zipping the .app file in the Payload folder, and submitting that through Application loader. The second time I encountered this issue (this past week), it was fixed by making sure my extensions directory only contained the .ane files I was using.

Hope this may help,

with kind regards,

Alex

R

rachalmers

Known Participant

I've got the exact same problem. It's now 02/11/2012 and this issue seems to be persistent.

"Application failed codesign verification. The signature was invalid, contains disallowed entitlements, or was not signed with an iPhone Distribution Certificate."

the original app was built with Flash Pro 5.5 and the Air SDK etc, and works fine. It's in the app store.

So I have loaded up CS6, AIR 4.5 and the Flex libraries etc (combined package) and it all compiles fine and works on the iPhone no problems.

However - try and upload it to the app store - and there comes the problem.

Now - to confuse the issue a bit, there is another problem with CS6, that MAY be causing errors.

The application's xml file contains lines at the top like this.

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<id>au.com.chalmers.pinpointpremium</id>

<filename>PinPointPremium</filename>

<name>

<text xml:lang="en">Pin Point Premium</text>

</name>

Now, you can't enter text into the Application Name field in the Publish Details popup.

If I do not wrap the name tag in the <text .... thing, the Geolocation service on the iPhone is seen as inactive. and of course doesn't work.

That is. If I leave it like this, so that it shows up in the Publish Settings,

<name>

Pin Point Premium

</name>

This breaks the Geolocation service.

Is this breaking the Loader? Who knows.

I don't see anyone actually adressing this issue. Lots of people fiddling at the edges - but no definitive fix.

sinious

Braniac

I'll chime in that I updated to the new localized version of <name> and it disabled my ability to edit it in the publish panel in CS5.5. However I can simply open the XML and edit it so I don't see that as a big deal. Localize everything they suggest and also set your supported languages.

Also make sure you're exporting with distribution, development, to the store.

R

rachalmers

Known Participant

The interesting thing about the localization in CS6, is that if you don't do it - it breaks the Geolocation API, and any app that uses it. And it breaks it silently. You don't know until you run your app. You then notice of course that your app can no longer get Geolocation data from the iPhone/iPad etc.

Also checked the distribution/development situation. Not this time. I continue the hunt for a solution to this.

Thanks

alexyamaneAuthorCorrect answer

Inspiring

SOLUTION

-------------

I'm posting this so others with the same problem may benefit. This makes no sense at all, but when I changed the ipa file extension to .zip on my Windows machine first (not on the Mac), transferred the .zip file to my Mac, then unzipped it on my Mac, and re-zipped the .app file on the Mac, Application Loader accepted the submission.

I was previously sending the .ipa itself to my Mac, and renaming the file to a .zip file on the Mac as the first step. This is literally the only difference, and it would have saved me 3 days of wasted time.

hope this helps,

Alex

sinious

Braniac

Mac must treat .zip differently when it un/compresses? Not sure but glad you got that solved.

On the Flash Builder question, no there's no real "Auto-import" from Flash Pro to Flash Builder. The workflow is very different.

The single thing you lose is the documents main timeline. If you animated things along that timeline you need to embed everything you did on the FLAs main timeline into its own MovieClip. When you export from Flash to use in Flash Builder, you typically export a SWC. When you import that SWC you access library items the same way you do in Flash Pro via code:

var someLibraryObject:MyClass = new MyClass(); // grabbed a library item with the AS linkage ID "MyClass"

This is why you don't want to use the documents main timeline A SWC won't contain that timeline, just library elements. Now technically you don't have to stay away from the main timeline, you could export a SWF of your main timeline and load that, but this is a bunny trail of possible failures all over the place.

Grab the trial and you'll see the workflow is much more code-centric. You get used to thinking of Flash Pro as an application that lets you quickly create complex objects and animations inside MovieClips and Sprites, but then you import them into Flash Builder and utilize them strictly with code.

And of course the whole other side of Flash Builder, besides top notch refactoring, code completion and profiling, is Flex/MXML. That is an entirely different beast. It's really what it is designed for.

MXML is a very simple markup language that makes it a cinch to create AS3 objects. For example to make a new Arial TextField that's bold at x position 100, y position 200, width 300, height 26, font size 24 with the text Hello World, here's the difference:

AS3:

var tf:TextField = new TextField();
addChild(tf);
tf.x = 100;
tf.y = 200;
tf.height = 26;
tf.width = 300;
var fmt:TextFormat = new TextFormat();
fmt.font = "Arial";
fmt.size = 24;
fmt.bold = true;
tf.text = "Hello World";
tf.setTextFormat(fmt);

Or MXML:

<s:Label text="Hello World" fontFamily="Arial" fontWeight="bold" fontSize="24" x="100" y="200" width="300" height="26"/>

It waters down a bunch of lines of code into a simple to understand markup language. It also has a lot of premade mobile-optimized (hence the s: spark namespace on "<s:Label") components that are drag and drop. More importantly there's a pretty good layout system built into flex. It becomes important so your interfaces can expand and collapse from device to device in an intelligent way.

sinious

Braniac

Do you have the WWDC certificate installed?

When you generated your distribution certificate from the portal did you do it before or after you made the app id in the portal? App IDs are assigned to certificates, which makes me crazy. If I create a new app ID I need to re-download the new distribution certificate and re-generate a new .p12 or the app ID (com.example.whateverApp, etc) won't be valid.

If the latter was the issue you would also have ad-hoc issues, unless you downloaded your development certificate at a later time than distribution.

For a company that pureports simplicity as it's overall goal in life, the provisioning portal is an utter failure.

I simply make sure I follow these steps when I make a new app:

1. Make a new App ID

2. Download new certs to generate new dev/dist .p12s (I use a mac for it, keychain access, which generated the original codesign request)

3. Add devices if needed (ad-hoc dev testing)

4. Generate dev/dist mobileprovision for app ticking off all proper testing devices for dev (certificate should be auto-assigned to both)

It's not hard once you've done it a ton of times but anything out of order will upset Apple. Then you must absolutely make sure your apps ID conforms to the way you set your app ID up. Remember, don't put the first portion of the app id like SG93AX29Z1.com.example.*, drop the SG93AX29Z1 portion and make sure your app id is set to "com.example.someThingHere". Otherwise you'll fail codesign on both ad-hoc and store.

Don't forget the new 1024px icon you need to supply too..

alexyamaneAuthor

Inspiring

Hi Sinious,

Thank you for your suggestions. Yes, I'm on page with you about not liking having to regenerate the certs and mobile provision files after adding a new appID, devices, etc. My problem still remains though: I can compile and run the ipa using the distribution cert and distribution adhoc mobile provision just fine on my iPhone, but when I compile for app store submission using the same distribution cert (and the app store mobile provision for it), when I load it using Application Loader (and I'm using v2.7 on Mountain Lion on my Macbook Air), I get first, that the .ipa or .zip is not a valid archive. So I did as some suggest, rename it as a zip, unzip it, and then re-zip the .app file within the Payload folder, and try submitting that. When I do, that's when I get the code sign validation errors I listed in the first paragraph.

Some more things I've also done since my above post----

a) I've tried to build for app store using AIR 3.4 SDK using Flash Pro CS6, but same thing.

b) I've also tried building from adt command line with AIR 3.4 SDK, same thing.

c) I've tried command line adt build on the Mac itself with AIR 3.4 SDK, same thing.

d) On all of the above scenarios, if compiled for the ad_hoc mobile provision, and loaded on my iPhone through iTunes, it runs fine. So it seems to me, that somehow the application is not getting signed properly for whatever reason.

I'm about out of options and really would appreciate some folks from Adobe giving us some pointers on this....

thank you again,

Alex

alexyamaneAuthor

Inspiring

I use AIR SDK v3.4. After 3.3 the adt command line utility now warns me I haven't chosen a minimum OS version and auto-assigns iOS 4 as the minimum.

I use Flash Builder to code, Flash Pro if I want to make some quick graphics/animations and export those via SWC into Flash Builder. Only problem with Flash Builder is it still cannot export ANEs without getting hung up on any errors. I can't believe they didn't fix it but I continually check help->updates and it never has a patch. Therefore I must use the command line. There's even an "Ignore Errors" checkbox but it still hangs during export.

I tell Flash Builder to Export Release Build, pick a folder, fill out the usual credentials and inclusions and let it run. It builds a bin-release-temp folder containing everything necessary to build the IPA. I run the adt command line in that folder and it builds the IPA for me.

Hi sinious,

Thanks again. Maybe I should look into switching to Flash Builder already. I've been in my Flash Pro comfort zone (I'm much more articulate with AS3 than Flex).. I did, however, find this in the 'known issues' release notes for Air 3.4: "[iOS] On some content, Installing an .ipa file with AIR 3.4 occasionally fails with Installation Error: PackageExtractionFailed(3220974)" http://helpx.adobe.com/en/flash-player/release-note/fp_114_air_34_release_notes.html#known_issues

Hoping this isn't what I'm experiencing through it sounds a lot like it. Specifically, I'm seeing 'code sign validation errors' when I try to submit to iTunes Connect using Application Loader... what to do... sigh...

Alex

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded