Notes, neat things, and gotchas about building and packaging a Go executable for the Mac App Store. This is based on the bampf project build at https://github.com/gazed/bampf/blob/master/build
bampf/srcdirectory. This seemed a handy place to keep product related stuff without cluttering the top directory,
bampf, or the code directory,
buildBinary (line 53): Its nice to be able to inject a version number into the executable during the build. In this case the version comes from source control tags, git for this project, combined with the go build -X flag.
buildWindows (line 110): Sometimes it can be easier to ship a single executable. Zip was used combine the game resources with the go executable into a single binary. At runtime, the go executable is able to open itself to read the zipped resources.
buildOSX (line 68): Needed
-linkmode=externalbuild flag as Apple looks for some system specific fields in the executable. Details in go issue 6198.
buildOSX (lines 73-80): Mac applications need to conform to a particular directory structure.
buildOSX (lines 88-93): Mac applications have a particular file mode that can copied from an existing Mac app.
buildOSXmethod. Edit to replace
YYYwith the names of your developer OS X keys.
# create two signed versions. One for self distribution, one for the app store. signOsx('target', '"Developer ID Application: XXX"', '"Developer ID Installer: XXX"') signOsx('target/app', '"3rd Party Mac Developer Application: YYY"', '"3rd Party Mac Developer Installer: YYY"') def signOsx(outdir, akey, ikey): subprocess.call(shlex.split('codesign -fv --entitlements src/Entitlements.plist -s '+akey+' '+outdir+'/Bampf.app')) subprocess.call(shlex.split('productbuild --version 1.0 --sign '+ikey+' --component '+outdir+'/Bampf.app /Applications '+outdir+'/Bampf.pkg'))
Caveats: while the script can also build a Windows executable when on a windows OS, it is not at the point where the application can be submitted to the Windows App store. Also Linux builds are stubbed at the moment.