From Claude.ai :

① Réponse forum pour whereas-stuf

Hey @whereas-stuf — that "unsupported Mac" message is misleading; it's almost certainly not a real hardware incompatibility. I had the actual app binary analyzed: it's a universal build (Apple Silicon + Intel) with a minimum of macOS 13, and there is no model/architecture/OS check anywhere in the code. So your M1 and M4 are fine in principle — what you're hitting is a code-signature/Gatekeeper rejection that macOS is reporting with a confusing dialog.

Important: the chmod +x on the inner binary that got passed around earlier in this thread is the likely culprit. Modifying that file breaks the app's code signature, and on Apple Silicon a binary with a broken signature literally can't launch (the kernel kills it) — which surfaces as exactly these "can't be opened" errors. So don't do that step.

Try this from a fresh download (don't touch anything inside the bundle):

rm -rf /Applications/C4DThumbnail.app
# copy the freshly downloaded .app into /Applications, then:
xattr -dr com.apple.quarantine /Applications/C4DThumbnail.app
codesign --force --deep --sign - /Applications/C4DThumbnail.app
open /Applications/C4DThumbnail.app
qlmanage -r && qlmanage -r cache && killall Finder

The codesign --sign - line re-seals it with an ad-hoc signature, which is what Apple Silicon needs to run it locally after the original seal was disturbed.

One more thing to check: are you running any third-party security software (CleanMyMac, Intego, Malwarebytes, an MDM profile from work, etc.)? Those can intercept the launch and throw their own odd dialog. Worth temporarily disabling to test.

Let us know which Mac/OS it finally works on — works here on M3 Max / Tahoe.

② Note technique pour Tisi (Matthias Lein)

@Tisi — quick heads-up on why it works for some of us and throws "can't be opened / unsupported" for others. It's not your code (no hardware check in there, it's a clean universal binary). It's the signing.

The build is signed with an Apple Development certificate, it carries the get-task-allow entitlement, and there's no provisioning profile in the bundle. That's a debug build: it runs reliably on your own machine, and on other Macs only if the user does the "Open Anyway" dance and nothing disturbs the signature. Any post-download tweak (like the chmod +x advice floating around) invalidates the seal, and on Apple Silicon an invalid signature = won't launch at all. Hence the "works on some Macs, not others" pattern.

The durable fix is to ship it as a proper distribution build:

1. Enroll in the Apple Developer Program ($99/yr) if you haven't — you need a Developer ID Application certificate (not the Apple Development one).
2. Build for Release with Hardened Runtime enabled, and remove get-task-allow (Xcode does this automatically for Release/Developer ID).
3. Sign with Developer ID, e.g.
   codesign --force --options runtime --deep --sign "Developer ID Application: Your Name (TEAMID)" C4DThumbnail.app
4. Notarize: zip it, submit with
   xcrun notarytool submit C4DThumbnail.zip --apple-id … --team-id … --password … --wait
5. Staple the ticket so it works offline:
   xcrun stapler staple C4DThumbnail.app

After that, Gatekeeper accepts it everywhere with a normal double-click — no Terminal, no quarantine stripping, no broken-seal issues. Easiest path is to let Xcode's Archive → Distribute App → Developer ID flow do all of steps 3–5 for you.

(For what it's worth: huge thanks for actually solving this — two hours of vibecoding beat three years of Maxon tickets.)

@whereas-stuff M3 max - Tahoe

@whereas-stuff From Claude.ai :

Quick clarification up front: this is not a regular app — it's a modern macOS Quick Look extension (an .appex of type com.apple.quicklook.thumbnail) bundled inside the .app. That means it registers itself automatically as soon as the containing app is on disk and has been launched once. Note that the old ~/Library/QuickLook folder does not apply here — that's for the legacy .qlgenerator mechanism. Here's how to set it up (run these in Terminal):

1. Move the app into Applications so LaunchServices keeps it registered:

mv ~/Downloads/C4DThumbnail.app /Applications/

2. Clear the Gatekeeper block. Heads up: this build is signed with a personal Apple Development certificate, not a Developer ID, and it isn't notarized — so macOS will flag it as coming from an unidentified developer. Strip the quarantine attribute:

xattr -dr com.apple.quarantine /Applications/C4DThumbnail.app

If macOS still refuses: System Settings → Privacy & Security → "Open Anyway".

3. Launch the app once to trigger the extension registration:

open /Applications/C4DThumbnail.app

4. Confirm the system sees the extension, and enable it if needed:

pluginkit -m -p com.apple.quicklook.thumbnail | grep -i tisi
pluginkit -e use -i io.tisi.C4DThumbnail.Extension

(The first command should list io.tisi.C4DThumbnail.Extension; a leading + means it's already active.)

5. Flush the thumbnail cache and restart Finder:

qlmanage -r
qlmanage -r cache
killall Finder

6. Test it on an actual file (swap in a path to one of your own .c4d files):

qlmanage -t -s 512 -o ~/Desktop "/path/to/a_file.c4d"

That drops a test thumbnail on your Desktop. Otherwise, just open a folder of .c4d files in Finder using Gallery or Icon view.

Two honest caveats: thumbnails will only show up for .c4d files that actually contain an embedded JPEG preview (this depends on your Cinema 4D save settings), and since the app isn't notarized, a future major macOS update could re-trigger a Gatekeeper block. If registration gets stuck, killall -KILL pkd (the PluginKit daemon) forces it to re-scan.

@Tisi It works great. Thank you so much.

@Tisi Thank you !!

@noseman Are you kidding? Is working in Cinema 4D a lottery?

I'd like to know that too.