Improvements for macOS App Store submissions in install4j 11.0.2
install4j 11.0.2 introduces several new features to simplify macOS App Store submissions, including automated entitlement handling for TestFlight, improved support for local testing with development provisioning profiles, and dynamic bundle versioning for easier resubmission of builds.
Background
Submitting a Java app to the Mac App Store can be a daunting task. Understanding the involved concepts and fulfilling the many requirements set by Apple is much easier when you have install4j to help you reach the finish line.
Since install4j 10.0, "the single bundle archive" media file type in install4j has an App Store submission mode that generates a .pkg installer that supports an optional "provisioning profile".
In addition, the launcher has several settings that are relevant for a successful App Store submission.
To be able to submit an application, the bundle identifier for the launcher must match the configured ID in App Store Connect. Since apps in the App Store run in a sandbox, they cannot even open a file without requesting the appropriate "entitlement". These fine-grained permissions can be requested in the entitlements file. Finally, the application category is a required attribute for an App Store submission.
Provisioning profiles
To complicate things, Apple has two different sets of entitlements. Some entitlements such as "com.apple.developer.applesignin" and "com.apple.developer.icloud-service" require a provisioning profile. This is an artifact that you create in your Apple Developer Account under "Certificates, Identifiers & Profiles".
In addition, using TestFlight is only possible when a provisioning profile is specified and the same "com.apple.application-identifier" and "com.apple.developer.team-identifier" attributes are also present in the entitlements file. Starting with install4j 11.0.2, these values are automatically copied to the entitlements by install4j, so using TestFlight is enabled as long as you use a provisioning profile.
Code signing certificates
Code signing for the App Store is further complicated by the fact that you need certificates of the types "Mac App Distribution" (for the app) and "Mac Installer Distribution" (for the .pkg installer). For each certificate, you have to generate a certificate signing request in the Keychain app, create the appropriate certificate in the Apple Developer Account, and import the certificate in Keychain.
When exporting from your Keychain, you have to add these certificates together with their private keys and specify the PKCS#12 file in install4j. If you also distribute non-App Store builds, you will also need to include an "Apple Developer ID" certificate. install4j automatically chooses the correct certificate from the specified PKCS#12 keystore.
Local testing
If you want to test the sandboxed environment of your app, you may want to install the generated .pkg file before submitting it to the App Store. However, if you use an App Store provisioning profile, such an installation will fail.
Instead, you have to use a "macOS App Development" provisioning profile and install it on your local machine. A development provisioning profile is associated with certificates of the type "Apple Development" or "Mac Development". This means that you have to change both the provisioning profile and the code signing certificate to create a development build.
Before install4j 11.0.2, using certificate types other than "Mac App Distribution" or "Mac Installer Distribution" for App Store code signing was not supported, so using development provisioning profiles was not possible.
If you do not require the special entitlements that are only available via provisioning profiles and you do not need to use TestFlight for testing, you can opt to not use a provisioning profile at all. In that case, the generated .pkg will be installable on your local machine even when signed with the distribution certificates.
Resubmitting builds
Another App Store-related improvement in install4j 11.0.2 is that the CFBundleVersion attribute is now set to a timestamp to allow submitting multiple builds with the same version to the App Store. Previously, you would have to change the user-facing version if a build was rejected by the App Store.
Ready to simplify your macOS App Store submissions? Download the current version of install4j and try it yourself.