Apple's "notarisation" – Blocking Software Freedom of Developers and Users
Postedabout 2 months agoActiveabout 2 months ago
fsfe.orgTechstoryHigh profile
heatednegative
Debate
85/100
AppleNotarizationSoftware FreedomDma
Key topics
Apple
Notarization
Software Freedom
Dma
The article discusses Apple's notarization process and its implications on software freedom, sparking a heated debate among HN commenters about the trade-offs between security and developer freedom.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
69
6-12h
Avg / period
26.7
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Nov 8, 2025 at 12:37 AM EST
about 2 months ago
Step 01 - 02First comment
Nov 8, 2025 at 1:43 AM EST
1h after posting
Step 02 - 03Peak activity
69 comments in 6-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 10, 2025 at 9:45 AM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45854441Type: storyLast synced: 11/20/2025, 8:52:00 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Nobody else would bother. That’s why meme language repositories continuously lead to hacks and vulnerabilities.
[0] https://appstoreconnect.apple.com/WebObjects/iTunesConnect.w... [1] https://developer.apple.com/support/downloads/terms/apple-de...
All the relevant agreements can be found here, so if there's something that specifies this kind of overreach, I'd both be very surprised and interested.
https://developer.apple.com/support/terms/
Edit: oh, are you saying that such requests would be "Apple confidential information" so nobody would say if it happened?
Right now you have a lot of piracy apps which are disguised as a "note taking app" and they passed the appstore review without any issues.
Which is exactly as it should be
I actually don't have (much) of an issue with walled garden approaches as long as the wall has a gate that is easily opened, give me an OS level toggle with a warning of "Here be dragons" and I can live with it - it's not ideal but it's not a terrible trade off.
It's something Android has had previously (but they seem to be trying to lock that gate) and iOS less so.
Invariably, the argument is: "users will just be instructed to open the gate by the bad guys, so we can't have a gate!"
and the purported purpose of notarization is "blessing" trustworthy software.
We also can't count on every person being able to check every single thing they do: how do you check if some food or drug you get is good or not? you can't really, you have to trust someone who knows.
Society should be more dangerous as a means to force people to learn more about technology they rely on.
Yes - the democratically elected government, not a monopolistic entity with capital interest.
Its a smokescreen.
You want less liberty because of the “least competent” user?
A phone/tablet is a tool, with very intense usage, and huge privacy value, not an engineer's toy.
Editing to add: it seems particularly ironic that you think iPhone users make great purchasing decisions when they buy the phone, but are incapable of making good decisions when selecting software. What accounts for the discrepancy?
And, the app store does absolutely nothing to prevent "dangerous" apps. Apple doesn't review the code. In fact, if your code is reviewable, it's even harder to get it on the app store.
At the end of the day, the App Store and Play Store are filled with adware, spyware, and other malware - because Apple and Google like it that way. That's what they want. They don't give a single flying fuck about your security. They care about extracting 30% while simultaneously doing as little as possible. That's completely at odds with security, yes, and they know that. They just don't care.
60% of society could be raptured tomorrow and the world would be better off.
Allowing third party installations does not mean uncontrolled third party apps. It merely means users have to option to install software on their phones - which continues to limit the softwares capabilities until the user was prompted to allow each.
You could argue "but a braindead person can randomly go on a phishing website, randomly download some .app file and suddenly - through magic go through a theoretical installation dialog to finally explicitly grant this malware problematic permissions... And I'm sure there are going to be people that will do exactly that... But without it, they'll still manage to do the same to the same effect, just without the app installation by inputting their bank credentials in a phishing site or similar
The thing your citing as a problem solved by disallowing app installs isn't actually solved - and it would not become more problematic either.
Finally, the fact of the matter remains that almost nobody would actually use the capability to install from third party stores, as you've correctly insinuated. But if anything, that should be another proof that allowing third party installs doesn't reduce security.
People just like to have everything provided to them from a single source, and will usually pay a premium for that.
I don't trust Apple's App Store review. They've approved countless scams that have tricked Apple users out of a lot of money, perhaps $billions in total.
UTM wasn't denied notarization because some virus scanner found that it was a virus, but because it violated App Store guidelines. That's editorial control.
The key thing here is that the Apple App Store and third party app stores must be on an level playing field to compete on.
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.
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.
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.
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.
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.
Or really any reason. They're not supposed to exert editorial control but that's how it has been happening in practice.
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.
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...
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.
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.
https://9to5mac.com/2024/06/19/iphone-pc-emulator-block-ille...
https://apps.apple.com/us/app/utm-se-retro-pc-emulator/id156...
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.)
When Apple denies notarization for bullshit reasons on one platform, it makes me highly suspicious of their motivation for notarization on all platforms.
Just noting I was wrong, Notarization Review Guidelines are referenced here https://developer.apple.com/help/app-store-connect/managing-...
It's not. They're totally different. The only thing they share is the word "notarization".
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.
Do you have an example of this on macOS?
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?
I don't know, I sometimes contemplated sticking sharpened pencils in my eyes for light relief whilst trying to renew my code signing certificates.
I cannot do the same thing on MacOS with the same ease, and that's the issue.
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.
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.
> 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.
Notarization is only needed when distributing binaries to others. Personally I do it once a month for the Mac app I distribute.
Absolute freedom does not exist.
Etc.
The post I wrote to point people at anyway:
https://donatstudios.com/mac-terminal-run-unsigned-binaries
https://developer.apple.com/help/app-store-connect/managing-...
iOS notarization is just app review with fewer rules.
Who is stopping them currently?
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?
Not only are all of these functions and corresponding permissions completely standard for all kinds of applications, they belong to the core of what any system that calls itself an "operating system" should deliver to developers and end users.
You don't need full unlimited access to everything in order to send a file.
But in the end the file access issue is an operating system deficiency. They could offer more fine-grained access control but the common operating systems don't. It's ultimately a matter of user convenience.
The only problem is that nobody cares, so there's no evolutionary pressure for OS developers to make their products safer in the sense the applications are safe for user.
You have to trust native apps, as it always was the case. You can't just install random apps. You can delegate the trust to a curated lists of apps that you trust.
Or you can just use the web apps, but then you have to trust them too (so they don't misuse information about you or your data for example). But then it can't integrate with anything and many features are simply not available.
As for your example, a photo editor could need a network connection when it contains collaborative features. Or an auto-update system. Or downloading of assets on demand. Or cloud AI feature. Or list of add-ons to install. Or for license checks. Or online help/docs. Or whatever.
> a photo editor could need a network connection when it contains collaborative features. Or whatever.
Or none, if I decide to not allow it.
Glad more developers are seeing the light now.
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.
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...
I don't want to hear any of the usual "don't use sideloading if you don't like it". I don't want it to exist so nobody can talk my grandma into installing a fake bank app over the phone, like they did to her once when she had an android phone and stole all her money.
Yes this is not foolproof still, some scam apps might make it past notarization. Just like cover fees in clubs and gates in gated communities -- it does not keep all the riff-raff away, but it helps.
It's clearly not working as advertised. Specially not as advertised by those affected by the distortion field.
Again, I would happily donate to such an initiative before it is too late!
iOS notarization is still manual review by Apple, but with fewer rules and restrictions.
https://developer.apple.com/help/app-store-connect/managing-...
> If you’ve opted into alternative distribution for customers in the European Union, you can choose to make your app version eligible for distribution on alternative app marketplaces or websites only by selecting to have it evaluated based on the Notarization Review Guidelines (a subset of the App Review Guidelines). Otherwise, App Review uses App Review Guidelines to evaluate your app version to make it eligible for distribution on the App Store, alternative app marketplaces, and websites if approved.
Next we'll hear that Nintendo has secretly developed a locked-down game console that only runs Nintendo-approved software, and Nintendo is charging developer fees.
It is surely a coincidence that 70% of Apple's iOS App Store revenue is from games.
17 more comments available on Hacker News