Gigabyte Z390 M, OpenCore, and Hackintosh Catalina: A Beginner’s Guide and Key Resources

My home screen!


I realise build guides are a dime a dozen, but it’s always reassuring to see one by someone who’s used a combination of components as similar to yours as possible, and even more so when that someone happens to be a newbie – so here I am, with the steps I followed to get macOS Catalina up and running on the tower I’d built. 

I’ll take this step by step, and will make an effort to avoid confusing language. Of course, if you have any questions, feel free to ask, after you’ve read the whole thing! Just bear in mind that I, too, am a novice.

Moreover, I have next to no experience with Ryzen builds, or prebuilt machines like laptops, so again, this guide is specific to modern Intel builds and chipsets. If you need help selecting components, look no further than this brilliant, concise guide by Mykola. My guide is by and large limited to the processes I followed, though I’ll try to include alternative steps for anyone that may need them.

Lastly, this guide may be extra handy for Indian Hackintosh enthusiasts — all my components were purchased in in India itself. So if you’re a fellow Indian interested in building one of these for yourself, there’s a good chance these components are readily available for you without having to import anything.

But first, some vanity shots:

My old faithful 1080p ASUS monitor, I hope to replace it with a better 1440p 100% sRGB one soon!
Pretty low-end as far as cases go, but very practical! NZXT cases are quite expensive in my country…
The innards! It’s actually a lot better cable-managed than it looks here.

Before You Get Started:

You HAVE to be a computer enthusiast, and have basic knowledge of how computers work. It’s crucial that you understand that there are no shortcuts to this. 

Morgonaut’s videos on YouTube are an example of what not to do — if you blindly follow what someone spoonfeeds you without truly understanding why something works the way it works, you’re setting yourself up for failure, and we won’t be able to help you because you wouldn’t be able to tell us what you’ve done. 

This also applies to tonymacx86 tools like Unibeast; they take user-intervention and transparency out of a process that absolutely depends on both of those to work reliably.

Hackintoshing is a precise process to begin with, and what works for someone else may not necessarily work for you. Take the time and effort to read through every line of the more specific guides I’ll be linking further ahead, and toggle exactly what is specific to your hardware. What you don’t get, r/Hackintosh and its Discord channel will be happy to lend you a hand with.

Don’t be anxious! It’s an intimidating prospect when you’re doing it for the first time, but once you’ve got everything up and running, you’ll realise that the process is actually pretty straightforward.

The Hardware:

The first thing you’ll need to do is, of course, build a computer, so build a computer, I did. Here are my components:

The parts that will affect your Hackintosh setup:

  • Motherboard — Gigabyte Z90 M
  • Processor — Intel i7-9700K
  • Graphics Card — Sapphire Pulse Radeon RX 580
  • Storage — WD Black SN750 (500GB)
  • WiFi + Bluetooth PCIe Card — Fenvi HB-1200

The parts that normally won’t:

  • RAM — 32GB, 2400MHz, DDR4 (Crucial CU16GU2400, 16GB x 2)
  • Power Supply — Antec NeoEco 650M (650W, rated Bronze)
  • CPU Cooler —Antec C400 Elite
  • Case — Corsair SPEC 01
  • Fans — Antec Spark 120mm x 4 (that’s a total of five fans, including the one that comes with the case)

You’ll notice that I’m using a Z390 motherboard, something Mykola explicitly advises against in the guide I’d linked above. He’s right — the best motherboard for Hackintosh computers is the slightly older Z370 series. It supports all the same processors that the Z390 chipset does, though you’ll need a BIOS update to run 9th gen Coffee Lake chips. More importantly, Z370 boards come with native NVRAM support, which is something macOS requires to function smoothly. 

The Z390 motherboards don’t have native NVRAM, but there’s a workaround to emulate it. If you’re starting from scratch, this becomes an unnecessary step, so stick with the Z370 series. However if you, like me, weren’t aware of this at the time of buying your components, no stress! The workaround to emulate NVRAM support is a rather easy one. 

Besides this, the other oddity you’ll notice is the Fenvi HB-1200. Here’s the deal: MacOS normally plays well only with very specific Broadcom cards for perfect WiFi and Bluetooth connectivity. So if you want AirDrop and Handoff to function properly on your Hackintosh build, you’ll need one of these things. Installing them is very easy, though, and if you’re unable to find one locally, AliExpress sells these in great abundance. It’ll take about 2-3 weeks to reach you, though. Until then, your only option for internet connectivity is via Ethernet. A more high-end alternative of the same is the Fenvi T919.

