MacOS Sequoia 15.7.5 killed Continuity on my Hackintosh

[Anubis111]

Attach the PR files to have a look!

Hi,
I have attached a ZIP with my current EFI folder (serials/SMBIOS data redacted), an IORegistryExplorer dump (IOReg) from macOS Sequoia 15.7.5, and a verbose boot photo showing where the system pauses around AppleKeyStore / AirPlayXPCHelper / bluetoothd.

Hardware / setup:
Asus Prime H270-Plus, Intel i7
Intel iGPU (HD 530) enabled with framebuffer patches (not fully headless), dGPU AMD Radeon RX 570 used as primary display GPU
SMBIOS: iMacPro1,1
Fenvi T919 (Broadcom) in PCIe slot for Wi‑Fi and Bluetooth
OpenCore config built and maintained by myself over the years, regularly updated for newer macOS versions

macOS / OCLP / kexts:
macOS Sequoia 15.7.5 (15.7.4 was working fine)
I am using OpenCore Legacy Patcher only for Broadcom Wi‑Fi/BT patches for the Fenvi card
To make the OCLP Broadcom patch work with my own OpenCore EFI, I manually added:
IOSkywalkFamily.kext
IO80211FamilyLegacy.kext
into my EFI/OC/Kexts and configured them in config.plist
Lilu, WhateverGreen, VirtualSMC, AppleALC and the other main kexts are up to date

Main problem (Continuity / Continuity Camera):
For years, Continuity and Continuity Camera worked perfectly on this Hackintosh:
iPhone was detected automatically over Wi‑Fi
iPhone as camera + microphone in Zoom and other apps without any hacks

After updating from Sequoia 15.7.4 to 15.7.5, Continuity partially broke:
iPhone is still visible in Finder over USB, photos can be imported
Continuity Camera only works when the iPhone is connected with a USB cable
Over Wi‑Fi the iPhone is no longer detected as a camera/microphone

On the same macOS Sequoia 15.7.5 and the same iOS version, Continuity Camera still works normally on my real MacBook Pro, so the issue seems to be Hackintosh‑specific.

Boot / AppleKeyStore logs:
I boot with -v and see repeated AppleKeyStore messages related to AirPlay and Bluetooth:
AppleKeyStore: unexpected session uid: -1 requested by: AirPlayXPCHelper (…)
AppleKeyStore: operation failed (sel: 7 ret: e00002c2 / e00002f0)
similar unexpected session uid and operation failed messages for bluetoothd
Before, these messages appeared very briefly and the boot continued almost immediately
Now there is a noticeable pause around the AppleKeyStore messages (subjectively shorter after some recent changes, see below, but still visible)

OpenCore patches (Kernel -> Patch):
Skip Board ID check -> Enabled = true
Disable RTC wake scheduling -> Enabled = true
Skip AppleKeyStore T2 init wait -> Enabled = false
Enable TRIM for SSD -> Enabled = false (TRIM works via macOS and is not needed for NVMe/AHCI here)

After disabling the AppleKeyStore T2 patch, the pause at AppleKeyStore during boot feels shorter, but the Continuity Camera issue over Wi‑Fi is still present.

Other notes:
OpenCore config.plist structure validates fine (no syntax errors)
I corrected an old placeholder DevicePath in my config (Path to BOOTX64.EFI) using a fresh DevPath from OpenShell (bcfg boot dump), so that part should now match the real NVMe/EFI partition
I do not have OpenCore boot logs (OC log file) despite having Debug settings enabled; this has been a long‑standing limitation on this machine
Instead, I provide IOReg + EFI and a verbose boot photo showing where the system pauses around AppleKeyStore / AirPlayXPCHelper / bluetoothd

Question:
Could you please take a look at my EFI and IOReg and advise:
whether the current Broadcom / OCLP Wi‑Fi + BT setup (Fenvi T919 + IOSkywalkFamily.kext + IO80211FamilyLegacy.kext) looks correct for Sequoia 15.7.5 on iMacPro1,1 SMBIOS with RX 570 and enabled HD 530 iGPU with framebuffer patches,
whether the AppleKeyStore errors from AirPlayXPCHelper and bluetoothd suggest a misconfiguration in my OpenCore/ACPI/kexts, or if this is more likely a side effect of OCLP’s Broadcom patches on Sequoia,
and if there is anything obvious I should change to restore full Continuity Camera over Wi‑Fi (as it worked before on 15.7.4)?

