Apple's "notarisation" – blocking software freedom of developers and users

2025-11-085:37297177fsfe.org

The EU’s Digital Markets Act is supposed to shake up the power of tech giants by giving developers and users more choice. Apple’s “notarisation” of mobile ...

News

on:

The EU’s Digital Markets Act is supposed to shake up the power of tech giants by giving developers and users more choice. Apple’s “notarisation” of mobile apps contradicts these objectives. A civil-society complaint against Apple’s monopolistic control over app distribution aims to change that.

Digital Markets Act (DMA) aims for a structural reset of power in digital markets, a shift from corporate control toward device neutrality, where users decide what runs on their devices. For Free Software, this legislation can be a unique opportunity by finally opening closed ecosystems - like iOS - to Free Software alternatives. Apple has reacted aggressively against the DMA, litigating against regulators, and unfairly excluding Free Software from iOS and iPadOS by blocking the unfettered installation of software (sideloading), prohibiting alternative app stores, and hindering interoperability.

The FSFE has recently contributed to a complaint initiated by civil-society organisations targeting Apple’s non-compliance with the DMA, urging the European Commission to enforce the DMA’s rules related to interoperability and the app store, giving users and developers effective choice over which apps and app stores they want to use on their devices. This complaint is important for software freedom, contextualising the diverse approaches towards curation of software distribution.

The action taken: calling out the illegality of Apple’s “notarization” of mobile apps

Imagine that you are a Free Software developer willing to make your program available in the iPhone. You want to have your software curated in a non-profit Free Software-friendly app store (like F-Droid for Android). This is important for you because you prefer to not have Apple controlling what your software does and to whom it should be made available.

This all sounds good, until you realise that your plan is not possible in iOS. There is no non-profit Free Software app store available for iPhones and iPads. Apple blocks non-profit app stores with extremely high financial requirements and prohibits unfettered installation of software. Even for the Free Software commercial ones, such as the Alt Store, Apple still applies a complete review and control, through an encryption layer over distributed source code.

On October 22, ARTICLE 19 and Gesellschaft für Freiheitsrechte (GFF) filed a complaint against Apple for non-compliance with the DMA to tackle these issues. The complaint highlights the following conduct as illegal under the DMA:

  • Apple does not allow the unfettered installation of third-party software (sideloading);
  • Apple prevents third-party app stores to effectively running on iOS and iPadOS;
  • Apple does not provide effective free-of-charge interoperability with the company’s features controlled via iOS and iPadOS.

The core of the complaint is twofold:

  1. Apple’s complete review of apps – known as “notarisation” process - a mandatory step for distributing any software on its platforms, represents the very gatekeeping behaviour the DMA was written to prevent.
    Notarisation forces all apps, even those distributed outside Apple’s App Store, to be submitted to Apple’s servers for scanning, approval, and cryptographic re-signing before installation. The result is that Apple retains full control over what software users can install and how developers can distribute it. This transforms Apple’s self-appointed “security review” into a choke-point of power, locking in developers and users into the company’s proprietary ecosystem.

  2. Apple’s requirements for third-party app stores.
    Apple has conditioned the provision of a third-party app store as a native app in its iOS and iPadOS on (1) providing a standby letter of credit in the amount of €1,000,000 from a financial institution that is at least A-rated; or (2) being a member of good standing in the Apple Developer Program for two continuous years or more and have an app that had more than 1,000,000 first annual installs on iOS and iPadOS in the EU in the prior calendar year.

Both requirements are extremely unfair and disproportionately affects non-profit Free Software projects, SMEs, startups, and individual developers. This discriminates by size and renders the market inaccessible to smaller new entrants.

The implications of Apple’s notarisation for software freedom

For Free Software developers, the implications are even more severe. Apple’s notarisation regime requires developers to hold a paid Apple Developer account, accept restrictive legal terms, and submit binaries to a closed, opaque process. Once approved, the binaries are re-signed by Apple and distributed under digital restriction management (DRM).

This breaks users’ rights when it comes to Free Software freedoms. Users can no longer verify that the source code they read corresponds to the binary they run, nor can they freely redistribute software that Apple refuses to notarise. What makes this process absurd is that Apple applies this notarisation process to all apps running on iOS, no matter which channel of distribution. This means that a developer of an alternative app store for iOS has actually no control over the apps they can distribute in their store, as Apple still holds gatekeeping power through notarisation.

