12

I have been with this problem already 8 hours unable to solve it.

Whats Cool JLD$ codesign -vvvv build/Distribution-iphoneos/Whats\ cool\?.app
build/Distribution-iphoneos/Whats cool?.app: a sealed resource is missing or invalid
/Users/JLD/Desktop/iOS Development/Whats Cool/build/Distribution-iphoneos/Whats
cool?.app/Whats cool?: resource modified

I have tried the solutions posted on all these threads to no avail:

I even tried recreating the whole project again redoing all the IB connections and nothing works! It builds everything, but it is unable to code sign it! So I'm unable to upload it through the AppLoader.

I am doing all these following the instructions found at the provisioning profile on the Distribute application page.

I even tried building from another Mac. I have my distribution profile and my distribution certificate both set to WildCard. But it still doesn't work. I made a new app under a different name with another Bundle ID to no avail. I don't know what to try anymore! Thank you future problem solver! I know you are there so come to my aid, I'll thank you forever!

UPDATE: I tried to make the new project from scratch. Copying the source code and remaking all the connections on IB to no avail. I even followed this link with instructions:

Unsuccessful. I don't know what else to do. I'm even considering using one technical incident to solve this problem once and for all.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Jose Luis
  • 3,307
  • 3
  • 36
  • 53

7 Answers7

12

I just experienced this error trying to sign an archive with Xcode 4 on Lion. The problem turned out to be related to the fact that the archive had been zipped on one machine and transported to another --- the zip utility did not support symbolic links, and the app code signature uses a symlink inside the bundle, so the unzipped archive was invalid.

Possible solutions are:

  1. Use the Finder's contextual (ctrl-click/right-click) menu and choose "Compress" to create the zip file, or:
  2. Use the command line version of zip and provide it with the -y argument to preserve symbolic links.
benzado
  • 82,288
  • 22
  • 110
  • 138
9

This isn't a specific answer I'm afraid, but something you may not have thought about.

From your command line snippet, it looks like you're code signing your app bundle after it's been built. Are you moving the bundle (.app folder or maybe an IPA or ZIP file) from another machine, or from another drive? I've had problems with moving app bundles between file systems that don't support symbolic links properly. Are you using a network drive, or have a local drive that's not formatted for Mac OS.

LongSteve
  • 323
  • 2
  • 6
  • Maybe I'm not sure since I'm accessing the proyect from a server in the company. I tried doing it locally but it didn't work. Should I redo the proyect locally? or is there a way to fix it? – Jose Luis Mar 07 '11 at 08:22
  • I would say yes. Certainly if you're accessing the app bundle on a network drive, the signing isn't going to work, due to the symbolilc link issues I mentioned. Simply copying the bundle from the network drive to your local machine before signing probably won't fix that either. What we do is build and sign on a Mac, then zip the bundle up, on that Mac, and only transfer the zipped bundle to server folders etc. – LongSteve Mar 11 '11 at 13:52
  • I see thank you for your answer Steve, so the solution would be to make everything again, copy pasting on a locally MAC OSX formatted drive right? – Jose Luis Mar 22 '11 at 08:15
  • Thanks a lot, that pointed me in the right direction as to the problem i was having. You saved my bacon! – Chris Jan 12 '12 at 00:33
9

Solved. The problem was a '?' character on the product name. Shouldn't be like that but that's how it is. Nowhere apple says that that makes a codesign verification issue.

Jose Luis
  • 3,307
  • 3
  • 36
  • 53
  • 1
    In general you don't want to include `*` and `?` in filenames since they are used as wildcards by the command line shell. (Not a problem if you work exclusively through the Finder, but app development needs to interact with shell scripts.) If you want a question mark in your app's name, use the `CFBundleDisplayName` key in your app's Info.plist file. – benzado Aug 10 '11 at 18:45
  • 1
    10 years later and this still seems to be a problem! I was submitting a Solar2D (used to be Corona) app and had to remove the ñ character from the name for it to be accepted. – Andy Castles Jan 27 '21 at 22:59
  • @AndyCastles crazy, I wonder how do developers in Thailand, Korea etc... do they have to use the english alphabet to name their apps? – Jose Luis Jan 28 '21 at 19:04
  • I just ran into a similar issue on macOS Ventura. Turns out I had a capital letter in my main binary (the one referenced by CFBundleName). Using only lowercase characters solved the problem for me. – JoWie Jul 15 '23 at 19:45
  • I meant CFBundleExecutable instead of CFBundleName – JoWie Jul 16 '23 at 09:15
2

Apple's new APFS file system has some bugs to process unicode characters and it is causing the issue.

Moving the whole project to the legacy MacOS Extended volume and archiving again solved the issue.

Valeri
  • 1,072
  • 5
  • 14
  • 31
1

Another problem could be your app contains image file name with none English characters in your app. Such as 'ş ç ğ'. If you remove those images or change the file name it will proceed.

mcnk
  • 1,690
  • 3
  • 20
  • 29
0

I passed days on this problem, for me it's because the name of the application contains arabic caracters :(, So apple on xcode 12 doesn't accept arabic caracters ? on xcode 10 i publish without any problem

it's very complicated to be a developper on ios

tamtoum1987
  • 1,957
  • 3
  • 27
  • 56
0

In my case, I got that error because the disk image I created to distribute my app ran out of space and ditto did not copy all files from the build folder to the disk image. As the script I used generates so much noise, I missed the warning of ditto that it ran out of space in the target disk image. Unfortunately, ditto should have aborted the whole procedure, instead of burying the warning into a myriad of other paths of smaller files that it managed to copy.

jvarela
  • 3,744
  • 1
  • 22
  • 43