Thank you in advance for any hints. If needed, I can provide additional verbose boot photos focusing on the AppleKeyStore / AirPlayXPCHelper / bluetoothd messages.

 

[EliteMacx86]

Hi,
I have attached a ZIP with my current EFI folder (serials/SMBIOS data redacted), an IORegistryExplorer dump (IOReg) from macOS Sequoia 15.7.5, and a verbose boot photo showing where the system pauses around AppleKeyStore / AirPlayXPCHelper / bluetoothd.

Hardware / setup:
Asus Prime H270-Plus, Intel i7
Intel iGPU (HD 530) enabled with framebuffer patches (not fully headless), dGPU AMD Radeon RX 570 used as primary display GPU
SMBIOS: iMacPro1,1
Fenvi T919 (Broadcom) in PCIe slot for Wi‑Fi and Bluetooth
OpenCore config built and maintained by myself over the years, regularly updated for newer macOS versions

macOS / OCLP / kexts:
macOS Sequoia 15.7.5 (15.7.4 was working fine)
I am using OpenCore Legacy Patcher only for Broadcom Wi‑Fi/BT patches for the Fenvi card
To make the OCLP Broadcom patch work with my own OpenCore EFI, I manually added:
IOSkywalkFamily.kext
IO80211FamilyLegacy.kext
into my EFI/OC/Kexts and configured them in config.plist
Lilu, WhateverGreen, VirtualSMC, AppleALC and the other main kexts are up to date

Main problem (Continuity / Continuity Camera):
For years, Continuity and Continuity Camera worked perfectly on this Hackintosh:
iPhone was detected automatically over Wi‑Fi
iPhone as camera + microphone in Zoom and other apps without any hacks

After updating from Sequoia 15.7.4 to 15.7.5, Continuity partially broke:
iPhone is still visible in Finder over USB, photos can be imported
Continuity Camera only works when the iPhone is connected with a USB cable
Over Wi‑Fi the iPhone is no longer detected as a camera/microphone

On the same macOS Sequoia 15.7.5 and the same iOS version, Continuity Camera still works normally on my real MacBook Pro, so the issue seems to be Hackintosh‑specific.

Boot / AppleKeyStore logs:
I boot with -v and see repeated AppleKeyStore messages related to AirPlay and Bluetooth:
AppleKeyStore: unexpected session uid: -1 requested by: AirPlayXPCHelper (…)
AppleKeyStore: operation failed (sel: 7 ret: e00002c2 / e00002f0)
similar unexpected session uid and operation failed messages for bluetoothd
Before, these messages appeared very briefly and the boot continued almost immediately
Now there is a noticeable pause around the AppleKeyStore messages (subjectively shorter after some recent changes, see below, but still visible)

OpenCore patches (Kernel -> Patch):
Skip Board ID check -> Enabled = true
Disable RTC wake scheduling -> Enabled = true
Skip AppleKeyStore T2 init wait -> Enabled = false
Enable TRIM for SSD -> Enabled = false (TRIM works via macOS and is not needed for NVMe/AHCI here)

After disabling the AppleKeyStore T2 patch, the pause at AppleKeyStore during boot feels shorter, but the Continuity Camera issue over Wi‑Fi is still present.

Other notes:
OpenCore config.plist structure validates fine (no syntax errors)
I corrected an old placeholder DevicePath in my config (Path to BOOTX64.EFI) using a fresh DevPath from OpenShell (bcfg boot dump), so that part should now match the real NVMe/EFI partition
I do not have OpenCore boot logs (OC log file) despite having Debug settings enabled; this has been a long‑standing limitation on this machine
Instead, I provide IOReg + EFI and a verbose boot photo showing where the system pauses around AppleKeyStore / AirPlayXPCHelper / bluetoothd

Question:
Could you please take a look at my EFI and IOReg and advise:
whether the current Broadcom / OCLP Wi‑Fi + BT setup (Fenvi T919 + IOSkywalkFamily.kext + IO80211FamilyLegacy.kext) looks correct for Sequoia 15.7.5 on iMacPro1,1 SMBIOS with RX 570 and enabled HD 530 iGPU with framebuffer patches,
whether the AppleKeyStore errors from AirPlayXPCHelper and bluetoothd suggest a misconfiguration in my OpenCore/ACPI/kexts, or if this is more likely a side effect of OCLP’s Broadcom patches on Sequoia,
and if there is anything obvious I should change to restore full Continuity Camera over Wi‑Fi (as it worked before on 15.7.4)?