Finally, macOS has no built-in framework for controlling the RGB lighting in your system. If you want to control the lighting via your motherboard’s RGB header, you’ll have to do it via BIOS. If even this option isn’t available, a hardware remote is your best bet*, I’m using this one

*You can mess with your RGB settings via Windows and have your settings persist when you reboot into macOS, but for this, Windows will have to be installed on a partition in the same disk as macOS. This often causes a number of complications and is generally not recommended. 

We now move on to the nitty and the gritty, the part of this process that puts the “Hack” in Hackintosh:

Setting up macOS Catalina:


The recommended method for getting started with a Hackintosh build — the vanilla method — involves having an actual Mac device around. It gives you the simplest, most reliable, and trustworthy way to download a fresh copy of macOS Catalina, straight from Apple’s own App Store. The download itself is free and won’t cost you anything. If you don’t own a Mac, borrow a friends’ — this way, you can also natively format your Catalina USB drive to a Mac-compatible format using macOS’ built-in tools, rather than having to rely on third-party methods.

With this in mind, the guide I’d followed is the OpenCore Vanilla Desktop Guide, once again by the brilliant Mykola. I’ll be referring to this multiple times, and will straight up link directly to it where I don’t have anything specific to my experience to add. Remember, my guide is sort of like an addon to Mykola’s Vanilla guide, and is NOT meant to act as a replacement.

A proven alternative method for those don’t have access to a Mac is Midi Jari’s Internet Install method. I have no experience with this, though, so I can’t really comment on what this entails. But it’s also a trusted method and has produced successful results for many folks here, so don’t stress out unduly! It’s just not something that I personally have used, given I simply borrowed my girfriend’s MacBook for this purpose.

The only other hardware you’ll need is a 16GB USB drive. Until macOS Mojave — the previous version — 8GB USB drives were enough to hold macOS, but unfortunately, Catalina is slightly larger than 8GB, so 16GB drives are the new minimum.

A Brief Prologue:

Here’s a grossly oversimplified primer on how macOS (or any OS, really) boots on a Hackintosh system:

BIOS —> Bootloader —> macOS

Similarly, let’s take this step by step.


First, your motherboard’s BIOS fires up. This is normally where the “Gigabyte” or “Asus” or whichever else company’s logo pops up, depending on your motherboard’s make. Here, repeatedly tapping on a button — which can vary from manufacturer to manufacturer — should take you to your BIOS’s settings. This is where your setup process begins.

MacOS requires a specific set of BIOS settings to be toggled, which can be a little daunting for first timers. Luckily, Mykola’s got your standard BIOS settings covered in his guide, so simply reset your BIOS to its optimised defaults, and make the necessary changes he’s highlighted here.

Once this is done, we move on to the big one:

The Bootloader, OpenCore:

The bootloader is the key to achieving a successful Hackintosh build, and this is where most of your efforts will be directed.

Ordinarily, on most Windows computers and actual Macs, the bootloader is invisible; you wouldn’t even know it exists beyond the existence of the loading screen. Given we’re off the beaten path, we will need to use a custom bootloader put together by several smart people in the community. This custom bootloader is what will let us boot macOS on non-Apple hardware.

Until very recently, Clover had been the standard bootloader for all Hackintosh builds. It’s well-documented, has a GUI that you’re used to operating, and comes with thousands upon thousands of guides and years of documented online support. It is also, however, nearing the end of its life. A lot of its code is deprecated, unmaintained, and can break anytime.

This brings us to OpenCore — a spanking new bootloader that many believe is the future of Hackintoshing. It’s designed to be a whole lot more flexible than Clover, and uses more modern protocols to offer a far stronger degree of futureproofiness — and dramatically faster boot times, to boot. There’s certainly a lot about it I don’t fully understand, but it’s been painstakingly documented over here in acidenthera’s GitHub page, so do pop over and give it a read if you’re interested.

It’s in the final stages of beta testing — v0.5.3 at the time of writing this — and aims to be released as a stable, public v1.0 build in the coming weeks. Given it’s so close to release, as long as you’re not running a laptop or a prebuilt, OpenCore will run just fine for you once properly setup. Seriously — if you’re not scared of a more transparent process where you have far more control over what your bootloader will end up doing, OpenCore is the way to go.

At this juncture, I’ll simply redirect you to Mykola’s guide, full on. It summarises the process of setting up OpenCore as simply as possible without skimping on important details. 

