It has been a whole year since the last time we gracefully played Minecraft on M1 MacBook. Most of the old friends have moved on to their jobs, and the Minecraft server, even if it’s still running, has been deserted.
I thought this weekend would be like any other summer weekend, filled with heat and restlessness. However, I received a message from a friend asking if there were any modpacks for Minecraft available.
After rummaging through my stuff, I found last year’s directory, where all the files were still intact, but I had completely forgotten how to open them — Running Minecraft natively on M1 has always been a headache.
Let me explore this again.
# Same Old, Same Old
“The only constant is change.” Hello Minecraft! Launcher (HMCL) now supports calling custom library files, LWJGL 3.3.0 onwards comes with macOS-ARM64 native components, and ManyMC launcher streamlines the process of replacing library files.
At first glance, everything seems to be progressing smoothly. However, appearances can be deceiving. Despite the advancements, Minecraft has not considered supporting macOS-ARM for versions before 1.19. To run Minecraft natively, you still need to take matters into your own hands and manage LWJGL native libraries.
# Self-Reliance
As a wise person once said, “True happiness comes from self-reliance.” Thanks to yaoxi-std, there’s already a solution to support calling dynamic library files in HMCL, but using JAR library files seems tricky. Manually copying files each time is not practical, as forgetting to turn off the “Check Game Files” option might undo all previous efforts.
Inspired by yusefnapora’s MultiMC auto script, I realized that HMCL’s Wrapper Command feature can modify JVM parameters on startup based on the version and load the appropriate native library files.
Here we go.
# M1 HMCL Hack
If M1 MultiMC Hack has stood the test of time, why should HMCL not have its own M1 HMCL Hack? Is it lacking in reputation? Today, I’m breaking this curse with the debut of M1 HMCL Hack.
Seems like a rhyme.
The Wrapper Command automatically detects the Minecraft version and replaces the library file path in the existing JVM startup parameters with the correct native library file path. It’s user-friendly and as good as it gets.
Friendly reminder: Even though we’re named M1 HMCL Hack, theoretically, it should also be compatible with M2.
# Installation and Usage
# Step 1: Download Java and HMCL
First, head over to the Azul official website to download Zulu JDK. You can choose the .dmg installation package for direct installation. Select the ARM 64-bit architecture, and since HMCL requires OpenJFX, choose the JDK-FX package type. Choose a Java version based on the Minecraft version. Through my testing, the compatibility between Minecraft and Java is roughly as follows:
| Minecraft | Java | LWJGL |
|---|---|---|
| 1.19 | >= 17 | 3.3.1 |
| 1.18 | >= 17 | 3.3.1 |
| 1.17 | >= 17 | 3.2.3 |
| 1.16 | >= 8 | 3.3.1 |
| 1.12 | >= 8, <= 11 | 2.9.4 |
| 1.10 | 8 | 2.9.4 |
| 1.7 | 8 | 2.9.4 |
Different JDK versions can coexist peacefully, as long as we all share one goal.
Next, download HMCL, with the latest version at the time of writing being 3.5.3.211.
# Step 2: Clone the Repository
Clone the M1 HMCL Hack repository to your local machine.
git clone https://github.com/DotIN13/m1-hmcl-hack.git
# Step 3: Configure the Wrapper Command
Open HMCL, download or import a Minecraft instance.
Navigate to the instance settings and check “Enable per-instance settings”.
Refer to the table above to choose the appropriate “Java path” in the advanced settings, ensuring you select the ARM architecture Java version installed in the first step.
Scroll down to the Wrapper Command in the advanced settings and enter /usr/bin/ruby /path/to/index.rb, with /path/to/index.rb being the local path to the index.rb file. Since HMCL switches the current directory to .minecraft when starting the game, if using a relative path, start from .minecraft.
Lastly, since HMCL defaults to not launching Minecraft using ARM architecture Java on ARM-based macOS, you need to check “No JVM compatibility checks” at the bottom of the page.
After these steps, clicking play will launch Minecraft in a No-setta (No-rosetta) state. For any new Minecraft installations, just repeat step three to continue enjoying a seamless experience.
# Enthusiasts’ Development and Governance
You might wonder why I created the HMCL Hack, and my answer might be to provide a smoother Minecraft experience to more Apple Silicon users who enjoy HMCL. But do we really need all this? Or is it necessary in the grand scheme of things?
Microsoft should lead the way in solving Minecraft compatibility issues. GLFW should consider backward compatibility in minor version updates. LWJGL should re-release old versions to support ARM architecture rather than addressing it through major version updates, preventing all applications using older libraries from running on macOS ARM-64bit.
For a special game like Minecraft, each version, old or new, has a large player base, making backward compatibility crucial. However, to date, the entire ecosystem has only addressed compatibility issues with the latest version and overlooked the older versions.
Reality and desire are like a sea apart, the ideal home remains unknown. The essence of open source is enthusiasts sharing, akin to a covenant between the owners, masters, and users of computer software, entrusting users with the rights to use and modify. However, unlike a typical social contract, users lack the power to overthrow the “rulers.” While open source signifies openness, code maintainers retain full authority. Although users can modify the software they use, they cannot make a substantial impact on software used by others. The lack of credibility and sharing channels leads to users’ modifications ending up as mere self-indulgence. It’s like users are jesters in a coin-making game, while the control over the currency system remains in the hands of certain “enthusiasts.”
Open source is not a fully decentralized process; it simply shifts control from evil corporations to another group of people. If these developers’ and users’ ideas clash, users with no alternative are left with no choice but to comply.
Words alone may not achieve much, but is open source just “the tyranny of the minority” disguised as a lamb?