can someone assist me shortly on installing Apple Developer Corporate licenses please?
I received Developer ID Application and Installer certificates from the client I am working for, in 3 different file types (.cer, .p7b, .pem).
Double-clicking them installed them in KeyChain, and they are shown as valid.
Though, when I open Xcodes preferences, below my distribution licenses only “Developer ID Application” is listed (no “Installer”), and marked with a red sign and “Missing Private Key” info.
AppWrapper 3.9.1 tells me both website deployment certs are missing.
If you do not install the private key too, it will not work.
If you lost the private key or do not have it, you willneed to revoke the key and opt for new keys. There is no other way.
Before you install the identities from your client, make sure you remove all of their existing certificates from your keychain. Use the search field in the top right hand corner, double check with each keychain (the list in the top left hand corner).
Thanks, you two! And sorry for the late reply, because this took incredibly long to fix. As it turned out the customer had never created the corporate licenses and for some reason Apple declared him not to be the owner of his own profile
Thats now fixed and AppWrapper gives green light, and I now try to attempt to fix the dozen of errors that AppWrapper reports. If I might add another related question, how could such a code signing error be caused? And any ideas how to find the real reason?
[quote]/Users/uli/Documents/Repositories/App Desktop/AppName/AppName.debug.app: bundle format unrecognized, invalid, or unsuitable
In subcomponent: /Users/uli/Documents/Repositories/App Desktop/AppName/AppName.debug.app/Contents/Frameworks/Capturei1IOHelper/Resources/de.lproj[/quote]
The helper is a console app created by me. Of course Apple doesnt like the helpers to be in Frameworks too, and I wonder why I missed the “Contents” Folder that is also accessible by the Xojo IDE. But that should be more or less easy to fix on my side.
Executable files should be in the MacOS or Resources directory. The Frameworks directory is only for frameworks and libraries loaded dynamically at runtime.
Shouldnt they be in macOS or Helpers?
I am currently moving them. What bothers me more is the code sign error above. There are only two localized strings in that lproj file, Xcode opens it without complaints. Any ideas what could be the reason?
Ah! Sorry, youre right. I moved this particular helper to Helpers and now I got a code sign error on another helper that has not yet been moved. Lets see where I end when all have been moved. Thanks, Greg!
EDIT:
Solution: Down to 3 critical errors. Much better, thanks!
but for these I must be overseeing something very obvious.
AppWrapper tells me
and in that helper I have these constants declared as
Protected Const eXactLIb32 as String (only 32 Bit Desktop, Console, Web)
And eXactLib64 for 64 Bit only:
Both folders copied to app.parent in a CopyBuildScript, and clearly working. I checked that all CPU compiler flags are set correctly for the external declares. Any idea what might be the reason for this error (personal stupidity not excluded)?
In regards to your 3 remaining errors. These are from my checks that Ive added to App Wrapper; they are not from the Codesign functions.
The first one is because executable doesnt contain any 64-Bit code and most certainly is banned from the App Store; most likely this is an oversight by me as I would expect Code signing with a 32-Bit only executable to work with developer ID (but for how long I couldnt say).
The other two are because App Wrapper is checking the paths that the executable links too. Apple no longer allows executables to link outside of the bundle (except for certain paths); my guess is that its failing that check.
At this point; I would suggest proceeding with wrapping. If you get no errors during wrapping and the signed app launches fine on other machines, let me know and Ill revise these checks.
Thanks a lot, Sam! I am having the customer check the DMG only first and things look fine, although I got App Wrapper errors during the build that resemble the first results I posted will update soon.
Ill let you know when we tested on a few more machines. And then for the final download tests.
P.S.: And yes, this app would never make it to the app store. We have to maintain some 32 Bit code because some device vendors did not update their drivers to 64 Bit yet, not to mention signing them
So yes: No troubles opening and running the app on several 10.13.6 and 10.14.5 installations.
Although during build I receive a Wrapping aborted warning (3 to be exact) with the first one being the bundle error I noted above but now located in “Helpers” instead of frameworks, the second telling me that Code Signature for the whole app has been rejected and the last one that GateKeeper doesnt like it as well
A wrapped app is being created anyway and I can use it for DMG Canvas.
Just to confirm what I’ve found matches @Ulrich Bogun statement; which is Helper apps should be in the “macOS” or “Helpers” folder. It is my understanding that the Resources folder is for non-executable code only. I believe that scripts such as Apple Script or Ruby are permitted in the Resources folder, I know that GLSL & MTSL are allowed.
Please send me the wrapping report; after wrapping select “E-mail support” from the “Help” menu and this will auto include the wrapping report.
I’d also like to build a sample app here; with your previous layout, so I can teach App Wrapper to reject it first.
My goal is to get the app diagnostics fast enough that it can provide enough information before you even click the “Wrap” button. Of course this means that any mistakes I make before hand need to rectified; and I wouldn’t stop you from wrapping (because I can be wrong and things change).
@Ulrich Bogun I see that you’ve done that already, I’ve only just gotten to your e-mail!
The error is highlighting that it’s failing because that language pack is not code signed; whaat…
This is odd, can you zip up “ChromaChecker Capture.app/Contents/Helpers/Capturei1IOHelper/Resources/de.lproj” and mail it to me please; I need to see if there’s anything I can see which might explain what’s going on. I mean technically a language pack is a bundle, but it’s not an executable bundle. There’s obviously something about it, which is making code sign think that this needs to be signed.
I’ve just checked the latest document I’ve obtained and there’s nothing there about needing to code sign language packs, but that doesn’t mean that I don’t now need too either…
Thanks a lot, Sam. I think the language pack is indeed unsuspicious and added a few notes. It might be of value for others to know that exactly the same error appeared as written during debug runs, and when I moved the helper to “Helpers”, it was replaced by the same error, but now accusing different lproj files in different helpers which had not been moved. Once I had placed everything in the folders suggested by App Wrapper, the error disappeared but now continue to lives on during the build/wrap process.
FWIW, the IDE does have frameworks and plugins in folders within the Resources folder. It took a while to get it right, but its all working now. We even have a file that only passes notarization when it gets signed right on the DMG for some reason. That took a long time to track down.
@Sam Rowlands: Did you find anything in the logs? I still got the Wrapper error and a GateKeeper failure, but a wrapped app is created and I can use it with DMG Canvas. As the failure in the Helpers translation file(???) transfers to the main app I am very uncertain if we can publish this way.