I do, however, have three points to add:

  1. In this guide I’m writing, I’d originally wanted to include an issue specific to my motherboard model that Mykola walked me through because it wasn’t in the guide (and I’m a newbie), but he went ahead and added it to his guide so idiots like me wouldn’t run into the same problem in future; the parts of his guide referring to CFG Lock settings in the configuration file and the BIOS allude to this.
  2. Once you clone/download OpenCorePKG, use macbuild.tool to compile your copy of OpenCore. Once the process finishes, you’ll find the folder you need in the same folder, under:

Binaries > Release > (the contents of this zip file are what you ultimately need)

  1. HfsPlus.efi is preferable over VboxHfs.efi. This is because HfsPlus.efi is Apple’s own driver for reading HFS volumes, wheres VboxHfs.efi is an open source variant that’s quite a bit slower, but is a better bet if you prefer playing it safe and like your code open source.

My OpenCore EFI folder structure:

Here, you can also have a look at my drivers and kexts. You’ll also notice a file called SSDT-UIAC.aml which isn’t explicitly present in Mykola’s writeup, but is something every Hackintosh user needs to build for themselves. This particular file is called a custom SSDT, and I’ll get into it in just a moment.

 ├── APPLE
 │   │   └── Firmware.scap
 │   └── UPDATERS
 │       └── MULTIUPDATER
 │           ├── Mac-BE088AF8C5EB4FA2.epm
 │           ├── Mac-BE088AF8C5EB4FA2.smc
 │           ├── MultiUpdater.efi
 │           ├── SmcFlasher.efi
 │           ├── flasher_base.smc
 │           └── flasher_update.smc
 ├── BOOT
 │   └── BOOTx64.efi
 └── OC
     ├── ACPI
     │   ├── SSDT-AWAC.aml
     │   ├── SSDT-EC-USBX.aml
     │   └── SSDT-UIAC.aml
     ├── Drivers
     │   ├── ApfsDriverLoader.efi
     │   ├── FwRuntimeServices.efi
     │   └── HFSPlus.efi
     ├── Kexts
     │   ├── AppleALC.kext
     │   │   └── Contents
     │   │       ├── Info.plist
     │   │       └── MacOS
     │   │           └── AppleALC
     │   ├── IntelMausi.kext
     │   │   └── Contents
     │   │       ├── Info.plist
     │   │       └── MacOS
     │   │           └── IntelMausi
     │   ├── Lilu.kext
     │   │   └── Contents
     │   │       ├── Info.plist
     │   │       └── MacOS
     │   │           └── Lilu
     │   ├── SMCProcessor.kext
     │   │   └── Contents
     │   │       ├── Info.plist
     │   │       └── MacOS
     │   │           └── SMCProcessor
     │   ├── SMCSuperIO.kext
     │   │   └── Contents
     │   │       ├── Info.plist
     │   │       └── MacOS
     │   │           └── SMCSuperIO
     │   ├── USBInjectAll.kext
     │   │   └── Contents
     │   │       ├── Info.plist
     │   │       └── MacOS
     │   │           └── USBInjectAll
     │   ├── VirtualSMC.kext
     │   │   └── Contents
     │   │       ├── Info.plist
     │   │       └── MacOS
     │   │           └── VirtualSMC
     │   ├── WhateverGreen.kext
     │   │   └── Contents
     │   │       ├── Info.plist
     │   │       └── MacOS
     │   │           └── WhateverGreen
     │   └── XHCI-unsupported.kext
     │       └── Contents
     │           └── Info.plist
     ├── OpenCore.efi
     ├── Tools
     │   └── Shell.efi
     └── config.plist

You can find my config.plist over here, but once again, be warned — no good ever came off of copy-pasting without at least some superficial understanding of the flags I’ve toggled in my .plist.

Once you’ve got all of this sorted, your OpenCore folder is now ready! 

Follow the instructions here to make yourself a USB drive to install macOS Catalina from (assuming you’ve already downloaded it from the App Store and quit the installer). Once the process is complete — it should take about 20 minutes — use this super handy Python script from Corp Newt to mount the EFI folder in your USB drive. Then simply copy the contents of your OpenCore folder to the EFI folder.

The final structure should be similar to the folder tree I’d shared above.

Installing macOS:

This is very straightforward. Boot from your USB drive, and when you arrive at the OpenCore selection menu, pick the partition in which your macOS installer is sitting. 

It is at this point that many first timers may see an error, indicating that you’ve overlooked something while setting up your OpenCore configuration. Don’t stress! Take a picture of the error you’re seeing, keep your hardware configuration and your EFI folder’s contents handy, and approach the subreddit or the Discord channel for help. It’s more often than not just a couple flags that need to be sorted out, after which you’ll be good to go.

