Apple's EU pilot for iOS sideloading launched in Germany, and the security discourse immediately split into two camps: people who think Apple's walled garden is the only thing standing between your phone and ransomware, and people who think Tim Cook invented the walled garden to collect 30% commissions. Both camps are wrong in useful ways.
Here is what the data actually shows. Kaspersky's 2025 study found that 23% of mobile malware comes from apps installed outside official stores. That sounds alarming until you remember that the App Store has shipped spyware, scammy subscription traps, and cloned banking apps that passed review. Official vetting is not a guarantee; it's a filter with known holes. The 23% stat tells you sideloading carries elevated risk. It does not tell you the App Store is safe.
The Friction Is the Feature
What Apple built for EU sideloading is not Android's "Unknown Sources" toggle. You need developer profile approval. There's a notarization step. The Germany pilot added complexity that frustrated some users and that friction is doing real work. Compare it to Google's new Android "advanced flow": a 24-hour wait, developer mode unlock, and multiple warning screens before an APK installs. Both companies are betting that inconvenience deters the casual user who would otherwise tap "install" on a fake Fortnite APK from a Discord link.
That bet is mostly correct. The threat model for sideloading isn't a sophisticated attacker who already has your credentials. It's phishing: a convincing fake app page, a user in a hurry, one tap too many. Symantec expects scam campaigns targeting new iOS sideloaders specifically because the population is unfamiliar with the flow. The attack surface expands when users don't know what a developer profile is or why they're being asked to trust one.
I'll grant Apple's critics one fair point: the App Store's review process has failed badly enough, often enough, that "just use the App Store" is not a complete security argument. But the answer to a flawed filter isn't no filter. It's a better one, with user education attached.
What Actually Gets People Compromised
The March 20 Apple security alert is more instructive than the sideloading debate. The Coruna and DarkSword exploits hit devices running iOS older than 15, via web-based attacks, no sideloading required. If you're running iOS 14 on an iPhone 6s because "it still works fine," a malicious link in your email is a bigger threat than anything in an alternative app store. The attack vector is neglected updates, not installation source.
A Hacker News commenter put it well in late March: FDroid, the Android sideloading store, holds 0.2% of Play Store's app volume. Its apparent safety record comes from being too small to bother attacking, not from superior code review. Scale changes everything. As iOS sideloading grows past the early-adopter crowd, that obscurity protection disappears.
So here's the actual tradeoff for builders and power users: sideloading on iPhone is manageable if you treat it like you'd treat adding a third-party dependency to a production codebase. You check the source. You read what you're granting. You don't install from a link someone DMed you. You keep iOS current. That's not a high bar. Most developers already operate this way with npm packages, and those can absolutely wreck your build.
Apple should publish clear, plain-language documentation on what notarization actually checks and what it doesn't. Right now that gap is where the phishing campaigns will live. Fill it before Q3 2026, when Google's Play Protect sideload scanning ships and makes Android look more thoughtful about this than iOS.
