If you try to open a freshly downloaded app and then blocked by the “<app> cannot be opened because the developer cannot be verified. macOS cannot verify that this app is free from malware” dialog, it just means what it says. The operating system is rather suspicious that the app may be malicious software. Thereupon it advises you to not run it. Even if you trust the developer of this app, the dialog serves to remind you that the app may be tampered by a third party. In other words, a virus could inject itself into the app—that could happen between the time the developer packaged it and the time you try to run it.
Contrary to popular belief, macOS isn’t immune to malware. The platform has been lucky thus far since its relatively low market share makes it a less attractive target for malware makers. In contrast as macOS gain more users, it would likewise be a more attractive target to make malware for—regardless of market share.
For that reason Apple is stepping up macOS security. For example the mandatory notarization which require developers to digitally sign the app and then register it with Apple. In turn, Apple would scan the app for known malware. In effect Apple would then provide a stamp of approval should none was found. On the other hand, Apple can also revoke its approval if at a later time the application turned out to be malicious.
In summary, the notarization process is like centralized anti-virus scanning. On the positive side, each app need to be scanned only once—that is during notarization. Each user’s mac would only need to verify the integrity of the app and whether it has a valid notarization ticket from Apple. To explain, a notarization ticket states that the app is free from malware, hence the operating system would only need to verify that the files which makes up the app hasn’t changed since it was scanned by Apple. Obviously this saves users from needing to continuously run anti-virus software which periodically scans applications. Simultaneously centralized scanning gives back precious computing resources that would otherwise need to be spent for periodic anti-virus scanning on each computer.
Since notarization requires code signing, it also ensures integrity of the application. If a virus injects itself to the app, this would invalidate the code signature and by extension the notarization ticket. Likewise code signing helps ensure accountability on the developers’ part. Each signed application can be confidently traced back to either an entity or a natural person who signs it. Therefore if a developer knowingly distribute malware, Apple would be justified to revoke their code signing credentials–effectively stops them from distributing new signed applications.
As a user, if you see the “app cannot be verified for malware” dialog, you shouldn’t open the app. Even if you trust the developer who produced it. A point often overlooked is that the app could gave been tampered. In any case, you should contact the developer of the app and advise them to notarize it.
The developer may say that they don’t have much time to notarize applications. It is a mundane process anyhow, notably when done manually. Nevertheless the developer may not know how to automate the notarization process. In this case you should recommend my book, How to Notarize macOS Application Notarization to them. This book can save about 50 hours of a developers’ time for trial and error in automating the notarization process as well as setting up a system for it.
To repeat, if you couldn’t open an app because of the “macOS cannot verify that this app is free from malware” dialog, do the developer a favor by sending them this link. Likewise if you know a developer planning to launch a macOS application or thinking to make one, stress the importance of notarization and how they can easily automate it.
That’s all for now, take care!