Code sign failures submitting iOS Air App

[alexyamane]

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

[MariusVersteegen]

Okay, thanks for the elaboration.

I recently realized that in previous cases, I didn't really pay attention to the <filename> value in the fooapp.xml. Yet it seems logical to match it with the "filename field" of the first dialog that you get when exporting to release in FlashBuilder. Perhaps that's been a cause for codesign-problems during uploads as well.

For directly creating uploadable ipas, I'm apparently doing something wrong, as it has not worked for me yet from FlashPro CS5.5 or CS6.0.

Ah well, for me, as I'll buy FlashBuilder 4.6 anyway (as it proved essential for profiling),
that's not a problem after all.
As it appears, properly uploadable ipas can still be generated for content created in either
of these FlashPro versions. I created a single (desktop swf and-) swc using either of the FlashPro versions, which inside it uses any swcs generated with either version.

Then, using FlashBuilder 4.6 - build an ipa of an application that does nothing but
to call the application inside the swc.

[sinious]

2 things to note. FlashBuilder 4.7 beta has been out for a while. I'd contact Adobe to assure you'll get a free upgrade if you purchase now.

Second, not to persuade you away from FB, but you could always try compiling your IPA from the command line with ADT. That's really all FB and FP are doing for you. Back when ANEs broke FB because their excessive notices couldn't be handled (a fixed issue) I just starting compiling everything directly with adt. I've had no issue with those app submissions either..

[MariusVersteegen]

Sounds like two pieces of good advice, thanks.

[sinious]

Let me know because I'm still on suite CS5.5

[MariusVersteegen]

Okay - here's the result of my testings:

The FlashBuilder 4.6 build already produced uploadable ipas.
The adt-build variation for FlashBuilder did so as well.

The adt-build variation for FlashPro CS6.0 did so too.
And after all, even the build straight away from Adobe CS6.0 did so as well.

As it appears - the main pitfall that made me fail to build uploadable ipas using FlashProCS6
before, was next thing:

I had learned to create an uploadable ipa for FlashBuilder4.6 first.
As part of the ritual of cleaning up all to the max before the build (otherwise no uploadable ipa),
I a.o. deleted the foo-app.xml file in the bin-debug directory.
(as it is only a copy that FB4.6 would recreate from its src located original anyway).

