Ready to code sign my app - what are the foolproof steps?

What we are doing is “packaging” the app bundle into a .zip file (that is what’s sent to the Notarization service). Thus, the zip file and its contents (the app bundle itself) are Notarized.

If you plan to distribute the app using a DMG container (UDIF format), then you should take the signed app bundle created by the IDE, add it to the DMG container and, then, Notarize the DMG. Once done, because the Notarization service notarizes both the DMG and its contents… everything should be ok to distribute.

Maybe it would be good to have a Feature Request to add the “Distribution/Container” to be selected in the IDE (Zip / DMG / Installer)? :thinking:

Ah. I’d assumed that the .zip file was just an artifact of the process, that is, a way to have a single file to send to Apple. I’d thus assumed that once received by Apple, it was unpacked by the Notarisation Service which then had no further interest in the .zip file.

But then, of what value is having the IDE do notarisation, if as it seems, I’m going to revert to having AppWrapper do it anyway?

What I was doing, was having a folder with some docs etc, into which I then placed the app (code-signed by AppWrapper). Only then was I creating the dmg (using Disk Utility → File → Create dmg from folder), and then getting AppWrapper to notarise the dmg. Thus, at the step where the IDE is involved, the dmg does not yet exist, so I don’t understand your suggested feature request, unless the idea is to automate all those manual steps. That would certainly earn a :+1:

That would be a good feature request. Those with AppWrapper already have it.

So, I solved the chrome download problem… Apps needed to downloaded from https:// not http://
No I just need to solve the problem of installing my dmg without gatekeeper having a fit.

No, they don’t. You still grasp at straws without trying to understand the basic problem.

1 Like

I was actually addressing the problem i was having with chrome not downloading my apps from a link. I know that this has nothing to do with code-signing or notarizing. I was just saying.

My iMac is overheating right now. New Zealand Summer.
I need to get a certificate again so I can register my dmgcanvas project.
I’ll be a happy camper when that works. Then I need to email all the music schools in New Zealand.

Get a certificate “again”? Didn’t you install the Developer ID Application? That’s all you need–unless you also use AppWrapper to make .pkg installers, where you’ll need Apple ID Installer too.

You were initially testing with self-signed certificates. They’re of no use for notarization.

Maybe you mean not a second certificate, but a second “app specific password”? Yes, DMG Canvas and AppWrapper would each need one–but as I mentioned above, you can automate the job through AppWrapper, in which DMG Canvas need not handle the notarization at all (if they both notarize the dmg, you’ll have to wait while it happens twice.)

As I also said above, if you’re actually an AppWrapper customer now, you’re entitled to their support. Sam’s a good guy. Tell him I sent you. :slight_smile:

Not summer here, but I once had a client in New Zealand, who remains a friend. :slight_smile:

Okay follow these steps to the letter.

  1. Open Xcode
  2. Select the “Xcode” menu and choose “Settings”
  3. Click “Accounts”
  4. If your Apple ID is not in this list, add it. Otherwise, select your Apple ID.
  5. Click “Manage Certificates…” - a Sheet window will open
  6. Click the [ + ] button in the bottom left
  7. Select “Developer ID Application” to download and install the correct application-signing certificate
  8. Do nothing else.
  9. Open App Wrapper

Keep in mind that if you mess up this process too many times Apple will not issue you any more certificates. If you do not see “Developer ID Application” then STOP and come back to us with the full list of certificate types it does offer you.

2 Likes

So - I got my app specific passwork. It checked out and the checkout ticks were good (in Appwrapper). I tried it with both DMGCanvas and Appwrapper.
The problem seemed to be when it started to commnicate with apple…
I got a lot of errors with

  • failed Archive contains critical validation errors
  • The signature does not include a secure timestamp.
  • The executable does not have the hardened runtime enabled.
  • The signature algorithm used is too weak
  • The signature of the binary is invalid.
    here’s what my package looks like after running a check

I did do exactly what you said Tim Parnell - it checked out perfectly.
My app has a whole bunch of MBS plugins - is this the problem?

I know you’re addressing Tim, but the answer here is no. Most of my projects contain a liberal amount of MBS (and Einhugur.) AppWrapper should sign all of them before calling DMG Canvas to pack the .dmg.

Based on your screenshot, it looks like you need to also at least install the “Developer ID Installer” certificate.

I see you have “hardened runtime” checked, yet you’re getting the warning. This gives me a clue. In AppWrapper’s “Packing” pane, make sure that “Force DMG Canvas to use wrapped app” is checked. As you might have noticed, AppWrapper does not modify your original build, but does its thing on a copy. Therefore DMG Canvas may not be embedding the right one.

Maybe try this:

  • Codesign your app with Appwrapper.
  • Then manually create a DMG file with DMG Canvas (make sure it sign the DMG too).
  • Then drop the DMG file into Appwrapper and let it do the notarising.

I use app wrapper to wrap my file (I even managed to add a provision to website deployment).
Question… For the DMGCanvas to be wrapped (and get past gatekeeper) - does the dmgcanvas need to the code signed and working too? If I could get that working, I think I wouldn’t need appwrapper. Appwrapper does create these save files… but the only one that actually installs it dmgcanvas - it works well enough when I then run it as a file on my mac from the finder, When I add it to my server and download it, and then run it gatekeeper steps in and I get the usua problem.

Here’s my packing.

Oh - no… At the risk of everybody getting mad at me… Appwrapper 4.7 has stopped opening and giving me a problem report. Did anybody else have this problem. I uninstalled it and reinstalled it twice, restarted my mac twice.

It is almost the other way around. DMG Canvas can only sign the .dmg, not your app bundle. AppWrapper can sign everything, including the .dmg. In your screenshot, though, you don’t have “Notarization” checked next to Auto-Submit (near the bottom.) With this, you can select “Don’t code sign or notarize” in the Gatekeeper popup in your DMG Canvas template. Otherwise, as I said before, BOTH will notarize the .dmg and you’ll have a good wait.

Okay, now you say that AppWrapper is not opening and giving you “a problem report” (which doesn’t tell us much.)

All I can think of (BUT DON’T DO THIS YET!) is to delete the com.ohanaware.appwrapper folder in ~/Library, and the .com.ohanaware.appwrapper plist file in ~/Preferences. I would expect this to make AppWrapper behave like a new install–which means be ready to reenter your activation key.

BEFORE you do anything, this is really an issue where you need to contact Ohanaware and ask Sam to help you. He will.

Sam also has AppWrapper 4.8 in beta. It is working swimmingly for me. He can give you the link.

Going back to your screenshot, you can uncheck the .zip and .pkg boxes. This whole thread has been in the context of .dmgs, and (as it is telling you) you don’t have the Installer certificate loaded anyway.

Dear Lord - It worked!
I followed Jerry’s advice on how to reinstall appwrapper and that fixed it…
I had multiple developer ID applications in my keychain access. I found those in the tab all items. After appwrapper had code signed the dmg, it had a tab called notarize and when I did this it took a while and I was holding my breath. Suddenly it was done! I uploaded it to my server, downloaded it and opened the dmg and dragged it over into the application folder.
Low and behold - it behaved just like a fully fledged respectable app and opened.
So - this is all because of all the help I got from you wonderful people. Mad props!

3 Likes

In such situations, it’s usually safer to rename/move the folder rather than delete it (e.g. just append something at the end of the name, so you can restore it later). That way, it can be done “right now”.

1 Like

Yes, I have done that myself and could have mentioned that. But what I really wanted him to do was ask Sam. :slight_smile: Anyway, happy ending.

1 Like