Are Mac Catalyst apps subject to the same code signing requirements and associated distribution restrictions as iOS/iPad apps? I wrote a small Catalyst app on my laptop and was not able to run the resulting binary on another Mac, it crashed with a code signing error and I had to recompile it on the target computer. I also assume that binary will stop working after a short period of time and require re-signing. I was hoping Catalyst apps would have the less restrictive Mac app requirements but it doesn’t appear so, and I would need to pay $99 to create a binary that stays usable indefinitely.
Catalyst Requires Code Signing?
Are Mac Catalyst apps subject to the same code signing requirements and associated distribution restrictions as iOS/iPad apps?
No. In general, Mac Catalyst apps are Mac apps and follow the Mac code signing rules. For example, it’s perfectly valid to distribute a Mac Catalyst app outside of the Mac App Store (MAS) using Developer ID.
Having said that, this isn’t quite what you’re asking. You wrote:
I wrote a small Catalyst app on my laptop and was not able to run the resulting binary on another Mac
The canonical way to create a non-MAS Mac app that runs on other Mac is to use Developer ID signing. Doing anything else will result in you bumping into various roadblocks. There are two things to consider:
-
Gatekeeper
-
Other trusted execution subsystems
On the Gatekeeper front, your scenario requires that the user bypass Gatekeeper. Gatekeeper will only accept MAS apps and notarised Developer ID apps.
Once you’ve bypassed Gatekeeper it should be feasible to run your app. There are, however, some further gotchas:
-
Apple silicon Macs require that all code be signed in some way. You can use ad hoc signing (Sign to Run Locally in Xcode) to satisfy this requirement.
-
Mac Catalyst apps always use the data protection keychain, and you can’t do that without a provisioning profile. For more background on Mac keychain APIs and implementations, see On Mac Keychains.
-
Ad hoc signed code has all sorts of limitations. For example, the TCC subsystem (System Preferences > Security & Privacy > Privacy) uses your app’s code signature to confirm that version N+1 of your app is equivalent to version N, and that requires a stable code signing identity, which ad hoc signing does not provide.
Notwithstanding all of the above, I was able to build an ad hoc signed Mac Catalyst app on one Mac and run it on another.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
HomeKit requires the com.apple.developer.homekit entitlement, which must be allowlisted by a provisioning profile. You won’t be able to do that on the Mac without a paid developer account.
FYI, these pages are super handy:
They tell you which capabilities are available for which deployment models on which platforms. For example, the HomeKit entitlement is only available for App Store apps on macOS (not even Developer ID, which surprised me) but is available to all deployment models on iOS (which I also found surprising, in that often such things are not available to a Personal Team).
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
can I still sideload the app on my server?
You can, with a significant caveat. You can get a development-signed running on your server in the same way you get it running on any Mac, by adding the server’s provisioning UDID to your provisioning profile [1]. The caveat is that development certificates expire regularly (once a year?) and you’ll need to update the app accordingly.
Note that my reply is entirely from the perspective of code signing. I’m not an expert on HomeKit, so I’ve no idea what HomeKit-specific restrictions might be in play here.
[1] See What exactly is a provisioning profile? for more background on this.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"