For years, tech reviewers have lamented that Apple’s iPad Pro is being “held back” by its software. The hardware is absurdly powerful—M4 chips that rival desktop processors, gorgeous displays, ample RAM—yet iPadOS will not let you do half the things macOS allows. No proper Terminal access. No kernel extensions. Apps locked in their sandboxes like well-behaved children at daycare.

The critics say Apple is artificially limiting the iPad to protect the Mac’s position in the lineup. I think they have it backwards.

What if iPadOS is not holding the iPad back—it is holding the fort? What if those “limitations” are not bugs but features? What if the iPad Pro is actually the more secure computing platform precisely because it refuses to give you enough rope to get yourself into serious trouble?

Let me make the case that the iPad’s locked-down nature is not a weakness—it is a masterclass in security design.

When Apple Threw macOS Under the Bus

In May 2021, something remarkable happened in a California courtroom. Craig Federighi, Apple’s senior vice-president of software engineering, testified in the Epic Games v. Apple trial. In a bid to defend iOS’s walled garden, he said something that must have made every Mac marketing executive wince.

“Today, we have a level of malware on the Mac that we don’t find acceptable,” Federighi told the court.

Read that again. Apple’s head of software engineering, under oath, admitted that macOS has a malware problem the company finds unacceptable. He went further, explaining that multiple app stores on the Mac are “regularly exploited” and that “iOS has established a dramatically higher bar for customer protection.”

Federighi compared the Mac to a car: “You can take it off road if you want, and you can drive wherever you want. There’s a certain level of responsibility required.” But iOS? “We were able to create something where children—heck, even infants—are able to operate an iOS device and be safe in doing so.”

This was not just courtroom theatrics. A 2020 Nokia Threat Intelligence Report that Federighi cited showed that across all observed network infections—phones, PCs and IoT devices—iPhones accounted for only 1.72 per cent, compared with 26.64 per cent for Android smartphones and 38.92 per cent for Windows/PCs. Apple’s own data showed the company blocks “many instances” of Mac infections affecting “hundreds of thousands of people” every week. Since May 2020, Federighi testified there had been 130 types of Mac malware, with one strain alone infecting 300,000 systems.

The company that built its reputation on Mac security essentially admitted: we do it better on iPad.

The Sandbox: Where Good Fences Make Safe Neighbours

Here is where iPadOS’s architecture diverges sharply from macOS, and it starts with sandboxing.

On iOS and iPadOS, every single third-party app runs in a mandatory sandbox. Each app gets its own isolated home directory, randomly assigned at installation. If an app needs to access anything outside its sandbox—your photos, your contacts, your microphone—it must explicitly request permission through system-provided services. The entire operating system partition is mounted as read-only. Apps cannot access files stored by other apps. They cannot make system-level changes. Full stop.

On macOS? Sandboxing exists, but it is complicated. Apps distributed through the Mac App Store must be sandboxed, yes. But Mac users routinely download and run apps from the internet, and those apps can have considerably more freedom. macOS even allows developers to create custom sandbox policies for their applications.

On platforms like iOS and iPadOS, by contrast, sandboxing is mandatory for third-party apps and there is no support for custom, developer-defined sandboxes. Modern macOS versions do use a sealed, read-only system volume, but the operating system remains far more permissive about what user-installed code it will run.

The result? If a malicious app somehow makes it onto your iPad, it is trapped in its little container, unable to roam freely across the rest of the system. On a Mac, that same app may have considerably broader access to your device, depending on how it was distributed and what permissions you have granted.

The Kernel: Apple’s Fortress vs. Apple’s Open House

Now let us talk about the kernel—the core of the operating system that manages everything from memory to hardware access. This is where iPadOS’s security advantages become almost unfair.

iOS and iPadOS employ something called the Page Protection Layer (PPL), a hardware-backed mechanism designed to enforce system-wide code integrity even if an attacker compromises the kernel. In simple terms, PPL walls off critical code pages so they cannot be silently modified at runtime, closing off entire classes of exploits that rely on changing code after it has been verified.

According to Apple’s own platform security material, this protection is not offered in macOS because PPL is only applicable on systems where all executed code must be signed. macOS is explicitly designed to run more arbitrary code—including unsigned or ad-hoc signed binaries—which prevents Apple from enforcing the same kernel-level protections that lock down iPadOS.

Then there are kernel extensions. On macOS, these pieces of code can run with full system privileges, accessing every corner of the operating system. They are powerful, but they are also dangerous. Apple has explicitly stated that kernel extensions “are no longer recommended for macOS” because they “risk the integrity and reliability of the operating system.” Yet macOS still supports them for backwards compatibility and to enable certain professional workflows.

