9

I've discovered that Xcode 4.3.1 has a serious issue validating apps with resources within a directory tree inside an application bundle.

Apps can pass validation within the Xcode "Build for Archive" process - it only fails when the validation is run via Organizer, which is required to save for ad hoc or App Store submittal.

After spending hours trying to trace down the usual code signing entitlement issues, I eventually noticed the following line in the system console when the export fails:

3/10/12 2:32:48.450 PM [0x0-0x261261].com.apple.dt.Xcode: /Users/chris/Library/Developer/Xcode/Archives/2012-03-10/Coverage 3-10-12 2.32 PM.xcarchive/Products/Applications/Coverage.app/Tiles/T-Mobile-roam/4: Is a directory

The "Tiles" directory has been added to my project via "Create folder reference for any added folders".

I discovered that removing the Tiles directory allows the app to build and validate. Adding it back results in this code sign failure.

It seems that adding a multi-level directory tree completely screws up the validation process, and the error messages send developers on a wild goose chase trying to track down code signing and entitlement issues that really aren't an issue.

I never had any issues with prior releases of Xcode - this seems to be a new serious bug in Xcode 4.3.1.

Is there any workaround possible that will allow us to submit updates to our app?

Notes:

This thread seems related: https://devforums.apple.com/message/630800

This question touches on a similar issue as well: Xcode 4.3: Codesign operation failed (Check that the identity you selected is valid)

Community
  • 1
  • 1
radven
  • 2,296
  • 1
  • 22
  • 39

5 Answers5

15

I spent a day trying to isolate this bug, and I've finally nailed it.

The code signer in XCode 4.3.1 when validating for the App Store or saving for AdHoc distribution chokes whenever there is a subdirectory in your bundle that has the same name as its parent directory.

For example:

test/test/file.x -- FAIL
test/test2/file.x -- WORKS

This seems to be new in Xcode 4.3.1, and hopefully will be fixed soon.

UPDATE: I have heard back from Apple DTS support confirming the issue, and indicating that there is no known workaround yet other than renaming the directories in the bundle. ugh

radven
  • 2,296
  • 1
  • 22
  • 39
5

Maybe I've found a workaround:

  1. Open Organizer;
  2. Right click on the archive you want to export and select "Reveal in Finder";
  3. Right click on the xcarchive file and select "Show package content";
  4. Go to Products/Applications;
  5. Create a folder and name it Payload;
  6. Drag the .app file into the folder (don't copy it, since it would invalidate the signing);
  7. Zip the folder;
  8. Rename the .zip file to .ipa

It worked for me.
Let me know if it's ok even for you.

pasine
  • 11,311
  • 10
  • 49
  • 81
  • Doesn't work for me. When validating I get the message `The file “VOL.AT.app” couldn’t be opened because there is no such file.` – mwidmann Mar 23 '12 at 12:11
  • did you left the original folder there? At the end of the workaround, the original folder must be exactly as you found it. – pasine Mar 29 '12 at 12:49
  • Worked for me but I hope apple comes out with a solution soon – Jason Rogers Apr 14 '12 at 18:18
1

I had the same problem and solved it like this:

There was a script (under Build Phases) which did try to "clean up" frameworks, by removing seemingly unneeded items, such as the Headers.

However, this destroyed the basic structure of the framework, which probably led to it not being detected properly any more, thus failing the signing or verify operation.

For example, the "Headers" folder and symlink should not be removed, only the *.h files inside the Headers folder!

So, check if your .framework folder contains the basic structure that looks like this:

mylib.framework/
  mylib     -> symlink to Versions/Current/mylib
  Headers   -> symlink to Versions/Current/Headers
  Resources -> symlink to Versions/Current/Resources
  Versions/
    A/
      Headers/
      Resources/
      mylib
    Current -> symlink to A
Thomas Tempelmann
  • 11,045
  • 8
  • 74
  • 149
  • This worked for me, thank you. In my case the problem was a missing `Info.plist` file inside the `Resources` folder. – zoul Jul 04 '12 at 09:32
1

I had the same problem. The solution was to remove files beginning by "._".

Be careful, these files are hidden even when you display hidden files !

In my case, I think that these files were generated by Photoshop.

Régis
  • 8,340
  • 1
  • 17
  • 15
  • Where did you find these files? In your project folder? In the build folder? If the files are hidden even when I display hidden files, then how do I find them? – Frank LaRosa Jun 15 '12 at 22:16
  • I found them tracking files with git. They were not displayed in Finder, even with displayed hidden files. – Régis Aug 15 '12 at 07:34
0

We just ran into this where somehow, our .app was getting other .apps built into its bundle. Presumably code signing was choking on the nested app.

David Dunham
  • 8,139
  • 3
  • 28
  • 41