As I tried to create an uploadable ipa from FlashProCS6, I did the same.
However - FlashProCS6 ostensibly stores a significant part of its air-ios build settings
on that bin-debug located file (instead of inside the fla!?!).
(so - the code/project info must be stored/maintained next to the build results - can it be more ugly? 🙂
So - at the moment the file is deleted - the app id is changed to some default value (which is the name
filled in on the first publish tab - with underscores replaced by dots), and codesign
failure results.

Another potential pitfall may have been (not sure) that at first, I built my "app swc" for flashplayer11, instead of Air3.4(desktop).
In the end, the ipa is built using Air3.4, and it could be that it requires the swc it depends on to be built on Air3.4 as well.
(an error during adt trials raised that suspiscion, although it lateron proved to be caused by the fact that my Path environment
variable contained the path of another adt - (-as well?))

It took me a day to explore the ways, but as in the end everything appears to work
(once you know the pitfalls) - made it worth the effort (and posting it - perhaps not just for myself).

Additional thingy: After downloading FlashProCS6 - it is essential to download the latest update.

Cheers, Marius

[sinious]

Just touching on the XML as they're handled differently by Flash Pro and Flash Builder.

Flash Builder is geared toward a source, debug and final destination setup. The source ('src' folder) has the XML that is required to build. The bin-debug merely copies the .xml file from the 'src' folder every time you debug your app. That's why it's in the debug folder. Delete it from there, press debug and you'll see it appear in there again. This is normal.

Flash Pro lets you set your own folder structure up. Typically where your publish settings are set to export to has the necessary XML file. That XML file is required, just like it is in Flash Builder. The only difference is you create the IPA in the same folder that XML is typically created in. If you accidently deleted it, you definitely did a bad thing. Just as bad as going in Flash Builder and deleting the XML file from the 'src' folder. That will kill Flash Builder from producing that project in the same way, only it's not easy to re-create the XML file. Flash Pro will re-create it every single time you open the Publish options for AIR for iOS.

So when working with Flash Builder it's safely in the Source folder and doesn't bother you or appear in a Release IPA. However Flash Pro typically keeps that XML file in the same place the IPA is compiled so if you go "clean up" happy and delete it, you have to re-create it and reconfigure it all over. (just restore it from your Recycle Bin!)

You may just want to try 'adt'. Here's a link with a file folder structure recommendation and how to use adt:

http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac1e63e3d128cdca935b-8000.html

[MariusVersteegen]

Yes, I understand now- and as pointed out above - I did do the builds using adt directly as well. I now realize that its advantage
over direct FlashPro builds is that it allows to keep the build-code (including foo-app.xml) together, while the build result can
still be in an other folder (just like with FlashBuilder).

[rachalmers]

Just to add my 2 cents worth, I am using CS6 Flash Pro + AIR and the SDK

CS6 Flash Pro with latest upgrades.

AIR 3.4 for iOS

ActionScript 3.0

I always start a project by actually creating a Project, and open and close that every time.

Everything is in appropriate directoriues under that project. eg.

The Project in this case is based in the directory PinPoint 6.5, under the directory Flash Development

Within that Project directory I direct AS3 to find classes here. Such as PinPointPremium.as.

C:\Users\Robert\Flash Development\PinPoint 6.5\Classes

Libraries in

C:\Users\Robert\Flash Development\PinPoint 6.5\libs\OAuthServices

C:\Program Files (x86)\Adobe\Adobe Flash Builder 4.5\sdks\4.5.1\frameworks\libs\core.swc

and so on...

So the whole hirearchy is made up of

/Pin Point 6.5 ..... or what every your project name is. Doesn't have to be the acutal app name.

This root contains the project files of

.swf

.fla ......and a couple other ones that get generated

then .....

/build ....... the finished ipa

/Classes ..... class files like PinPointPremium.as

/fonts ......  any fonts you are using

/icons .....  you know Apple needs these

/images ....  any images you are using

/libs .....  any libs you are using

/sounds .... and any sounds you are using

When I start a new project, I just replicate this directory structure.

I hadcode signing problems earlier on, not because of this structure, but because I was creating the Certificates out of sequence. They weren't talking to each other as a result. Once I got that right again, away it went.

Problem Note Here ------ Stuff I still struggle with for no good reason.

The other thing I notice is that CS6 Flash Pro and the project descriptor file .xml don't seem to co-exist entirely comfortably.

In this case...

PinPointPremium-app.xml

Within this file, you have this bit near the top.

.......................

  <description/>

  <!-- To localize the description, use the following format for the description element.<description><text xml:lang="en">English App description goes here</text><text xml:lang="fr">French App description goes here</text><text xml:lang="ja">Japanese App description goes here</text></description>-->

  <name>

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

  </name>

  <!-- To localize the name, use the following format for the name element.<name><text xml:lang="en">English App name goes here</text><text xml:lang="fr">French App name goes here</text><text xml:lang="ja">Japanese App name goes here</text></name>-->

  <copyright/>

......................

For a start, if I don't put in that bit for name,

............................

  <name>

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

  </name>

.............................

The Geolocation service in the iPhone/App isn't enabled. Silently. NO warning messages - nada. It just doesn't work at all. Which is NOT GOOD in an app that is basically a GPS.

In other words, if I don't hand edit the xml description file and modify this section, my app will never work. It will have the name in the App name field of the AIR for iOS tab in Flash Pro, but the app wont work.

With that "name" field added to the xml file, you then can't see or edit the App name field in the AIR for iOS tab - but the app now runs the Geolocation service as it should.

People have told me that this is fixed ???? but it's NOT. It's a right pain in the butt.

SECONDly, the part of the descriptor file that talks about doing the same to localize the <description> segment - doesn't. If you do that then the app won't build. It tells me it doesn't recognkize the description tag. go figure.

So knowing all this - I can still build and upload my app. I can't imagine how the unwary get get on with this lot, and Adobe et al don't seem particularly bothered?

cheers folks

[MariusVersteegen]

Thanks Robert, by sharing these details, you're saving others (probably me as well) tons of time.

[sinious]

Marius~

Ahh I see the comment about path to adt now. To answer you exporting for Flash vs AIR, I've honestly never tied any code in Flash Pro to anything AIR. I always used Flash Pro just to easily create objects and then tied them to classes and/or utilized them via code solely in Flash Builder. So I've only ever (knowing captive runtime was being merged) exported to the highest version Flash Player for SWC and compiled with the highest version AIR via FB.

I don't use the command line to compile via adt anymore but if you need a lot of compiles a good batch file sure speeds things up.

Anyhow glad you got everything sorted, in multiple ways

Robert~

AIR 3.4 isn't the latest, 3.5 (and FP11.5) has been out:

http://www.adobe.com/devnet/air/air-sdk-download.html

And as you discovered, yes you should manage the XML file yourself. The panel used to work back in AIR3.2 or AIR3.3 before they introduced localizations. They have not updated it for localization support (In CS5.5 or CS6 apparently). I have the same behavior as well. If I set a language I can't use the CS5.5 publish panel for much more than setting an IPA destination and assigning p12/mobileprovision. Doing just that doesn't bother your XML files settings, although it will re-write it (keeping what you had). I don't think this is a big issue. How many times do you change your app ID, name or description? I've long ago learned to just edit the XML file directly as that's the way Flash Builder expect you to do it so I never really thought it was a big deal.

[MariusVersteegen]

Hi sinious,

As you're a pinnacle of knowledge in the Adobe community, I think its best to share next information to you:
Another cause for codesign verification failure during upload to apple can be when the clock on the computer that has created the ipa (in my case, a pc) is ahead of the clock on the computer that uploads the ipa (in my case, a (virtual-) mac).

So - what works is:
1. synchronize the clocks on both systems.
2. transfer ipa via dropbox.
3. upload ipa.

It may be the case if one of both computers is using local summer time, while the other is not.
But it may be the case as well if one of the computers has its time only a few minutes ahead.
I can imagine that in the latter case, it could explain why some people first have to apply some voodoo, for instance by renaming to zip, and other things - because it bridges the time gap.

Regards, Marius

[MariusVersteegen]

Hi Sinious, I bought Flash builder 4.7, yet it looks like its compiler does no longer properly support gradient bevel and gradient glow
bitmap filters - or hopefully I'm wrong about it? - about a month ago, I posted it on the FlashBuilder 4.7 forum, but no response so far.
I was hoping you could share me your opion on it:

http://forums.adobe.com/thread/1132057

Best Regards

[sinious]

I responded to your other thread.