Thank you in advance for any hints. If needed, I can provide additional verbose boot photos focusing on the AppleKeyStore / AirPlayXPCHelper / bluetoothd messages.

Your config.plist is not as per the guide.

Make the following changes to the config.plist

- Remove ResetLogoStatus
- DevirtualiseMmio shouldn't be required.
- RebuildAppleMemoryMap shouldn't be required.
- FixupAppleEfiImages shouldn't be required
- The framebuffer does not seem to be setup in headless mode.
- Kexts ordering is not correct. Important kexts should load first.
- Remove NVMeFix. What's the SSD drive you're using?
- Disable AppleXcpmExtraMsrs and AppleXcpmForceBoost. The latter defeats the purpose of XCPM.
- Disable CustomSMBIOSGuid. It shouldn't be required for your hardware.
- Disable DisableIoMapper and DisableIoMapperMapping and implement VT-d.
- DisableRtcChecksum and ThirdPartyDrive shouldn't be required.
- You should consider removing -no_compat_check as you're already using iMacPro1,1. Moreover, you should use iMac SMBIOS for better results.
- You should set the UpdateSMBIOSMode to Create.

 

[Anubis111]

Thank you for your reply, I really appreciate it. I will now start applying the corrections to my config.plist according to your post. Here is the information about my SSD: WD_Black SN770 1TB. Understood – I will try removing NVMeFix.kext.

 

[EliteMacx86]

Thank you for your reply, I really appreciate it. I will now start applying the corrections to my config.plist according to your post. Here is the information about my SSD: WD_Black SN770 1TB. Understood – I will try removing NVMeFix.kext.

No problem. Happy to help!

SN770 is a poor choice, not just for macOS but as in general. It has no DRAM.

 

[Anubis111]

Hi again,

I went through your checklist and also cleaned up my iGPU configuration to a proper headless setup. Let me summarize exactly what changed and what I’m still seeing.

1. Changes applied to config.plist​

From your checklist I applied the following:

• Removed / disabled:
  
  • ResetLogoStatus
  • DevirtualiseMmio
  • RebuildAppleMemoryMap
  • FixupAppleEfiImages
• Fixed kext load order so that the important kexts (Lilu, WhateverGreen, VirtualSMC, AppleALC, etc.) load first.
• Removed NVMeFix.kext (my main macOS SSD is a WD Black SN770).
• Disabled AppleXcpmExtraMsrs and AppleXcpmForceBoost.
• Disabled CustomSMBIOSGuid.
• Disabled DisableIoMapper and DisableIoMapperMapping, as you suggested.
• Disabled DisableRtcChecksum and ThirdPartyDrive.
• Removed -no_compat_check (I’m already using iMacPro1,1 SMBIOS).

I did not change UpdateSMBIOSMode to Create. I kept it on Custom, because I have a long‑standing iMacPro1,1 SMBIOS with a real‑world serial/MLB/ROM that’s been stable for years, and I’d like to avoid regenerating a new identity if possible.

My PlatformInfo → Generic block (SystemProductName = iMacPro1,1, SystemSerialNumber, MLB, ROM, SystemUUID) is bit‑for‑bit identical to the config from before these changes.

2. Headless iGPU configuration​

Originally my Intel HD 530 iGPU was configured with a non‑headless framebuffer and a bunch of framebuffer patches (enable-hdmi20, framebuffer-con0/1/2-*, fbmem, stolenmem, unifiedmem, flags, framebuffer-has-headless, etc.).

Following your remark that “The framebuffer does not seem to be setup in headless mode”, I reworked it to a clean headless setup:

• AAPL,ig-platform-id changed to 0x19120003 (base64 AwASGQ==) – headless Skylake.
• Removed all connector / framebuffer patch keys (enable-hdmi20, framebuffer-con0/1/2-*, fbmem, flags, stolenmem, unifiedmem, framebuffer-patch-enable, framebuffer-has-headless).
• Kept only:
  
  • AAPL,slot-name = Internal@0,2,0
  • device-id (HD 530)
  • device_type = Display controller
  • hda-gfx = onboard-1
  • model = Intel HD Graphics 530

Now RX 570 is the only display GPU; HD 530 runs purely as headless iGPU. Hackintool reports:

• Platform ID = 0x19120003
• VDA Decoder = Fully Supported
• RX 570 with full Metal and QE/CI.

3. VT‑d situation (BIOS vs macOS)​

In BIOS:

• Intel Virtualization (VT‑x) was and still is Enabled.
• Intel VT‑d was actually Disabled. I enabled VT‑d to match your recommendation (“Disable DisableIoMapper / DisableIoMapperMapping and implement VT‑d”).

With VT‑d Enabled in BIOS:

• Keyboard works fine in the OpenCore picker.
• As soon as macOS reaches the login screen, both my Apple USB keyboard and Bluetooth keyboard stop working completely. I can’t type my password at all.
• This is reproducible – several attempts gave the same result.

Because of that, I reverted VT‑d in BIOS back to Disabled, otherwise I simply can’t log into macOS. With VT‑d disabled, the system is usable again and all USB/BT input works as before.

So at the moment I have:

• VT‑d = Disabled in BIOS
• DisableIoMapper / DisableIoMapperMapping = Disabled in OpenCore (as per your checklist)

4. What improved after these changes​

After the config changes + headless iGPU:

• System feels more responsive after login. Apps and browser windows open noticeably faster.
• Display layout and resolutions were re‑detected; I quickly re‑arranged the monitors in System Settings and restored the higher resolution on the left monitor via BetterDisplay.
• Continuity Camera over USB is back to working: I can use my iPhone as a wired camera/microphone in Zoom and other apps, just like before Sequoia 15.7.5.
• “Find My Mac” finally activated correctly for this Hackintosh in System Settings → Apple ID → Find My Mac. For years I was unable to fully enable it; now it’s finally ON.

So there are clear positive effects from your tweaks and the headless framebuffer change.

5. Issues that are still present​

However, a few problems remain:

1. AppleKeyStore / boot spam
   
   • Verbose boot still pauses around AppleKeyStore / AirPlayXPCHelper / bluetoothd (similar to the screenshot I posted earlier). The pause might be slightly shorter than before, but the repeated AppleKeyStore messages are still there.
2. Wrong model/serial in macOS UI and tools
   
   • “About This Mac” / System Information → Hardware shows:
     
     • Model Name: “Mac”
     • Model Identifier: “System Product Name”
     • Processor Name: “Unknown” (4.0 GHz, 4 cores, Hyper‑Threading enabled, 36 GB RAM).
   • Hackintool’s System Info decodes the SMBIOS in a strange way (e.g. Model Identifier: MacBook1,1, “Valid: Unlikely”), even though PlatformInfo → Generic contains my original iMacPro1,1 SMBIOS (same serial, MLB, ROM, SystemUUID as before all these changes).
3. Licenses broke
   
   • After these changes and internal identity changes, several app licenses disappeared (VideoProc, Boom 3D, MS Office, etc.). I know I can fix them manually, but it’s clearly a sign that macOS now “sees” this machine differently than before.
4. iStat and GPU visibility
   
   • iStat Menus no longer shows the GPU properly, despite RX 570 having full Metal support and the headless iGPU being reported as fully supported in VDA.
5. Continuity over Wi‑Fi still broken
   
   • Continuity Camera over USB now works again, but over Wi‑Fi the iPhone is still not seen as a camera/mic by macOS, which matches what I described originally for Sequoia 15.7.5.

6. Current PlatformInfo state​

Just to be absolutely clear:

• PlatformInfo → Generic is identical to my pre‑change config (iMacPro1,1, real serial/MLB/ROM/UUID).
• Automatic = true, UpdateDataHub = true, UpdateNVRAM = true, UpdateSMBIOS = true, UpdateSMBIOSMode = Custom.
• CustomSMBIOSGuid = Disabled as per your recommendation.

Despite that, macOS UI still reports “Mac / System Product Name / System Serial Number / Unknown CPU”, and Hackintool’s SMBIOS decoder still shows an odd MacBook1,1 mapping.

---

Given all this:

• Headless iGPU + your config tweaks clearly improved responsiveness, USB Continuity and finally enabled Find My Mac.
• But model/serial reporting in System Information is still wrong, AppleKeyStore spam remains, licenses were invalidated, and Wi‑Fi Continuity Camera is still dead.

Do you see anything else in my current setup (especially around SMBIOS/VT‑d/AppleKeyStore) that could explain why macOS still presents the machine as “Mac / System Product Name / Unknown”, even though the PlatformInfo → Generic block is correct and matches my long‑standing iMacPro1,1 SMBIOS?

Any hints on what to check next (or whether this is just a Sequoia 15.7.5 + OCLP/Broadcom oddity) would be greatly appreciated.