Security researchers have found multiple vulnerabilities that exploited this very feature. In 2021, the “Shrootless” vulnerability (CVE-2021-30892) allowed attackers to bypass System Integrity Protection (SIP)—macOS’s core safeguard for critical system files—and potentially install rootkits by abusing how Apple-signed installer scripts were executed. Apple patched it in macOS Big Sur and Monterey. In late 2024, Microsoft discovered CVE-2024-44243, another SIP bypass that allowed attackers with root access to load unauthorized third-party kernel extensions, enabling persistent, stealthy malware and malicious drivers. That flaw was addressed in macOS Sequoia 15.2.

On iPadOS? Kernel extensions do not exist. The door is not just locked—there is no door.

Terminal: The Power Tool That Cuts Both Ways

Here is something Mac users take for granted: open Terminal, type sudo before a command, enter your password, and suddenly you have administrative privileges. You can modify system files, install software, reconfigure network settings—essentially rebuild your entire computing environment.

It is incredibly powerful. It is also a massive security liability.

Multiple sudo vulnerabilities have plagued Unix-like systems over the years, including macOS. CVE-2019-18634 allowed a local user to trigger a stack-based buffer overflow in sudo under certain configurations. CVE-2021-3156, dubbed “Baron Samedit,” let local users gain root privileges via a heap-based buffer overflow in sudo’s default configuration. More recently, CVE-2025-32462 and CVE-2025-32463 exposed yet another set of long-lived bugs in sudo that had been sitting in the codebase for over a decade, again enabling privilege escalation on mainstream Unix-like systems.

All of these flaws share a common trait: they turn a tool designed for legitimate administrative access into a highway for attackers to gain complete system control. These are not Apple-specific problems; they are structural risks inherent to exposing low-level administrative interfaces to end users.

iPadOS? There is no Terminal. There is no sudo. Apple’s documentation notes that “unnecessary tools, such as remote login services, aren’t included in the system software, and APIs don’t allow apps to escalate their own privileges to modify other apps or the operating system.” The attack surface simply does not exist.

What power users call a limitation, security professionals call attack surface reduction.

The App Store: Gatekeeping as a Feature

macOS lets you download applications from almost anywhere. Visit a developer’s website, download a DMG file, drag it to your Applications folder, and you are running third-party software. Apple has mechanisms like Gatekeeper and notarization to check these apps for malware, but determined users can and do bypass these protections.

iPadOS takes a different approach. Starting with iPadOS 18, users in the European Union can install apps from alternative app marketplaces or directly from developers' websites, thanks to the Digital Markets Act. But this remains a geographically limited exception to a baseline model where every app comes through the App Store. Every app is reviewed. Every app is signed. The closed ecosystem is not about control for control’s sake—it is about maintaining a security boundary.

The iPad ecosystem is deliberately designed so that malware finds it extremely hard to get a foothold in the first place. Apps are compartmentalized, so even if a malicious app downloads additional payloads, it cannot easily infect the entire device.

Yes, this means most users cannot sideload applications. Yes, this means Apple acts as gatekeeper. But for the vast majority of users—the ones who are not compiling their own software or running server infrastructure—this trade-off makes their device dramatically more secure.

When “Limitations” Become Liberations

The tech commentariat loves to frame this as Apple “crippling” the iPad to protect Mac sales. The security reality is more nuanced.

Apple designed iPadOS to be secure by default, secure for everyone, and resilient even when operated by users who have no idea what a kernel extension is or why sandboxing matters. The “limitations” are not arbitrary restrictions imposed by bean counters in Cupertino; they are deliberate architectural decisions that create a fundamentally more secure computing platform.

Apple now states publicly that the only system-level iOS attacks observed in the wild come from mercenary spyware—extremely sophisticated exploit chains, historically associated with state actors, that cost millions of dollars to develop and are used against a very small number of high-value targets. Commodity, at-scale malware campaigns simply do not land on iOS and iPadOS in the way they do on traditional desktop platforms.

Think about what that implies. On iPadOS, attackers at scale are effectively priced out of system-level compromise; only nation-states and their contractors can afford to play. On macOS, by contrast, Apple itself acknowledges an “unacceptable” level of malware, with weekly campaigns impacting hundreds of thousands of systems.

Your iPad is not being held back by its software. It is being protected by it.

The Paradox of Professional Computing

