By default, Xcode Server signs binaries using a development certificate, not a distribution one. Unfortunately there is no built-in option to make it use a Developer ID certificate. What’s the solution?
Notarization is a fully automated process, unlike going through the App Store which involves manual human review. At least it’s automated in Apple’s side. However it could consume a non-negligible amount of brain bandwidth in your side. How about automating it?
“I want a REST API for notarization since it’s impossible to parse text coming from the notarization tool reliably.” What if I say that the command line API is the best method for integration with build pipelines? Read on to find out more.
Distributing macOS apps as ZIP archives has been quaint since Sierra. Today’s macOS packaging requirements mandates notarization, otherwise it would say that your app is suspicious. This often means distributing apps within disk images since this container format can be signed, notarized, and stapled.
The long-rumored ARM Mac is on the horizon. With this comes the big work of porting and re-compiling current applications. But many Mac App Store apps are dependent on OpenSSL, which doesn’t yet support ARM on the Mac. Here is how you can continue to test your mac app while waiting for official OpenSSL support for the new hardware.
When you’re just starting out in iOS development, there are so many options in which to place a button. There’s storyboard, auto layout, and even SwiftUI — that’s just scratching the surface. How should someone new to programming the platform chart a learning path?
Do you distribute your macOS apps as .zip files? That has been quaint since Sierra. You should package your apps as signed and notarized disk images instead. Otherwise Catalina would say that your package is suspicious. However creating disk images is a rather involved process. Read on to find out more.
Distributing macOS apps within .zip files nowadays is no longer a good idea. One issue is app translocation. Another issue is the mandatory notarization starting from macOS 10.15 Catalina.
App translocation goes into effect when the user downloads a .zip file containing an application, extracts it, and runs it directly without moving it anywhere using the Finder. The operating system would run your app from a temporary read-only disk image created just for the purpose of launching your app. This has an unfortunate side effect of Sparkle being unable to update your app – which prevents you from delivering updates and bug fixes seamlessly to your user.
Notarization is the method to register your software packages to Apple when you distribute outside the App Store. The problem with packaging software inside a .zip file comes from the inability to attach the notarization result on to the archive. Therefore your user’s system would need to be online to check whether your software package has been notarized. Otherwise it would prompt a “macOS can not validate…” warning to the user, possibly causing suspicion to your package. However when the notarization result is stapled to your package, macOS can validate it without making a network connection to Apple.
Thus disk images is probably the best way to distribute application bundles outside the Mac App Store. Disk images can be signed, notarized, and stapled. When you distribute apps using disk images and Sparkle, your users would find it straightforwardly effortless to install, use, and update.
But creating disk images is an involved task for the developer. There are so many tasks involved to package an application into a disk image ready for the user. This includes:
Creating a blank read/write disk image for scratch-pad purposes.
Copying the application bundle inside the disk image.
Creating a symbolic link inside the disk image to the /Applications folder.
Setting a background image for the disk image’s Finder window to instruct the user to install the application bundle.
Use the Finder to carefully arrange the icons of the application bundle and the symbolic link to the /Applications folder to the background image, as well as any other additional content in the disk image.
Convert the scratch-pad disk image into a compressed read-only disk image.
Sign the disk image.
Upload the disk image for notarization.
Wait for notarization to complete.
Staple the notarization ticket on to the disk image.
That’s a lot of steps to do manually on each release. Thankfully all of those steps can be automated and added to your continuous integration environment. Hence you can automatically get a finished disk image on every release. Even if you don’t have a build server, integrating this to your Xcode build would be a snap. Read on to learn how to do this.
macOS Catalina is just around the corner and with it comes mandatory notarization and hardened runtime. If your mac app accepts plugins or otherwise loads 3rd party frameworks and libraries, there are a few caveats that you’ll need to take care.
Are you being hunted by Xcode command line tools? Have you uninstalled it only to realize that it came back again? If you already have the Xcode installed and really need the full IDE, don’t waste space by having the command line tools installed as well. Here’s how.