June 2017: High Sierra Beta, Kaby Lake iGPU, and ACPI Stability

The release of macOS High Sierra Developer Preview 1 on June 5, 2017, at WWDC marked a turning point for the Hackintosh community. While the final release would not arrive until September, the beta cycle exposed several hard limits for builders running Kaby Lake and Skylake hardware. In this retrospective, I examine the concrete changes that landed in June 2017: the new APFS file system requirements, the first signs of Kaby Lake integrated graphics support, and the ACPI patching patterns that became necessary to avoid kernel panics on X99 and Z270 platforms.

If you are still maintaining a Sierra 10.12.5 installation and considering the upgrade path, the June beta period is where the real compatibility boundaries were drawn. The following sections cover what actually changed under the hood and how it affected existing configurations.

APFS Conversion: The First Boot Trap

High Sierra Developer Preview 1 automatically converted HFS+ volumes to APFS during installation on solid-state drives. For Hackintosh builders, this introduced a critical failure point: if your bootloader (Clover r4077 or earlier) did not include APFS driver support, the system would immediately kernel panic on reboot. The community quickly published updated Clover builds with ApfsDriverLoader-64.efi and AppleImageLoader-64.efi, but many users who attempted the beta on unsupported configurations lost access to their data.

The safe approach in June 2017 was to clone your existing Sierra installation to a separate test SSD, install the beta on that drive, and verify that your bootloader could handle APFS before touching the primary system. If you were using a Samsung 850 EVO or similar SATA SSD, the conversion to APFS also required a firmware check: drives with older firmware sometimes exhibited TRIM-related stalls after conversion. Updating the SSD firmware before the beta installation was mandatory.

Kaby Lake iGPU: Partial Support in DP1

One of the most anticipated features of High Sierra was native support for Intel Kaby Lake integrated graphics (HD 610, HD 615, HD 620, HD 630). In Sierra 10.12.4 and 10.12.5, the Kaby Lake iGPU required the IntelGraphicsFixup.kext and Shiki.kext combo, plus a fake device-id of 0x19120000 (Skylake) to enable basic acceleration. The June beta changed this: for the first time, High Sierra included native framebuffer kexts for Kaby Lake, specifically IntelKBLGraphicsFramebuffer.kext.

However, support was incomplete. The framebuffer patches for connector-less laptops (e.g., HDMI-only mini‑ITX boards) still required manual injection. The native driver worked best on desktop boards with DP or DVI output. If you were running a Z270 board with a Core i7‑7700K and a dedicated GPU, you could now disable the iGPU entirely without patching — but users relying solely on the iGPU for output still needed to inject ig-platform-id values such as 0x59120000 for desktop or 0x591B0000 for mobile. The beta also introduced a regression: systems using the 0x19120000 spoof from Sierra would panic on boot. You had to remove the fake device-id and switch to the native Kaby Lake ID.

ACPI Changes: The _DSM to _SB.PCI0 Rename

Apple’s ACPI implementation in High Sierra DP1 tightened the rules for device identification. Many DSDT patches that worked in Sierra — particularly the _DSM methods for injecting properties into IMEI, HDEF, and XHCI — began causing wake failures and immediate sleep panic. The root cause was a change in how the XNU kernel parsed the _PRW (Power Resource for Wake) objects. In Sierra, a missing or malformed _PRW on the IMEI device (0x00160000) was tolerated. In High Sierra, it triggered a kernel panic on wake.

The fix involved renaming _DSM to XDSM in your Clover ACPI patches and using a custom SSDT to supply the correct _PRW return value. For X99 systems, the same issue affected the XHCI controller. The community-developed SSDT-XHC.aml needed an update to include the _PRW object with return 0x0D (for port 13). Without this, any USB device plugged into a rear port would wake the system, then immediately crash it. I covered this pattern in detail in a prior piece on Fixing ACPI Panics on X79/X99 Hackintosh for macOS High Sierra, and the same principles applied to Z270 boards with the 200-series chipset.

Ethernet and Audio: The June Breakage

Realtek RTL8111 Ethernet users faced a surprise in the beta: the RealtekRTL8111.kext version 2.2.0, which worked flawlessly in Sierra, caused a panic on boot when loading in High Sierra DP1. The panic originated from a change in the IONetworkingFamily’s memory allocation routines. The developer (Mieze) released a beta kext (2.2.1d1) on June 10 that replaced the deprecated IOMalloc calls with IOMallocAligned. If you compiled your own kext, you had to bump the deployment target to macOS 10.13 and add a check for the IOEthernetController class version. For a full breakdown of chip revisions and kext compatibility, see the article on Fixing Realtek RTL8111 Ethernet on Hackintosh High Sierra.

Audio was less affected. AppleALC 1.1.3 (released June 8, 2017) added layout IDs for several ALC1220 and ALC1150 codecs that were missing in the initial beta. If you used VoodooHDA, the kext loaded but produced distorted output on HDA-enabled motherboards — a known issue with the IOAudioFamily changes in the beta. The recommendation was to stick with AppleALC and inject the correct layout ID via Clover’s Devices > Audio > Inject.

Bootloader Updates: Clover r4080 and EmuVariableUefi

Clover r4080, released on June 15, 2017, was the first version to fully support High Sierra DP1. The critical changes were in OsxAptioFix2Drv-64.efi and EmuVariableUefi-64.efi. The beta introduced a new memory map layout that caused the old OsxAptioFixDrv (version 1) to hang at Error allocating 0x... pages. Users had to switch to OsxAptioFix2Drv or OsxAptioFix3Drv. Additionally, NVRAM emulation via EmuVariableUefi became mandatory for systems without native NVRAM (most Z270 boards), because High Sierra stores the boot‑volume UUID in NVRAM and panics if it cannot read it on the second stage of boot.

The configuration checklist for a stable June 2017 build was:

• Update Clover to r4080 or newer
• Use OsxAptioFix2Drv-64.efi (not FixDrv)
• Enable EmuVariableUefi-64.efi
• Add ApfsDriverLoader-64.efi to drivers64UEFI
• Remove fake device-id for Kaby Lake iGPU (if spoofing Skylake)
• Inject ig-platform-id 0x59120000 for desktop Kaby Lake iGPU
• Update RealtekRTL8111 to 2.2.1d1 or later
• Update AppleALC to 1.1.3
• Add custom SSDT-XHC.aml with corrected _PRW for X99 and Z270

Known Risks and Data Preservation

Installing the High Sierra beta on a production Hackintosh in June 2017 carried real risks. The APFS conversion was irreversible without reformatting the drive. The beta’s graphics stack crashed on certain Kabylake‑R (Kaby Lake Refresh) CPUs that would not be released until August 2017, but early engineering samples existed in the community — those machines would boot to a black screen. The ACPI wake panic described above could corrupt open files if the system crashed during a write.

If you still have a June 2017 backup of your Sierra installation, it is worth preserving the exact kext versions and Clover configuration that worked. Many builders archived their /EFI folder with a date stamp. That practice remains the single most effective way to recover from a failed upgrade. The beta period of High Sierra taught the community that incremental testing on a secondary drive is not optional — it is the only reliable method when Apple changes the file system, graphics driver model, and ACPI parser in a single release.

For those who waited until the public beta in July 2017, many of the issues described here were partially resolved. But the June DP1 configurations remain historically relevant: they document the exact breaking points that forced the community to adapt bootloader and kext practices that are still in use today.