Heads up... You're reading this book for free, with parts of this chapter shown beyond this point astext.
If you’re reading this book in order, you have a pretty good grasp of how to bring an iPhone or iPad app to macOS. Now it’s time for the next step: getting your app into the users’ hands.
Fortunately, once you have a Mac app, you can use Catalyst to choose how to distribute it. There are four ways to distribute your app:
- The App Store: The Mac App Store works almost like the iOS store. Since iOS apps already follow Apple’s app review guidelines, you shouldn’t have any issues going through app review. You can either release your app as a standalone Mac App Store product or offer a universal purchase so that your customers can buy your app on one Apple platform and have it everywhere else.
- Third Party Distribution: As long as you sign the app and have it notarized by Apple, anyone can simply download and launch it. The distribution, in this case, is up to you.
- Developer Signing: Similar to third-party distribution, you must sign your app with a development certificate. You can’t use this option for distributing to the general public because the certificate includes an allowlist of specific devices that can install the app. In the past, this was your best bet for testing the app in development because macOS didn’t have TestFlight support until 2021.
- Test Flight: Towards the end of 2021, Apple finally included TestFlight support for macOS apps. Test Flight is a service you can use to distribute beta versions of your app to your testers. Before you release your app, you can collect valuable feedback from the testers and improve your app.
If you made your Catalyst app in Xcode 11.3 or earlier, there are a few steps you need to take to get your app up to speed.
Updating Existing Catalyst Apps
Before Xcode 11.4, Catalyst apps had an automatically-assigned bundle ID with a maccatalyst. prefix. If you want to offer a universal purchase or just want a custom bundle ID, you’ll have to make a quick change.
Go back to your main target’s settings and open the Build Settings tab. Scroll down to the User-Defined section and set DERIVE_UIKITFORMAC_PRODUCT_BUNDLE_IDENTIFIER to NO. This setting tells Xcode to stop generating a bundle ID automatically and let you change the bundle ID in the Signing & Capabilities tab.
From there, you decide how you want to distribute your app.
The App Store vs. Third-Party Distribution
Since developer signing is only for testing, you’re probably trying to decide whether to use the App Store or distribute the app independently. Each approach has pros and cons. The App Store has several benefits, including:
Adding Your App to the App Store
Distributing your app via the App Store is tedious but straightforward. All you have to do is click a bunch of things! Before you get started, take note of some basic terminology you’ll need while going through this process.
Xcode does an excellent job of automatically code signing your app. As the name suggests, code signing is a way of verifying that you wrote the code inside the app and that it hasn’t changed since you wrote it. Code signing is required before a user can install an app on a device. Your signature is a distribution certificate that you get from Apple and is unique to your developer account.
Setting up an App ID
First, you need to create your app’s app ID. You’ll do that in Apple’s developer portal.
Adding an App Entry
Note: If you already have an existing app entry on App Store Connect, skip to the next section.
Uploading a Build
Your app entry can hold apps for multiple platforms and versions of each of those apps. You’ll see a new macOS App section and a new version called 1.0 Prepare for Submission. Now you have a place to upload your app.
Testing Your App With TestFlight
Now that you have everything filled out, it’s good practice to make sure everything works as intended before releasing your app to the world. This is where TestFlight kicks in.
Beta Testing Inside Your Team
Go to the TestFlight tab, where you’ll manage all your beta testing. Here, you’ll see a list of your builds available for testing. Each build is available for testing for 90 days after uploading. Usually, that won’t be an issue since there’s no need to test old builds!
Adding External Testers
Before you add any external testers, there are a few things you have to fill out.
Releasing Your App
You uploaded your build, filled out all the necessary metadata and even tested to make sure it works. All that’s left is to release your app to the App Store masses.
Pricing Your App
In the App Store tab, go to Pricing and Availability in the sidebar. Set the price of your app under Price Schedule. You can choose from almost 100 different pricing tiers for your app. Each of the tiers has a roughly similar price in all currencies. Once you select a price, click Other Currencies to see the exact values in each territory.
Submitting for Review
Once you’ve filled everything out, click Save in the top-right corner and click Submit for Review. A reviewer from Apple will look at your app to ensure you followed the guidelines. This may take a few hours to a few days.
Selling Your macOS App Separately
By default, Xcode sets up your project to offer a universal purchase, meaning that users buying your app on the iOS app store get it for free on macOS. With this approach, you might forego the income you’d usually get from a single user, but you give your users a better experience and value for the same price. If your macOS and iOS apps are the same and there’s a reason to expect users to want to have both versions, consider offering a universal purchase.
- You must sign each app with a provisioning profile, which combines a certificate with an app ID.
- You create app IDs in Apple’s Developer Portal.
- Manage the app on the App Store by going to App Store Connect.
- Upload new builds from Xcode.
- Test beta versions of your app with internal and external testers using Test Flight.
Where to Go From Here?
To ensure you’re not violating any of Apple’s guidelines, carefully read through Apple’s App Store Review Guidelines. Apple also provides a helpful list of common app rejection reasons. Use it as a checklist before submitting.