Running macOS Sonoma on an AMD Ryzen 7 7735HS Mini PC

I’ve been running a cheap mini PC built around AMD’s Ryzen 7 7735HS as my latest experiment bench, and the question that kept nagging me was obvious: how hard is it to put macOS on this thing? Not “kind of boot macOS” — actually running Sonoma day-to-day on an 8-core AMD chip that Apple has never officially supported.

Short version: it works, and the whole project lives or dies on one thing — getting the OpenCore EFI partition right. Once that was sorted, the rest of the install was almost boring.

The hardware: what a 7735HS actually is

The Ryzen 7 7735HS is AMD’s Rembrandt-R refresh chip — Zen 3+ cores on a 6nm process, aimed at thin laptops and the wave of budget mini PCs that hit the market recently. On paper:

Spec	Ryzen 7 7735HS
Cores / Threads	8 cores / 16 threads (Zen 3+)
Clocks	3.2 GHz base, up to 4.75 GHz boost
iGPU	Radeon 680M — RDNA2, 12 compute units
TDP	35–54 W, configurable by vendor
Typical homes	Budget mini PCs, thin-and-light laptops, handhelds

For a hackintosh, the interesting line in that table is the Radeon 680M. It’s an AMD APU iGPU, which historically meant “no graphics acceleration, enjoy your laggy 7 MB framebuffer.” That changed once the NootedRed kext matured — it exists specifically to give AMD APU graphics real QE/CI acceleration on modern macOS. Without it, an AMD hackintosh isn’t worth the USB stick you’d install it from.

The one step that matters: the OpenCore EFI partition

Every hackintosh guide eventually arrives at the same place: build an EFI folder and put it on a FAT32 EFI partition. This is the part that looks intimidating and is genuinely the make-or-break step.

What the EFI partition actually is

It’s a small hidden partition (a couple of hundred megabytes of FAT32) that firmware reads before any OS loads. On a normal PC it holds boring boot files. In a hackintosh, it holds your entire cheat sheet for fooling macOS:

• ACPI tables (SSDTs) — small compiled patches that describe the hardware to macOS, like faking a proper power-management setup.
• Kexts — kernel extensions that add driver support. For this build the important ones are Lilu (the patch engine everything builds on), VirtualSMC (emulates Apple’s SMC chip so macOS will even boot), NootedRed (graphics acceleration for the 680M) and AppleALC (onboard audio).
• config.plist — the master configuration file. For any AMD CPU this includes the AMD kernel patches, because macOS’s kernel only knows x86_64 as Intel sees it; the patches rewrite the early boot code so it tolerates AMD.
• Drivers — OpenCore’s own UEFI drivers, like the one that lets the file system be read at boot.

Get any of that wrong and you get kernel panics, boot loops, or an installer that reboots halfway through writing files. Get it right and macOS never knows it’s running on “unsupported” silicon.

Building and mounting it

The guide I followed was built around OpenCore, and the flow was the standard one:

1. Prepare the install USB with macOS Sonoma downloaded from Apple, restored onto a 16 GB+ stick.
2. Mount the EFI partition on that stick. CorpNewt’s MountEFI script does this in one pick, or you can do it manually:

   # find the EFI partition (usually the first small FAT32 partition)
   diskutil list
   
   # mount it, e.g. disk0s1 on the target disk
   sudo diskutil mount disk0s1
   
   # copy your EFI folder in
   cp -R /path/to/EFI /Volumes/EFI/

3. Drop in the prebuilt EFI folder for the platform, check the config.plist against the guide’s settings, and set the BIOS options it demands — the usual suspects being SVM enabled, Secure Boot off, and Above 4G decoding handled properly.
4. Boot from the stick, pick the installer in OpenCore’s boot menu, and let it run.

The honest advice here: don’t freestyle the EFI. These chips are popular enough that working EFIs for 7735HS machines are shared openly, and the community guides around Dortania’s OpenCore documentation cover the AMD-specific quirks. Building every kext and ACPI file yourself from scratch is a learning exercise, not a shortcut.

The install itself was anticlimactic

This is the part nobody believes until they’ve done it: once the EFI partition was correct, the install just… went. The OpenCore picker appeared, the Sonoma installer booted to a real GUI, Disk Utility erased the target drive as APFS, and the install ran through its several automatic reboots — each one correctly handed back to OpenCore so it could resume from the right stage instead of restarting the whole installer.

After the final reboot it dropped into the normal macOS setup assistant, logged into iCloud, and landed on a desktop that looked exactly like it does on a Mac. No rescue missions, no terminal surgery afterwards.

