How to check for yourself whether a Mac live wallpaper app is safe
Some are, some aren't — and you don't have to take anyone's word for it. Three Terminal commands that ship with macOS and one System Settings pane tell you who signed the app, whether Apple scanned it, and what it is able to read. The rule that decides everything: a wallpaper draws pixels; it never needs to read them. Since March 2026 the category has been actively impersonated by malware, and more than half of the malicious Mac binaries analysed this year arrived digitally signed. That is why this page is a checklist you can run on any app, not a promise.
The rule that sorts the whole category: drawing pixels is not reading them
Open System Settings > Privacy & Security on macOS 26 and count the categories: twenty-four. Your data (location, contacts, photos, files and folders, full disk access), your sensors (camera, microphone, screen recording), control of the machine (accessibility, input monitoring, automation, remote desktop), your surroundings (Bluetooth, local network, HomeKit). Now ask which of them governs displaying something. None. Every one governs reading your data or controlling your Mac.
That is the whole sorting rule. A wallpaper renderer draws pixels onto the desktop; it reads none of your data to do it, so structurally it needs none of the twenty-four. Every permission a wallpaper app asks for has to be justified by a feature you actually use — a weather widget wanting Local Network, a folder icon feature wanting Files and Folders — never by the wallpaper itself.
The permission that hurts most is Screen & System Audio Recording, which lets an app, in Apple's words, “access and record the screen and audio on your Mac”. The usual excuse for it — “we need it to pause the wallpaper when a window covers it” — does not survive the documentation. Without that permission, CGWindowListCopyWindowInfo omits exactly one thing, the kCGWindowName key: an app still sees that a window exists and where it sits, it just cannot read its title or contents. Pausing needs none of it. The honest exception: an app that previews your desktop or reacts to what is on screen genuinely needs it — and must say why before asking. Battery cost is a separate question, measured in do animated wallpapers drain a MacBook's battery?; this page measures nothing.
Before you even launch it: read what the app is allowed to ask you
Here is the step nobody publishes. The app sits in /Applications, downloaded but not yet opened. Every permission dialog macOS can show on its behalf is already written inside the bundle, as a “purpose string” in Info.plist. One line reads them all:
plutil -p "/Applications/Example App.app/Contents/Info.plist" | grep -i usageWhat comes back is the list of what the app is capable of asking for. An app with no NSScreenCaptureUsageDescription cannot display the screen recording dialog at all; an app that carries one, in a category that draws pixels, owes you an explanation. Then read what the signature itself authorises:
codesign -d --entitlements :- "/Applications/Example App.app"That prints the entitlements — the capabilities baked into the signature, such as the App Sandbox (com.apple.security.app-sandbox, normal for App Store apps, absent for most direct downloads) or Apple Events automation. One verified limit: many apps declare no purpose strings at all — Google Chrome, checked on 29/08/2026, declares none. A string that is present is a signal. A string that is absent proves nothing.
Two commands that tell you who signed the app and whether Apple scanned it
Now ask macOS for its verdict. If the path contains a space, keep the quotes:
spctl -a -vv "/Applications/Example App.app"Ignore the stale articles claiming “spctl is dead”: what macOS 15 removed, per its own manual page, is only the operations that modify Gatekeeper's rule database. The assessment, -a, still works on macOS 26.6.2. It answers with a verdict and a source= line, in only five combinations, all observed on 29/08/2026:
| What spctl returns | What it means | Verdict |
|---|---|---|
| accepted · source=Apple System | Apple software shipped with macOS | Nothing to check |
| accepted · source=Mac App Store | Went through Apple's review, sandboxed | Good signal, not a guarantee |
| accepted · source=Notarized Developer ID | Signed by an identified developer account and scanned by Apple | The minimum to demand outside the App Store |
| rejected · source=Unnotarized Developer ID | Signed, but never submitted to Apple's scan | Reject for a wallpaper app |
| rejected · source=no usable signature | Nobody claims authorship | Delete |
The second command reads the identity behind the signature:
codesign -dv --verbose=4 "/Applications/Example App.app"Four lines matter. Authority= is the name on the certificate, followed by Apple's chain (Developer ID Certification Authority, Apple Root CA). TeamIdentifier= is the ten-character Team ID. Notarization Ticket=stapled means the ticket travels with the app and the check works offline — on a signed but unnotarized app, that line is simply absent. The word runtime inside flags= means the Hardened Runtime is on.
Compare the Team ID with the one the developer publishes on its website; if it is published nowhere, that is already an answer. For a disk image, stapler validate "Example App.dmg" checks the ticket on the DMG itself — it needs an internet connection and only works on UDIF images, flat installer packages and .app bundles. Ten minutes cover a whole shortlist — our comparison of live wallpaper apps for Mac is a good place to start.
Four Privacy panes where a wallpaper app should never appear
Now launch it, use it for a session, and open System Settings > Privacy & Security. You are checking that the app is absent from four panes.
- Screen & System Audio Recording — your pixels, your window titles and your sound. Not needed to draw a wallpaper, nor to pause it.
- Accessibility — “access and control your Mac”; Apple notes that an app granted this can also reach your contacts, calendars and other private information, and adds: “Be cautious and grant access only to apps that you know and trust.”
- Full Disk Access — the global exemption. It overrides every fine-grained permission: one checkbox, and the app reads every protected area without a single further dialog. This is the box the March 2026 campaign walked its victims into ticking.
- Input Monitoring — your keystrokes, in every app.
Other panes can be legitimate, on one condition: each entry must map to a feature you use. Files and Folders and Automation make sense if the app changes Finder folder icons; Local Network makes sense for a weather widget. An entry you cannot map to something you asked for is the exit rule.
What it leaves behind, and what it sends out
Persistence first. Open System Settings > General > Login Items & Extensions and look at what the app registered there. Then ask launchd directly, with the bundle identifier from the codesign output:
launchctl list | grep com.example.appAnd look into the three folders where third-party agents live: ~/Library/LaunchAgents, /Library/LaunchAgents and /Library/LaunchDaemons. The uninstall test is the useful one: drag the app to the Bin, then look again. Whatever survives had no business being there.
Network next, without installing anything. nettop ships with macOS:
nettop -P -t external -p "Example App"-P gives a per-process summary, -t external keeps only real interfaces, -p selects the process. Leave it running during a normal session. To block rather than watch, LuLu (Objective-See Foundation, free, GPL-3.0) is an outbound firewall that asks before each new connection; KnockKnock, from the same developer, lists everything installed persistently. What to expect from a locally rendered wallpaper: near-zero traffic in normal use, at most a licence or update check — never a continuous stream.
What the checklist doesn't prove (and the 2026 trap)
A signature is not a virtue. Moonlock Lab's mid-2026 macOS threat report (16/07/2026) is blunt: “well over half of malicious Mach-O uploads were digitally signed, and roughly one-fifth carried valid or recently revoked Apple Developer certificates.” Notarization is not an audit either. In Objective-See's review of the Mac malware of 2025, MacSync Stealer was “delivered as a code signed and notarized Swift application within a disk image” and ChillyHell was notarized before Apple revoked its ticket and certificate. OSX.Shlayer had already been found notarized back in August 2020. Apple's own wording is “free of known malicious content”: notarization proves a real identity and the absence of known malware at scan time, nothing about what the app does with your data once it runs.
Then the 2026 trap. Since its first detections on 30 March 2026, a credential stealer documented by Moonlock Lab has been distributed as a counterfeit copy of a real Mac live wallpaper app, hosted on lookalike domains and promoted through a hijacked social-media channel. Two infection paths: a “ClickFix” page showing a base64-encoded Terminal command presented as a fix, and a DMG containing an Install.sh. Either way the victim is then walked, step by step, into granting Full Disk Access. Moonlock's advice, verbatim: “Never paste Terminal commands sourced from a browser or document.”
Two rules follow. Never paste an opaque command a website hands you — the commands here are read-only diagnostics, short enough to type and documented in their manual pages. And never follow instructions to get around Gatekeeper: when macOS blocks an app, the dialog reads “Apple cannot check “Example App” for malicious software”, the override lives in System Settings > Privacy & Security > Open Anyway with a second confirmation, and the right-click > Open bypass was removed in macOS 15. Frigid Stealer told its victims exactly that. A legitimate developer never needs to. If a free animated wallpaper download comes with a workaround, the check is over.
Mac+ put through its own checklist
A page that asks you to verify every app has to submit its own. Mac+ is distributed outside the Mac App Store, signed with a Developer ID certificate and notarized — the download on this site carried a valid notarization ticket under stapler validate on 29/08/2026. The values to compare your Terminal against: bundle identifier com.macosengine.app, Team ID H59XG3G3QT. Before you run codesign: the certificate is in the name of the individual who publishes Mac+ under the PENRA brand — Developer ID Application: Adrien Pennetier (H59XG3G3QT) — not a company. Hardened Runtime is on; the only entitlement in the signature is Apple Events automation.
Permissions declared in Info.plist: Apple Events toward Finder (to refresh a folder icon you customised) and access to the Desktop, Documents, Downloads and removable volumes (to apply icon patterns to folders you choose). Both belong to the folder icon feature, not the wallpaper. No screen recording string, no Accessibility string, no reason to appear under Full Disk Access. Mac+ is not “permission-free”: it asks for two, and neither serves the wallpaper.
Last honesty: the app is not offline. Rendering, scenes, palettes, widgets and icons stay on the machine, but the optional account and the purchase go through the network as soon as you sign in or buy — LuLu will show you exactly that. Run the checklist on it like on any other app. macOS 13 or later, Apple Silicon and Intel, free tier with no account; pricing without subscription is €1.99 a month or €9.99 once, and the scenes live on the live wallpaper for Mac page.
The checklist, in seven moves
- Download the app from the developer's own website only — never from a link in a video, a forum post or a shared document. Do not launch it yet.
- Read what it is able to ask for:
plutil -p "/Applications/Example App.app/Contents/Info.plist" | grep -i usage. A screen recording string in a wallpaper app needs an explanation from the developer. - Ask macOS for its verdict:
spctl -a -vv "/Applications/Example App.app". Expectacceptedwithsource=Notarized Developer IDorsource=Mac App Store; anything else, stop here. - Read the signer's identity:
codesign -dv --verbose=4 "/Applications/Example App.app". NoteTeamIdentifier=, check thatNotarization Ticket=stapledis present and that the flags containruntime. Then compare the Team ID with the one the developer publishes — if it is published nowhere, treat that as an answer. - Open System Settings > Privacy & Security and confirm the app is not listed under Screen & System Audio Recording, Accessibility, Full Disk Access or Input Monitoring.
- Check what it installs: System Settings > General > Login Items & Extensions, then
launchctl list | grep com.example.appand the LaunchAgents folders in ~/Library and /Library. - Watch outbound traffic during a normal session:
nettop -P -t external -p "Example App", or install LuLu if you want to be able to block.
macOS 13 or later. Apple Silicon and Intel. Free tier, no account required — €1.99/month or €9.99 once for the paid tier. Run the checklist on it first.
Frequently asked questions
Are live wallpaper apps safe for Mac?
Some are, some aren't, and you can sort them yourself in a few minutes: spctl tells you whether the app is signed and notarized, codesign tells you who signed it, and the Privacy & Security pane tells you what it was granted. The decisive criterion is the set of permissions it asks for. A wallpaper draws pixels; it has no structural need for screen recording, Accessibility, Full Disk Access or Input Monitoring.
Does a live wallpaper app need screen recording permission?
Not to draw a wallpaper, and not to pause it when a window covers it either: without that permission an app still sees that windows exist and where they are, it only loses their titles and contents. Screen recording exists to read the screen. The one legitimate exception is an app that shows a preview of your desktop or whose effect reacts to what is displayed — and it should say so before asking.
How do I check if a Mac app is notarized?
Run spctl -a -vv on the app's path (in quotes if it contains a space). A notarized download answers accepted with source=Notarized Developer ID. Then run codesign -dv --verbose=4 on the same path and look for the line Notarization Ticket=stapled: it is present on a notarized app and simply absent on an app that is signed but was never submitted to Apple's scan.
Can a notarized Mac app still contain malware?
Yes. Objective-See's review of 2025 documents MacSync Stealer, delivered code signed and notarized inside a disk image, and ChillyHell, notarized before Apple revoked its ticket and certificate; back in 2020 OSX.Shlayer had been notarized too. Apple only certifies the absence of known malicious content at the time of the scan. Notarization proves an identity and a clean scan, not good behaviour with your data.
Do Mac wallpaper apps collect your data?
That is not a matter of opinion: the permissions you grant bound what is technically possible, and the traffic shows what actually leaves. Check the app's entries in Privacy & Security, then watch it with nettop -P -t external -p followed by the process name, or with an outbound firewall such as LuLu. A locally rendered wallpaper should produce near-zero traffic, at most a licence or update check.
Keep reading
Sources
- Apple Support — Safely open apps on your Mac
- Apple Support — Control access to screen and system audio recording on Mac
- Apple Support — Allow accessibility apps to access your Mac
- Objective-See — The Mac Malware of 2025
- Moonlock Lab — notnullOSX: a new Mac stealer targeting crypto wallets
- Moonlock Lab — Mid-2026 macOS threat report