Under the DMA, gatekeepers must enable the installation of third-party app stores and refrain from imposing unnecessary technical restrictions. Yet Apple’s notarisation enforces the very dependency the DMA prohibits: it reasserts Apple’s role as the mandatory intermediary for every app on its platforms. This undermines competition, discourages independent developers, and excludes non-commercial, community-run projects that cannot afford to submit to Apple’s terms or refuse to submit to them. Allowing this practice to persist would water down the DMA’s promise before it is even tested.

Blocking alternative app stores with extremely high requirements

Apple’s requirements for enabling third-party app stores are very hard to meet. They have effectively prevented non-profit Free Software app stores from working in iOS and iPadOS. The provision of a 1 million euro standby letter of credit or 1 million downloads within a year in the EU overburdens not only non-profits, but also individual developers, startups, and SMEs. When these conditions are put into context, such requirements do not reflect industry standards and expectations. They derive from Apple’s monopolistic behaviour with respect to mobile devices. Such impositions do not exist in Apple’s laptops and desktop computers, where unfettered installation (sideloading) is a reality. The complaint concludes that both requirements go beyond the limits of what is necessary under the DMA. Apple ignores less restrictive alternatives (e.g. insurance and escrow frameworks), and provides no justification for doing so.

The solution: decentralised software curation

The complaint surges the European Commission to impose fines and to find an alternative to Apple’s control over software distribution, including non-profit stakeholders in the process. The alternative to Apple’s notarisation already exists, and it works. Decentralised curation, as practised by repositories like F-Droid, shows that security and software freedom coexist inherently. Instead of concentrating trust in a single private authority, decentralised systems distribute it: through transparent verification pipelines, reproducible builds, and community audits. Users choose whom to trust, and curators are accountable to the public, not to corporate shareholders. This model embodies the DMA’s vision of interoperability and openness far better than Apple’s notarisation.

Such a model aligns with the DMA’s ambitions: interoperability, transparency, and user choice. Decentralised curation can support multiple overlapping trust networks, from individual developers to NGOs, universities, or public institutions, each maintaining their own repository policies. Instead of “millions of apps” buried in opaque ranking algorithms, users could benefit from clearly defined, community-led collections where the emphasis is on transparency, privacy, and respect for user rights. Security is achieved not through corporate secrecy but through diversity, peer review, and verifiable integrity.

What’s next?

If the DMA is to live up to its potential, regulators must treat Apple’s notarisation for what it is: a mechanism of control disguised as a security feature. This civil-society complaint demonstrates that Apple’s understanding of security undermines transparency, competition, and user autonomy - hampering software freedom for everyone. It is not genuine security, it is merely gatekeeping by another name. The European Commission must ensure that compliance with the DMA means genuine openness. The right to install, share, and verify software freely in any device is not merely a technical issue; it is a matter of freedom.


Read the original article

