As macOS and iOS keep getting closer in terms of functionality (including low-level fundamentals and a shared software platform), I hear a lot of fear from Mac users who are concerned that the Mac is in danger of becoming a locked-down platform that will lose a lot of the capabilities that advanced users have come to expect from their devices.
The security philosophy Apple has nurtured over the past decade as it has built iOS is one that’s based on strictly limiting what third-party software can do, in turn limiting what users are able to do. But I’m optimistic that Apple isn’t planning on barring Mac power users from some of the best things about using a Mac, and there are many ways Apple can create a fundamentally more secure platform without destroying its appeal.
Trust but verify
Despite the fear that the introduction of the Mac App Store meant that Apple would eventually limit the Mac software market to App Store apps only, that has never happened. In part, this is because a huge array of important Mac apps have not qualified for inclusion in the Mac App Store, something Apple seems now to be dedicated to rectifying.
But Apple has also spent the last few years finding alternate paths to offer software security outside of the Mac App Store—an approach that I doubt the company would bother with if it was planning on dropping the hammer and killing all non-App Store apps.
With the introduction of Gatekeeper, Apple began differentiating between Mac App Store apps, apps that had been created by known Apple developers outside the App Stores, and apps with unknown provenance. Macs can be set to refuse to launch non-App Store software, or they can run pretty much anything—it’s the call of the administrator of that device.
Last summer, Apple introduced a new concept for Mac software distribution outside the Mac App Store, something called “notarization.” Just as the older approach allows Apple to recognize registered developers—and turn off their accounts if they’re creating malware—this new approach requires developers to pass their apps through an automated process at Apple. Apple gets the ability to flag any problems it sees, and retains the ability to shut off individual apps from a developer, rather than the entire output of an account.
Yes, it’s possible that Apple could use this approach to ban most third-party apps outside of the App Store, but I don’t think that’s the intent. Instead, I think this is yet another example of how Apple wants to gain some of the benefits of App Store-style security without forcing every piece of Mac software through the Mac App Store.
Turn on developer mode
The beauty of all of Apple’s software security features on the Mac thus far is that you can turn them off. We’ve not yet reached the point where legitimate third-party Mac software is entirely unable to reach an audience, and I hope we never do.
That said, I think there’s a strong argument to be made that by default the Mac should be as safe and secure as possible. Most Mac users are not particularly technical, and they may be induced to make bad choices that could potentially make them vulnerable to malware. The more locked down the Mac can be made by default, the better.
But for the rest of us, those who have old software we love, who develop software, who install systems like Homebrew to compile and run command-line utilities and shell scripts… we demand more. And there’s nothing stopping Apple from granting it.
One of the first things I did when I got a Chromebook was to figure out how to install Linux on it. Google keeps Chrome OS pretty locked down by default, but you can enable a special developer mode that lets you do pretty much want you want with your device.
Apple already allows users to set what level of apps are allowed to be run. And beginning with El Capitan, Apple launched System Integrity Protection, another boost to security that limits the modification of system files—which advanced users can turn off if they so desire. Similarly, on Macs with a T2 processor, the Secure Boot feature verifies the operating system against a known cryptographic signature—but you can likewise turn it off.
It’s a little scary to turn off security features—which is good. Most users probably shouldn’t turn them off. But as long as Apple provides ways to turn them off, or better yet, allows users to enable an explicit power-user or developer mode, the truly committed will still be able to do what they need to do.
It works both ways?
And if increasing security while providing a developer mode works on macOS, let me make another suggestion: Apple should consider adding a similar feature on iOS.
Yes, yes, I know that iOS has been locked down by Apple for its entire existence. But as devices like the iPad Pro gain the power of traditional laptops and increasingly attract users who want to take advantage of that power and the ecosystem of iOS apps, some of those users will want to do more than Apple has been comfortable offering on iOS up to now.
The solution is to offer some of those features behind an explicit developer mode, turned off by default. Let those of us who want to compile software and run shell scripts and the like do so—in an authorized way, limited to only those who really want to take advantage of those features.
I doubt that Apple will ever embrace the idea of allowing users to install any old app they want, from any source, on iOS—that method of bypassing the App Store would be an open door for piracy and malware—but there are some power-user doors on iOS that could be opened to users with knowledge, desire, and perhaps an Apple developer’s certificate.
But even if Apple doesn’t move to make iOS more like macOS by opening it up to power users, I am optimistic that we won’t be locked out on macOS. So far, Apple has been following a clear strategy: keep adding ways to make the platform more secure while also letting users who care turn those features off. If that strategy leads to a developer mode for macOS, I’ll applaud—and then I’ll turn it on.
When you purchase through links in our articles, we may earn a small commission. This doesn't affect our editorial independence.