Recently I needed to submit a Python app to the Mac App Store. Since there seemed to be no good documentation online for doing this, I had to figure it out myself. Here’s what I learned:
Below I will explain how to make a Python script into a Mac App Store app. I would recommend that you download my example Python app that can be submitted to the Mac App Store and examine its build system while reading the rest of this article.
First, I assume you already have a Python script that you’d like to package as an application and submit.
My example app uses src/HelloAppStore.py
as the main script.
A Python script, along with its included Python modules and dependencies, can be bundled into a regular Mac app using py2app.
I won’t repeat the py2app documentation, but you generally need to create a setup.py
file that looks something like this:
from setuptools import setup
APP = ['src/HelloAppStore.py']
DATA_FILES = []
OPTIONS = {
'argv_emulation': True,
#'iconfile': 'src/Icon.icns', # optional
#'plist': 'src/Info.plist', # optional
}
setup(
app=APP,
data_files=DATA_FILES,
options={'py2app': OPTIONS},
setup_requires=['py2app'],
)
Then you can build dist/HelloAppStore.app
into a nice double-clickable app by running the command:
python setup.py py2app
My example app runs the above command as part of the ./build-app.sh
script.
There are several additional nontrivial restrictions that must be satisfied before an app can be submitted to the Mac App Store:
An exhaustive list of restrictions can be found in the Mac App Store Review Guidelines.
Mac App Store apps must be sandboxed. Sandboxed apps are restricted in several ways, but the most significant restriction is the inability to read/write arbitrary files.
In particular an app cannot write to a file outside of its sandbox container unless a native1 open/save dialog is used to prompt for the location of the file or the file already resides within the app’s container directory.
It’s a good idea to read the App Sandboxing documentation to understand the full set of restrictions and how to overcome them when necessary (and when possible).
My example app enables sandboxing by specifying that com.apple.security.app-sandbox = true
in the src/app.entitlements
file. This entitlements file is used in the code-signing process described in the next section.
Mac App Store apps must be code-signed. This means you must go through some extra hoops to generate signing certificates, download them to your dev machine, and alter your build script to sign the final app package with it.
These certificates have to be generated by Apple as part of your Mac Developer Program subscription ($99/year). And renewed annually if you wish to continue making app updates.
Since Python apps are built outside of Xcode, you’ll have to use the codesign
tool manually to sign your app.
My example app runs the codesign
tool as part of the ./build-app.sh
script, recursively signing the inner frameworks, helper tools, and finally the outer application binaries. As part of the signing process the application binaries are also embedded with entitlements, which are used to enable sandboxing.
See the Code Signing Guide for more information about manual code-signing.
Your Python script probably won’t be directly using any deprecated APIs. However your Python script might depend on other libraries that do. Such dependencies can be difficult or impossible to eliminate. Typically you have to modify and recompile the dependency manually.
In particular the very popular wxPython GUI toolkit depends on deprecated QuickTime APIs at the time of writing, making any Python app that depends on it inadmissible to be submitted to the Mac App Store.
My example app has no workarounds for deprecated APIs.
Your Python script probably won’t be directly using any old PowerPC code. However, again, your Python script might depend on other libraries that do. In fact Python 2.7 itself includes PowerPC code.
Luckily any PowerPC code can be stripped out easily using the lipo
tool, so you just need to add some extra lipo
commands to your build script.
My example app uses lipo
in the ./build-app.sh
script to remove PowerPC code from the python2.7
library.
If you don’t have an app icon you’ll have to create one. If you do already have an app icon, I’ll bet you it doesn’t meet the minimum 1024x1024 pixel size requirement.
Creating an icon entails creating several images for your icon at various specific sizes, and then using the iconutil
command to generate a final .icns
icon file.
My example app contains a ./build-icon.sh
script that can be used to generate src/Icon.icns
from images in the src/Icon.iconset
directory.
See the Icon Design Guidelines in the OS X Human Interface Guidelines for more information about creating icons.
The Info.plist
file inside a Mac App Store app is required to specify what category on the Mac App Store it belongs to under the LSApplicationCategoryType
key.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
...
<key>LSApplicationCategoryType</key>
<string>public.app-category.reference</string>
...
</dict>
</plist>
So far as I can tell, the set of valid values for this key is not documented anywhere. Therefore to find new values, I created a new Cocoa Application project in Xcode (where I could specify the app category in a dropdown), compiled the app, and opened its Info.plist
file to see what value it had for the LSApplicationCategoryType
key.
Regular apps written in Objective-C for the Mac App Store are usually submitted directly from within Xcode. This is not an option for Python apps that you build outside of Xcode.
Instead you have to use an older app submission tool called Application Loader to upload your app. However Application Loader doesn’t submit a .app
package directly; it requires an installer .pkg
instead.
An installer package can be built from your .app
using the productbuild
tool.
My example app runs the productbuild
tool as part of the ./build-pkg.sh
script which creates an installer package containing the app.
For more information about the productbuild
tool, see its man page.
Hopefully you should now have a good idea of what is involved in submitting a Python app to the Mac App Store.
If you’d like to actually try out the process of submitting an app, try building and submitting my example app using the instructions in its README.
Please send comments and corrections to David Foster.
Therefore if you are using a GUI toolkit that uses a simulated open/save dialog rather than a native one, your app won’t be able to access the files the user selects!↩