Comments

  • By donatj 2025-11-0811:173 reply

    I stopped releasing binaries for a number of my tools because I didn't want to pay the $100 a year for the right to do so, and I got tired of explaining how to run them without signing.

    The post I wrote to point people at anyway:

    https://donatstudios.com/mac-terminal-run-unsigned-binaries

    • By lapcat 2025-11-0814:532 reply

      Note that the submitted article is about iOS, not macOS. The "notarization" process on iOS shares practically nothing with macOS except the name:

      https://developer.apple.com/help/app-store-connect/managing-...

      iOS notarization is just app review with fewer rules.

      • By hu3 2025-11-0817:371 reply

        Doesn't it also require the same $100 annual fee?

        • By lapcat 2025-11-0817:501 reply

          Yes, the Apple developer program is $99 per year, but again, this has nothing to do with the submitted article.

          • By hu3 2025-11-0820:35

            And a mac*

      • By archagon 2025-11-0819:361 reply

        You can bet that Apple will pervert macOS notarization for app review just as soon as they can get away with it.

        • By lapcat 2025-11-0819:471 reply

          > just as soon as they can get away with it

          Who is stopping them currently?

          • By archagon 2025-11-0822:321 reply

            Developers would revolt if Apple introduced it right away. The steps will have to be gradual. But it’s pretty clear that the open, Unix-based Mac is an odd duck in Apple’s current lineup — and Apple is a company that likes to homogenize.

            • By lapcat 2025-11-0822:56

              > Developers would revolt if Apple introduced it right away.

              What does "revolt" mean, exactly? I'm a developer myself, so I'd like to know what I would/should be doing?

              Keep in mind that a lot of Mac developers have iOS apps too, so they're accustomed to app review.

              > The steps will have to be gradual.

              Developer ID was introduced in 2012, and notarization was added in 2019. What are the next steps, and what is the timeline for them?

    • By thatfrenchguy 2025-11-0818:391 reply

      easier to release the source code here and better for your customers right?

      • By donatj 2025-11-0823:16

        My stuff is all just free open source. No customers.

  • By invaliduser 2025-11-088:167 reply

    The same thing exists on Windows, developers have to code sign their binaries. It's even worse in my experience because you have to use a token (usb key with cryptographic signing keys in it) and that's impractical if you want your ci/cd to run in a datacenter. At my company we had a mac mini with a windows VM and a code signing token plugged in just for the purpose of signing our macos and windows binaries.

    Another solution that is not mentioned in the article is that users of both macos and windows should be able to easily integrate the certificate of a third-party editor, with a process integrated in their OS explaining the risks, but also making it a process that can be understood and trusted, so that editors can self-sign their own binaries at no cost without needing the approval of the OS editor. Such a tool should ideally be integrated in the OS, but ultimately it could also be provided by a trusted third-party.

    • By Xiol 2025-11-088:50

      I struggled with a similar problem recently. You can use osslsigncode to sign Windows binaries from Linux. It is also possible, with some pissing about, to get everything to work hands off.

      In the end we went with Digicert Keylocker to handle the signing, using their CLI tool which we can run on Linux. For our product we generate binaries on the fly when requested and then sign them, and it's all done automatically.

    • By lapcat 2025-11-0813:45

      > The same thing exists on Windows, developers have to code sign their binaries.

      > Another solution that is not mentioned in the article is that users of both macos and windows

      The article is actually about notarization on iOS, which is vastly different from notarization on macOS. On iOS, every app, whether in the App Store or outside the App Store, goes through manual Apple review. But apps distributed outside the App Store have fewer rules.

    • By AzzyHN 2025-11-0816:491 reply

      If I try and run an unsigned program, the UAC window will be yellow, but I can run it with zero issue.

      I cannot do the same thing on MacOS with the same ease, and that's the issue.

      • By seec 2025-11-1013:30

        Yes I don't understand what he means. On Windows you can basically tone down the security to the point you basically tell it to shut up and let you do anything you want, including shooting yourself in the foot (which is fine by me).

        On macOS you have to resolved to various tricks to be able to run stuff you have decided you want to run, for whatever reason.

    • By anang 2025-11-088:371 reply

      Just FYI, you don’t have to use a USB stick, you can also use HSM like azure key vault and sign using azure signtool.

      • By nickf 2025-11-0810:071 reply

        Azure Key Vault - even in the ‘premium’ HSM flavour can’t actually prove the HSM exists or is used, which doesn’t satisfy the requirements the CA has. In theory, it shouldn’t work - but some CAs choose to ignore the letter and the spirit of the rules. Even Azure’s $2400a month managed HSM isn’t acceptable, as they don’t run them in FIPS mode.

    • By tumult 2025-11-088:234 reply

      Nope. Notarization is not code signing. It’s an extra step, after code signing, where you upload your software to Apple’s servers and wait for their system to approve it. It’s more onerous than code signing alone and, with hindsight, doesn’t seem to have been offering any extra protection.

      • By jeroenhd 2025-11-088:292 reply

        It's not the same, but in practice it's also not so different. Microsoft keeps track of how many times a certain executable has been run and only after a certain threshold does the executable become openable without hunting for tiny buttons. The kicker: this also applies for signed binaries.

        Microsoft will upload these executables to the cloud by default if you use their antivirus engine ("sample collection").

        In a way, Microsoft is building the same "notarisarion database", but it's doing so after executables have been released rather than before it. Many vendors and developers will likely add their executables to that "database" by simply running it on a test system.

        On the other hand, SmartScreen can be disabled pretty easily, whereas macOS doesn't offer a button to disable notarisarion.

        • By makeitdouble 2025-11-0810:063 reply

          Microsoft's notorisation sounds fully automated and transparent, while Apple's is more political and hands on. Individual apps getting their notorisation slowed down to a glacier pace because the platform owner doesn't like them doesn't seem to happen in Microsoft land.

          • By mort96 2025-11-0810:391 reply

            Wasn't there even a story some time ago about how some completely legit, legal, above-board app to virtualize old (pre OS X) versions of Mac OS got rejected by Apple's notarization process?

              • By raddan 2025-11-0811:541 reply

                “UTM SE” is now on the App Store. Perhaps this was just a mistake?

                https://apps.apple.com/us/app/utm-se-retro-pc-emulator/id156...

                • By immibis 2025-11-0812:111 reply

                  It was the standard business pattern of denying your competitors everything you can, unless it causes a third-party fuss.

                  • By mort96 2025-11-0814:12

                    I'm honestly not even sure it's about denying competitors anything. It feels more like denying their users. Apple has a long history of intently denying users the ability to do what they want LONG before any potential App Store competitors appeared.

              • By robenkleene 2025-11-0811:581 reply

                Note this is an iPhone app (noting because this thread seems to mainly be about macOS).

                • By mort96 2025-11-0813:052 reply

                  Notarization is the same for macOS and iOS AFAIK. Both platforms have a separate app store review process that's even more strict than the notarization process.

                  • By robenkleene 2025-11-0813:512 reply

                    > Notarization is the same for macOS and iOS AFAIK.

                    Assuming the basic facts are straight, the the linked story explicitly proves this is false:

                    > UTM says Apple refused to notarize the app because of the violation of rule 4.7, as that is included in Notarization Review Guidelines. However, the App Review Guidelines page disagrees. It does not annotate rule 4.7 as being part of the Notarization Review Guidelines. Indeed, if you select the “Show Notarization Review Guidelines Only” toggle, rule 4.7 is greyed out as not being applicable.

                    Rule 4.7 is App Review Guidelines for iOS, so this would be a case of failing notarization for iOS App Review Guidelines, which means the policies (and implementation) are different between platforms.

                    (Of course there's no such thing as "Notarization Review Guidelines" so maybe this whole story is suspect, but rule 4.7 is the App Review Guidelines rule that prohibits emulators.)

                    • By mort96 2025-11-0814:06

                      The point is that notarization plays the same role for both platforms: checks whose purpose is to make sure that the software won't harm the user's device, unrelated to the App Store review process. Both platforms have an additional App Store review process which is significantly more strict, and the notarization process isn't supposed to involve App Store review for either platform.

                      When Apple denies notarization for bullshit reasons on one platform, it makes me highly suspicious of their motivation for notarization on all platforms.

                    • By robenkleene 2025-11-0818:36

                      > Notarization Review Guidelines (a subset of the App Review Guidelines).

                      Just noting I was wrong, Notarization Review Guidelines are referenced here https://developer.apple.com/help/app-store-connect/managing-...

                  • By lapcat 2025-11-0814:141 reply

                    > Notarization is the same for macOS and iOS AFAIK.

                    It's not. They're totally different. The only thing they share is the word "notarization".

                    • By mort96 2025-11-0814:281 reply

                      Their decision to use the same word for both is enough for me to treat them as the same. Apple has tried to convince people that notarization exists for the user's benefit; the iOS implementation of notarization has convinced me that that's not the case.

          • By Earw0rm 2025-11-0810:322 reply

            The bigger difference is that Apple isn't just checking for malware, it's checking for conformance with various APIs, manifest requirements and so on. Not as strict as the iOS App Store, maybe, but it will refuse to notarize if it detects use of unsanctioned API calls.

            You don't even need signing for Microsoft's system to do what it does - it can operate on unsigned code, it's all hash based.

            • By makeitdouble 2025-11-0810:55

              > it will refuse to notarize if it detects use of unsanctioned API calls.

              Or really any reason. They're not supposed to exert editorial control but that's how it has been happening in practice.

            • By robenkleene 2025-11-0811:572 reply

              > detects use of unsanctioned API calls

              Is there a concrete example of this? We know this isn't blanket policy, because of a recent story (https://news.ycombinator.com/item?id=45376977) that contradicts it. I can't find a reference to any macOS app failing notarization due to API calls.

              • By drysart 2025-11-0812:501 reply

                Notarization doesn't blanket block all access to private APIs; but the notarization process may look for and block certain known accesses in certain cases. This is because notarization is not intended to be an Apple policy enforcement mechanism. It's intended to block malicious software.

                So in other words, using private APIs in and of itself isn't an issue. Neither is it an issue if your application is one that serves up adult content, or is an alternate App Store, or anything else that Apple might reject from its own App Store for policy reasons. It's basically doing what you might expect a virus scanner to do.

                • By robenkleene 2025-11-0812:59

                  Yeah, don't disagree with any of that, but I'm looking for explicit evidence that that is true (right now it sounds like it's just an assumption)? E.g., either examples of apps failing notarization due to API calls, or Apple explicitly saying that they analyze API calls. Without that it sounds like we're just guessing?

              • By Earw0rm 2025-11-0821:38

                I have experienced it myself but this was some years ago, may not be current. Think it was things they were trying to deprecate, which are now fully gone - was around the time they introduced Hardened Runtime, 2018-19 ish.

          • By hkpack 2025-11-0810:321 reply

            I have the opposite experience - on macOS you can guarantee what users will see when you distribute your notarized app, while on Windows you cannot for undefined time.

            How often do you notarize your apps? Why does the speed matter at all? In my cases it takes 2 seconds for the notarization to complete.

            • By makeitdouble 2025-11-0811:052 reply

              The article is about iOS, and getting your notorization in 2 seconds or weeks is IMHO a big difference.

              There's obviously simple cases where the iOS notorization also flies in 2 secs, but there seems to be enough tougher cases:

              https://www.reddit.com/r/iOSProgramming/comments/1l9m7jd/how...

              • By drysart 2025-11-0812:581 reply

                The length of time notarization takes depends primarily upon how large and complicated your app is, and how different is from previous versions of the same application you've previously notarized. The system seems to recognize large blocks of code that it's already analyzed and cleared and doesn't need to re-analyze. How much your binary churns between builds can greatly influence how fast your subsequent notarizations are.

                A brand new developer account submitting a brand new application for notarization for the first time can expect the process might take a few days; and it's widely believed that first time notarizations require human confirmation because they do definitely take longer if submitted on a weekend or on a holiday. This is true even for extremely small, trivial applications. (Though I can tell you from personal experience that whatever human confirmation they're doing isn't very deep, because I've had first time notarizations on brand new developer accounts get approved even when notarizing a broken binary that doesn't actually launch.)

                And of course sometimes their servers just go to shit and notarizations across the board all take significantly longer than normal, and it's not your fault at all. Apple's developer tooling support is kinda garbage.

                • By Someone 2025-11-0813:21

                  > I've had first time notarizations on brand new developer accounts get approved even when notarizing a broken binary that doesn't actually launch

                  https://developer.apple.com/documentation/security/notarizin... (emphasis added):

                  “Notarize your macOS software to give users more confidence that the Developer ID-signed software you distribute has been checked by Apple for malicious components. _Notarization_of_macOS_software_is_not_App_Review. The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly.”

                  ⇒ It seems notarization is static analysis, so they don’t need to launch the process.

                  Also, in some sense a program that doesn’t launch should pass notarization because, even though it may contain malware, that’s harmless because it won’t run.

              • By robenkleene 2025-11-0811:58

                I went through the comment there, all of those look like the most likely explanation is just bugs in the notarization system.

        • By layer8 2025-11-0821:35

          The important part is that once you have a code signing certificate, you can sign your executable independently, offline, without involvement from Microsoft, which isn’t possible with Apple’s notarization.

      • By tonyedgecombe 2025-11-0812:24

        >It’s more onerous than code signing alone and ...

        I don't know, I sometimes contemplated sticking sharpened pencils in my eyes for light relief whilst trying to renew my code signing certificates.

      • By Earw0rm 2025-11-0810:291 reply

        It's more akin to an enforced malware scanner, at least in principle, kind of mandatory VirusTotal with a stapled certificate.

        In practice though they use it to turn the screws on various API compliance topics, and I'm not sure how effective it is realistically in terms of preventing malware exploits.

        • By robenkleene 2025-11-0812:03

          > In practice though they use it to turn the screws on various API compliance topics

          Do you have an example of this on macOS?

      • By robenkleene 2025-11-0812:021 reply

        > doesn’t seem to have been offering any extra protection.

        How would this be measured?

        Since no one has pointed it out here, it seems obvious to me that the purpose of the notarization system is mainly to have the code signatures of software so that Apple can remotely disable any malware from running. (Kind of unsavory to some, but probably important in today's world, e.g., with Apple's reach with non-technical users especially?)

        Not sure how anyone external to Apple would measure the effectiveness of the system (i.e., without knowing what has been disabled and why).

        There's a lot of unsubstantiated rumors in this comment thread, e.g., that notarization on macOS has been deliberately used to block software that isn't malware on macOS. I haven't seen a concrete example of that though?

        • By tumult 2025-11-0813:501 reply

          Disabling malware via hash or signature doesn't require the Notarization step at all. Server can tell clients to not run anything with hash xxyyzz and delete it. I mean, just think about it. If disabling stuff required the Notarization step beforehand, no anti-malware would have existed before Notarization. Nonsense.

          • By robenkleene 2025-11-0813:53

            I think notarization is just a more automated way to do this approach, e.g., otherwise Apple has to hunt down all the permutations of the binary themselves. It seems like it just simplifies the process? (It makes it a white list not a black list, so it's certainly more aggressive.)

    • By scosman 2025-11-089:172 reply

      Highly suggest trying Azure Trusted Signing on a CI system with windows boxes (I use Github). Windows signing was an expensive nightmare before, but is now relatively painless and down to $10/mo (which isn't cheap but is cheaper than the alternatives).

      • By drysart 2025-11-0813:03

        Azure Trusted Signing is a crapshoot. If you can get running, it's easy and fast and great. But if you run into any problems at all during the setup process (and you very well might since their onboarding process is held together with duct tape and twine), you're basically left for dead and unless you're on an enterprise support plan, you're not going to get any help from them at all.

      • By amaccuish 2025-11-089:351 reply

        Last time I checked it's still US/Canada only. Luckily I only needed code-signing for an internal app, so we just used our own PKI and pushed the certs over MDM.

        • By jtokoph 2025-11-0819:03

          It’s also limited to companies that have a proven life span of at least 3 years IIRC (you have to provide a duns number). They may have reopened for individuals, but that means your personal name attached to every binary.

    • By catlifeonmars 2025-11-0812:43

      You can virtualize an HSM FWIW.

  • By Someone 2025-11-0813:401 reply

    FTA: “Apple’s complete review of apps – known as “notarisation” process - a mandatory step for distributing any software on its platforms, represents the very gatekeeping behaviour the DMA was written to prevent.”

    Notarization doesn’t involve a complete review (https://developer.apple.com/documentation/security/notarizin...: “Notarization of macOS software is not App Review. The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly.”

    I also expect Apple will argue that requiring code to be notarized is explicitly allowed under the DMA, based on section 6.7:

    “The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.”

    So, the discussion would have to be on whether this is strictly necessary and proportionate, and whether Apple duly justified that.

    I think “strictly necessary” is a bit at odds with defense in depth (https://en.wikipedia.org/wiki/Defense_in_depth_(computing)), where you explicitly add redundancy to improve security, so we’ll see how a judge rules that, but I can see them accepting it if Apple argues they’ll implement a similar feature on-device instead if they have to.

    • By lapcat 2025-11-0813:53

      > “Notarization of macOS software

      The submitted article is about notarization on iOS, which is vastly different from notarization on macOS.

      It's a shame that Apple used the same word for both platforms, because it appears to be confusing everyone. Maybe that was deliberate...

HackerNews