Here is the uncomfortable truth for those of us who grew up with beige boxes and command prompts: professional-grade power and consumer-grade security do not always coexist peacefully.

macOS offers flexibility because certain professional workflows genuinely demand it. Developers need to compile code and run local servers. Systems administrators need Terminal access. Security researchers need low-level hooks. Creative professionals need to run specialized software that may never appear in the App Store. These are legitimate needs, and macOS serves them well.

Those users are also critically important to the ecosystem; they build the software, infrastructure and content that everyone else relies on. Their work just happens to come with inherently higher risk and a higher expectation of security literacy.

But most people are not developers or sysadmins. Most people check email, browse the web, manage documents, edit photos, consume media, and maybe do some light creative work. For these users—which is to say, for most professionals as well—an M4 iPad Pro running iPadOS is not just powerful enough. It is more secure than the equivalent Mac precisely because it refuses to give them the keys to the kingdom.

You do not need sudo privileges to write a novel. You do not need kernel extensions to edit a podcast. You do not need to disable System Integrity Protection to create a presentation. By not offering these capabilities, iPadOS eliminates entire categories of security vulnerabilities from the threat model of ordinary users.

A Different Kind of Pro

Maybe it is time we redefine what “pro” means in computing.

The iPad Pro is not professional despite its limitations—it is professional because of them. It is a computer that protects your data even when you are not paying attention. It is a platform that assumes you have better things to do than maintain security hygiene. It is a device that can move from a child’s hands to a corporate boardroom without requiring a full-blown security audit in between.

That is not a computer being held back. That is a computer that has been thoughtfully designed for the way billions of people actually use technology, and for the threat landscape they actually face.

The next time someone tells you the iPad is handicapped by iPadOS, ask them this: compared to what? A platform with “unacceptable” levels of malware, according to its own creator? A system with regular kernel-level vulnerabilities and a long history of command-line privilege escalation bugs? An operating system that requires constant vigilance and technical knowledge to keep secure?

The iPad’s greatest limitation is also its greatest achievement: it will not let you casually destroy your own security posture. In 2025, with nation-state hackers, ransomware gangs and mercenary spyware firms prowling the internet, that may be exactly the kind of limitation we should be optimizing for.

Keywords: #iPadPro #iPadOS #AppleSecurity #CyberSecurity #InfoSec #ThreatModeling #ZeroTrust #SecureByDesign #EndpointSecurity #MobileSecurity #MacOS #SecurityArchitecture #Sandboxing #KernelSecurity #AttackSurface #DigitalRisk #Ransomware #Spyware #MercenarySpyware #NationStateThreats #Privacy #DataProtection #CISO #SecurityLeadership #EnterpriseIT #CloudAndSecurity #DeviceStrategy #ProWorkflow #SecurityVsConvenience #AppleEcosystem #BoardroomSecurity #SecurityFirst #TechOpinion #SecurityBestPractices #CyberResilience

—

Ethics Statement and Disclaimer

Personal Views: The opinions, analysis and conclusions expressed in this article are solely those of the author and do not reflect the views, positions, strategies or opinions of the author’s employer, any affiliated organizations, clients, partners or colleagues. This article was written in a personal capacity, and the author accepts full responsibility for its content.

Transparency: This article represents the author’s independent analysis and opinion. While the author works in the cybersecurity field, the views expressed here are personal and were developed outside the scope of employment responsibilities. No confidential, proprietary or non-public information has been used in preparing this article.

Methodology: The security comparisons in this article are based on publicly available technical documentation, independent security research, court testimony and vulnerability disclosures from Apple, Microsoft, Google and independent security researchers.

Limitations: This analysis focuses specifically on architectural security differences between iPadOS and macOS. It does not address all security considerations, including physical security, cloud services, user behaviour or enterprise deployment scenarios. Security is multifaceted, and no platform is completely immune to threats.

Objectivity: The author has attempted to present technical facts accurately while acknowledging that both platforms serve different use cases with different security trade-offs. This article argues for one perspective but recognizes that reasonable people may prioritize flexibility over security constraints.

No Conflicts of Interest: The author has no financial relationship with Apple Inc., does not own Apple stock beyond standard index funds and receives no compensation from Apple or its competitors. This article was written independently and was not sponsored, reviewed or approved by any technology company prior to publication.

Reader Responsibility: This article is for informational and educational purposes only. Readers should conduct their own research and consult with qualified security professionals before making technology purchasing decisions or implementing security policies. Security requirements vary significantly based on individual threat models and use cases.