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?
Continuous testing is paramount to ship serous software. Yet continuously running tests is a pensive productivity plight. Is it possible to automate testing? Yes you can.
Xcode 13 brought a new notarization tool. What is it and how much better compared to the old one?
“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.
Notarization may take just a few clicks in Xcode, but this takes time and a security risk. You include notarization as part of your continuous delivery pipeline. Here’s how.
Distributing binaries for macOS outside the App Store requires registering it with Apple beforehand—notarizing it. But do you know what can be submitted for notarization?
Being in the “bleeding edge” has its drawbacks in addition to benefits. Blazing a fresh trail means it’s more rough and plenty of unknowns. Similarly in open source software, support for the ARM architecture is slim and even slimmer on the Mac. But there is a way to run “legacy” Intel-only command line apps on the Mac.
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.
Publishing similar apps is considered spamming. Yet there are valid reasons to develop multiple apps from the same code base. Here is what you need to know to avoid being labeled as spammer by app reviewers.
Some developers’ app updates were rejected from the App Store because their apps look similar. Worse, some others were marked as spammer due to publishing apps that looks like another developer’s app. How can you avoid this?
It would be a big blow when Apple rejects your suite of apps, call it “spam” and tell you to move into a container app. If this is happening to you, then this article would be a solution to your predicament.
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.
Being a white-label app vendor in Apple’s store is not easy. App Review could label you as a spammer because of a number of similarly-looking template apps and jeopardize your entire developer account.