How to build for mac app store?

[mcfedr]

I cannot see to set the platform or target setting to mas

electron-packager accepts mas as platform

[develar]

Not yet supported, it is easy to do, will be fixed tomorrow.

[mcfedr]

Awesome response @develar

I dont know how much you know about this. I have up to now been using electron-packager, in my gulp file, and a bit of code to build the package to upload for mac store.

The package is built with the tool productbuild - basically I run

productbuild --component "MyApp.app" "/Applications" --sign "' + codeSignPackage + '" "../../release/Myapp-mas-x64/MyApp.pkg"

Please beaware that its nessesary to use a different signing key to the one used to sign the .app

The app one is something like '3rd Party Mac Developer Application: Company (XXX)' and the installer one is '3rd Party Mac Developer Installer: Company (XXX)'

It would be best to have a separate option for the name of the key incase I need to call it something custom.

[develar]

@mcfedr Thanks for details. Yes – our current issue is that we don't use https://github.com/electron-userland/electron-osx-sign and don't use productbuild. Fix is — use electron-osx-sign (and, so, productbuild) and allow mas as target.

[mcfedr]

Yes, I was just looking at electron-osx-sign, and remembered why my code doesn't use it to generate the package file, electron/osx-sign#33

[adam-lynch]

@develar it would be amazing if this could be added ASAP. Adding it to my book. Can you confirm that this would be the correct way to set the platform to MAS?

"scripts": {
  ...
  "pack": "build",
  ...
},
"build": {
  ...
  "platform": "mas",
  ...
}

[develar]

@adam-lynch I am working on it right now. Fix will be published tomorrow morning.

Can you confirm that this would be the correct way to set the platform to MAS?

No. Implemented as "set build.osx.target to ["mas"]" — https://github.com/electron-userland/electron-builder/wiki/Options#OsXBuildOptions-target — to the list of current targets mas will be added.

[adam-lynch]

@develar great thanks!

[develar]

@mcfedr Thank you for links, it was very useful. Your feedback is important, please try 3.11 (next version). See https://github.com/electron-userland/electron-builder/wiki/Code-Signing

[mcfedr]

would be really nice if I could pass to the build options the name for signing, not use the same one as for app signing - https://github.com/electron-userland/electron-builder/blob/master/src/macPackager.ts#L69

[mcfedr]

And now I dont get a normal osx build

[develar]

would be really nice if I could pass to the build options the name for signing, not use the same one as for app signing

Do you mean sign param? Yeah, it is an error. Well, I want to deprecate sign param. It seems, we should introduce CLI args to pass identity/installer identity names. Why env solution (define env)

export CSC_NAME="Developer ID Application: Your Name (code)"
export CSC_INSTALLER_NAME="your name"

is not suitable for you?

[develar]

And now I dont get a normal osx build

What's wrong?

[mcfedr]

sign: I am starting the build from gulp - there is lots of other stuff that has to happen before electron builder is called - I would prefer to pass as the signing keys as options to the build function, as it is I did process.env.CSC_NAME = '...' before making the call, these seems messy to me.

Personally, I wont want to use the cli, It makes sense to me to build a solid API, and the cli on top of that, such that I am not forced to use the cli.

There are reasons why I want to be able to pass args in from gulp - some of my devs work on linux, i want them to be able make linux/windows builds - so i detect in gulp what platforms they are running on and pass only the platforms they can build for to the build function.

osx build: I dont get a 'normal' darwin build in the release folder, I have put .build.osx.target = ['dmg','mas'] in the package.json but the result is a dmg with the mas platform, not a dmg with the darwin platform as I would expect.

[develar]

@mcfedr Thanks for detailed feedback. All your points is valid and confirmed.

with the mas platform, not a dmg with the darwin platform as I would expect.

Why do you want to build both if you distribute app using MAS? (no doubt, it will be fixed, but I want to know exactly why).

[mcfedr]

I need both because I use one for distributing to testers and one for the store - although actually the mas build is probably ok for that as i dont need the auto-update functionality.

Either way, I feel like this should be my choice :)

Also, to me its a bit strange to use a separate 'target' option, when both packager and prebuilt add an extra mas platform.

[develar]

Also, to me its a bit strange to use a separate 'target' option, when both packager and prebuilt add an extra mas platform.

Your case exactly is a reason. "need both because I use one for distributing to testers and one for the store". Otherwise on execute "platform darwin" you will get "zip" + "dmg", but for testers you want only DMG (or, may be, just zip/7z). So, target is an elegant solution.

[mcfedr]

Seems like i would just use build({platform: 'mas'}) or build({platform: 'darwin'}) or build({platform: ['darwin', 'mas']}) when i want both.

[develar]

@mcfedr But configuration is the same (build.osx). Code signing is the same (so, certs are not downloaded twice, keychain is not created twice).

So, we decided to keep platform as OS only. target allows you to specify wanted distributable format (dmg, zip, mas, xz, deb, rpm, 7z, sfx, pkg, sh-installer and so on).

[develar]

3.14 — you can build dmg and mas. or 7z. (['dmg','mas']).

[develar]

Proposal: Add identity to build.osx. And introduce build.mas to override any options in the build.osx (will be used in addition to build.osx if we build mas).

So, it will be easy to pass it using programmatic API:

build({
  devMetadata: {
    build: {
      osx: {
        identity: "my name"
      },
     mas: {
        identity: "my installer name"
      }
    }
  }
})

[develar]

Recommended way to provide entitlements — files mas.entitlements, mas.inherit.entitlementsand others in the build directory. See https://github.com/electron-userland/electron-builder/wiki/Options#buildmas

[mcfedr]

@develar these changes sound great, i'm going to check them out when im back at work

[mcfedr]

Just wanted to say thanks, got my mas and dmg builds working. Things are good!

[develar]

@mcfedr Thanks for confirmation, feel free to file issues if something not user-friendly/can be improved. Please be aware of #398 (non-Apple cert doesn't work on CI).

[mcfedr]

Thanks, I'm currently only signing with apple certs so its not a problem.

It might be of help, we use this tool, https://github.com/ekreative/xcode-build-tools, for helping create a keychain on CI server