Graphics acceleration was live thanks to NootedRed — smooth UI, proper resolution handling, video playback without the CPU melting. Audio, USB ports and networking all came up with the kexts the EFI shipped with. In other words, the EFI partition is the difficulty; it just happens to be front-loaded into one step at the very beginning.

What works, and what to keep an eye on

Working in daily use

• Full graphics acceleration on the Radeon 680M — the difference between a usable Mac and a slideshow.
• Onboard audio via AppleALC.
• USB peripherals, external drives, and general desktop responsiveness.
• Normal app workflows — browsers, editors, development tools, App Store apps.

Things to watch

• Updates are the risk window. Minor Sonoma point releases usually survive, but the safe ritual is: update the EFI/kexts alongside macOS updates, and let someone else find the breakage first.
• Wireless depends on your card. AirDrop, Handoff and friends generally want Broadcom Wi-Fi; whatever radio your mini PC shipped with may limit Continuity features.
• No discrete GPU option. You’re living on the 680M. Fine for desktop work and light media, not a video-editing powerhouse.
• Power management is approximate. Sleep/wake behaviour on AMD hackintoshes ranges from flawless to quirky depending on the board — test it before you rely on it.

The actual reason to keep it: macOS feeding Home Assistant

Here’s the part that reframes the whole build. Nobody sensible installs macOS on an AMD mini PC because they want a cheap Mac. I did it because this box is always on, it sits alongside the Home Assistant install, and a genuine macOS is what lets me get at the Find My device data my house actually runs on.

That makes the machine a macOS-side data source. Its job is not to be a Mac. Its job is to publish presence data for the people I care about into Home Assistant, so the rest of the house can act on it — arrival automations, “is everyone home” logic, a phone that hasn’t moved all afternoon.

How the data actually moves

The chain is short, and every link in it is load-bearing:

1. macOS keeps its own copy. Find My does not get asked for a position every time something wants one. The system maintains a local cache of device and location data, refreshed as part of ordinary signed-in, online operation — and that cache is signed and encrypted, so it is not a file you can open in a text editor.
2. Something on the Mac has to read and decrypt it. That step is what Pnut-GGG/findmy-cache-decryptor on GitHub is for: turning the local cache into data a program can consume.
3. Home Assistant turns it into device trackers. A Home Assistant custom integration — manonstreet/FindMySyncPlus — runs on the macOS machine itself and reads that cache, publishing the Apple Find My device positions into Home Assistant as device tracker entities — at which point the rest of my automations read them like any other presence sensor.

End to end, then: macOS refreshes a local Find My cache → a macOS-side agent reads and decrypts it → Home Assistant publishes it as a device tracker. The practical win is real presence data without my iCloud account being handed to anything.

Is it robust? No, and you should plan around that

• It reads a private cache, not a documented API. Apple publishes nothing about this. When the format changes — and it can change without warning — the feed may just go quiet, and the fix is whatever an open-source project has shipped by then, or nothing at all.
• Silence looks like “still at home”. A stalled feed doesn’t raise an error; Home Assistant holds the last known position. Automations built on that can make the wrong decision very confidently.
• Every hackintosh problem comes with it. The EFI and kext work is still the foundation, and the update treadmill still comes round. A macOS update can break the graphics, the wireless card or the integration, and all of those are now your problem.
• You own the failure mode. No vendor, no support commitment, no warning before it stops.

I’d still do it again. If you need presence data to be boringly reliable, this is the wrong tool and a dedicated tracker is the right one — but for anyone comfortable owning an unofficial machine, this is the most useful thing the hackintosh has actually delivered.

Worth doing?

Do it if…	Don’t, if…
You already own a 7735HS mini PC and have a spare SSD.	The Mac has to do income-critical work — updates, support and reliable sleep all come with a real one.
You want a lab machine for tinkering, testing or light duty, and you can back it up.	You need Continuity — AirDrop and Handoff usually want Broadcom Wi-Fi.
You can spend an evening and a USB stick on it, and treat the first Sonoma update that lands on your machine as a research project.	You need heavy video work. There is no discrete GPU option — the 680M is the ceiling.

The honest summary: on paper the 8 Zen 3+ cores are plenty, and the 680M carries the desktop experience better than you’d expect from integrated graphics. What separates “supported” from “works fine with the right EFI folder” turns out to be less than you’d expect — but the right EFI folder is non-negotiable, and the update treadmill never stops.