Once you arrive at your macOS installer, before you do anything, find Disk Utility in it (it’s in one of the menus up top) and format your storage drive to Mac OS Extended (Journaled). Once that’s done, go right ahead and install the OS onto your disk!

There’s only a few things left to do after. One of them, Mykola’s already outlined — set up your NVRAM emulation if your motherboard doesn’t have native NVRAM. The other is setting up your custom SSDT. Let me explain why this is necessary.

Setting up your Custom SSDT:

MacOS, unlike Windows, has an interesting limitation: you’re limited to a maximum of 15 USB ports, including the internal ones sitting on your motherboard for Bluetooth connectivity, etc. To make matters worse, if you have a USB 3.0/3.1 port that’s backwards compatible with USB 2.0 connectors, to the OS, that one physical port counts as two ports — one for 3.0/3.1, one for 2.0. So even if your motherboard has exactly 15 physical USB ports, if even one of them is USB 3.0, you’re likely above the limit.

A second problem is, when you install macOS on a motherboard whose firmware isn’t specifically written for supporting macOS, it gets the placement of your USB ports wrong. So your super high-speed USB 3.0 port may not even recognise a USB 3.0 device plugged into it. This may also cause issues with your Hackintosh facing weird sleep/wake issues, among others.

This is where the USBInjectAll kext* comes in. If you’ve got it enabled, it’ll force macOS to “see” all the USB ports it possibly can, including ones that don’t physically exist on your motherboard. This isn’t a solution to get all your ports working, though — this shoots you well beyond the 15 port limit (you’ll likely see around 30 ports, instead), and will more often than not cause more problems than it fixes. This brings us to the custom SSDT — this file is what “talks” to UsbInjectAll, telling it which ports to inject and which ones to not bother injecting. Once you setup your SSDT file properly, you’ll have eliminated all the ports that don’t actually exist, or that you don’t intend to use, to bring the total number of ports down to 15, or lower. After this, macOS will communicate with your motherboard’s USB ports perfectly, the way you’d want it to.

*Some motherboards, such as mine, will require UsbInjectAll.kext to be accompanied by the XHCI-unsupported.kext for it to work properly.

Here’s another super handy Corp Newt Python script to very quickly map your USB ports. If you want a clearer understanding of what USB mapping is all about, I recommend this guide for newbies, and this one for people who want an even deeper dive into the subject.

Corp Newt’s script actually provides you with an alternative — once you’ve mapped your USB ports, you can either generate your custom SSDT file and place it in your ACPI folder the way I have, or you can generate an all-new kext called USBMap that will replace both the USBInjectAll kext and your SSDT file (you’ll still need XHCI-unsupported, though). USBMap is the more recommended method, as USBInjectAll isn’t maintained all that frequently, and could stop working properly after a macOS update.

Once you set up USBMap.kext (or your custom SSDT), you’ll never need to do it again for your motherboard, so be patient, set it up, and then forget about it. 

And that’s it!

You should have yourself a Hackintosh that just works. If you don’t, there’s a detailed post-install section in Mykola’s guide that should see you through common problems that occur once everything is up and running. If it doesn’t, you’re always welcome to share your troubles with us at the Discord channel, or in the subreddit. Just make sure that what you’re facing is a Hackintosh-related issue, rather than a macOS bug that’s all Apple’s fault. Enjoy!


I really can’t thank enough all the people who patiently sat down and helped me through my various rookie mistakes and anxieties. There are certainly more names — forgive my terrible retention — but among others, u/dracoflar, u/CorpNewt, and u/fewtarius have been invaluable in teaching me how to approach the entire process and in answering all the questions I had about the same. Thanks a billion, y’all.

The iPad Artist, Part 2: iPad Air (2019) vs Surface Go

Diving immediately into the process, I decided that I wanted a gadget beefy enough for it to not feel like a functional compromise.
Ideally, a portable art machine would cost around half as much as my laptop did. Armed with a budget of ₹42,000 ($600), I came to realise rather quickly that there were only two real options for me: Apple’s newly released iPad Air, or Microsoft’s Surface Go.

There were several good reasons I had for considering the Surface, key among them being:

  • My primary device already being a Windows 10 laptop, I wouldn’t have to spend time learning new keyboard shortcuts and getting used to new UI paradigms; the experience would largely be the same.
  • I wouldn’t have to buy new software, given all my existing purchases would work on my new device.
  • A “full“ desktop experience in tablet form factor.
  • A type-C port! As someone with half-hearted resolve to charge all my devices with a single cable, this would have been a nice step forward for me. Also, access to a wider variety of accessories and interfacing with external devices would have been a nice plus.

All of that being said, here’s what the iPad Air had going for it:

  • It already had an established user base of artists, which meant that every workaround or solution for most problems specific to my use case would have readily available documentation.
  • A top-to-bottom experience optimised specifically for tablets (which is occasionally to its detriment, such as still-fledgling mouse support, but is, for the most part, a pro)
  • Apps! So many top-tier tablet apps, and all of them invariably touch-optimised. On Windows 10, besides Microsoft’s half-decent first party apps and third-party offerings that you could probably count on one hand, it’s not really a top-to-bottom touch-centric experience, which was something I was specifically on the lookout for.
  • Significantly greater performance, courtesy of the rock-solid A12 chip and a generally fluid OS. I got to use a friend’s Surface Go, and the overall fluidity of the experience was… passable, at best.
  • An extension of the previous point, the Apple Pencil had consistently better latency. The Surface Pen was no slouch and largely matched the Apple Pencil’s quality of experience, but on heavier workloads, such as multilayered Affinity Photo documents, the latter was far less troublesome; nearly no glitches or stroke stutters when compared to the Surface Pen.

After around two months of flip-flopping, I came to the conclusion that as a standalone, strictly tablet + stylus setup, the iPad wins out. I already had a mouse-and-keyboard interface for interfacing with an arguably more “full-fledged” operating system and granular software (solely After Effects) in the form of my laptop; what I realized I wanted to do was to complement that setup, not duplicate it.

And so it was that I took the plunge into getting myself the Wi-Fi-only 2019 model of the iPad Air, with 64GB of internal storage.
This also meant that the cables I had to use to charge my various devices would continue to be an unhealthy mix of lightning, micro-USB and proprietary ones, but hey! I get to charge my phone and my soon-to-be primary work device with the same cable, so that’s a neat little plus.

My next post in this series will be a short one, centered around the accessories that I found myself buying in order to make the iPad work as a primary device over my laptop. Stay tuned!

The iPad Artist, Part 1: A laptop doesn’t always cut it

Until recently, my primary computer was a 14″ Lenovo 720S. It’s a powerful little guy; perhaps not as much as your thick, hefty gaming devices, but capable nonetheless. Portability was a key concern when I was deciding which laptop I should get myself, a little over a year ago, and this notebook ticked nearly all the boxes that I’d borne in mind at the time, with a relatively solid $1000 price tag. I’d still recommend it to anyone looking specifically for a well-built, svelte Windows 10 video machine.

As the year passed, however, the limitations of the laptop – despite its lightweight footprint – became all too apparent.

As context for all the non-artists reading this, a standard laptop-based artstation includes:

  • The laptop (what a twist, eh?)
  • A Wacom tablet of varying sizes
  • A mouse (many grow accustomed to laptop trackpads, though, as a result of wanting to deal with fewer components)
  • Therefore, a chair and a table that can accommodate all of these things.

If you’re with me so far, you probably realise that this rules out being able to (conveniently) work in, say, trains, airplanes, and even beds, among a plethora of other social scenarios.

So with all of that, I decided to follow in the footsteps of several of my friends and colleagues who’ve made the move towards complementing their respective art workflows with iPads and a miscellany of tablets.

The next post will focus on my selection process for what to buy. Stay tuned!

The iPad Artist, Part 0: Prologue

As an illustrator and animator, using an iPad as my primary computer always seemed a challenging proposition. It would entail abandoning two decades of being conditioned to a monitor, a keyboard and a mouse, in addition to nearly half a decade of figuring out the ins and outs of getting used to Wacom tablet workflows.

Now having finally obtained one and completed a couple of illustrations on it, I realise that while specific tutorials and shortcuts are abundant on the internet, resources – specifically directed at artists – detailing how such a transition can be easy or difficult are scant.

I consider myself reasonably tech savvy, but after a couple days of trying to wring out a proper workflow on a platform that I’ve traditionally been accustomed to using for media consumption, I realised that this was easier said than done.

So there lies my reason for assuming that people would be interested in what I have to say here: a series dedicated solely to the ins and outs of a transition from a clamshell laptop to a tablet.

More importantly, all of the content you see here – the words, the pictures, EVERYTHING – will be made on said tablet.

… which is also to say I’ll be making it up as I go.

The first post will be out tomorrow morning. See you soon!