Add macOS arm64 build

[rakleed]

Closes #257

I checked the compiled build for arm64, and it works correctly.

Here's how Claude Code explained why these changes will be enough:

Details

Dependency analysis and fixes

Dependencies without ARM64 wheels on macOS:

Package	Status	Resolution
imgui==2.0.0	❌ x86_64 only	pip automatically builds from source (sdist contains pre-generated C files, Cython not required)
zipfile-deflate64-macos==0.1.0	⚠️ universal2 for cp39 only	pip builds from source on Python 3.12 (same as on Intel)

All other dependencies (zstd, bencode2, pillow-avif-plugin, lxml, cx-Freeze, etc.) already have native ARM64 or universal2 wheels.

Changes made to .github/workflows/build.yml:

1. Added new runner macos-15 (Apple Silicon / ARM64) to the build matrix
2. Added artifact field to each matrix entry for unique artifact names: Windows, Linux, macOS, macOS-ARM64 — replacing the previous runner.os which produced the same name macOS for both macOS builds

Why this works:

On the ARM64 runner (macos-15), pip won't find compatible wheels for imgui==2.0.0 (x86_64 only) and will automatically fall back to building from sdist. The sdist already contains pre-generated C files, and Xcode Command Line Tools (pre-installed on GitHub runners) will compile them into a native ARM64 binary.

[cantunborn]

This is working. Tested on my fork. Also improves launch time significantly.

[rakleed]

@WillyJL could you please review PR?

[cantunborn]

For anyone that finds this, I have added quite a lot of macOS-specific fixes and optimizations for myself on my fork here: https://github.com/cantunborn/F95Checker.

You can download and try the arm64 version (courtesy @rakleed for their work on the build for arm64 in this PR) for Apple Silicon macs from the Actions section, see if it works for you. Works much better for me in terms of resource usage, compatibility and general smoothness.

[rakleed]

@cantunborn could you please open PRs in this repo with your changes?

[WillyJL]

i was gonna check over them manually and merge what i think makes sense to have upstream, in a few minutes

[WillyJL]

@cantunborn regarding your fork:

• changes from this PR here are merged
• changes from Fix macOS .app bundle support for game launch #259 are merged
• other changes to github build workflow seem superfluous to me, dont see why you would need to specifically build for just one platform
• super+w seems like user preference. also, usually the keybind is ctrl+w to close a tab. apps typically dont bind to super (windows key), but idk if macos invers ctrl and super. anyway, i dont think this keybind fits
• changes to default scroll amount and smoothing seem unjustified and just personal preference. if the issue is scaling on macos causing too much/little scrolling, thats an issue to address, not to change the default value
• _build_mdi_range() is superfluous, the mdi font uses basically all characters in that range, the resulting range is almost exactly the same as including all characters in the full range, its 7430 with your solution vs 7446 with full range. youre doing a lot of expensive computation for basically no reason
• ill double check the changes to the noto sans font range, those might make sense
• render_when_unfocused change kinda makes sense. it seems like on linux wayland too, self.focused is always true. and anyway, the app should not constantly render while focused if theres nothing happening. i think this check for drawing should be removed entirely, this setting doesnt make much sense anymore
• draw_next of either 0.5 or 0.2 i think is a bit excessively small, ill keep it as is at 1s
• glfw.wait_events_timeout() makes a lot of sense, not sure how i missed that
• changes related to the tray icon dont make sense to me, what do they accomplish?
• and what about the qt.conf patch, any more explanation of what it actually fixes user-facing side?

[cantunborn]

other changes to github build workflow seem superfluous to me, dont see why you would need to specifically build for just one platform

That's just something I did to simplify builds for myself. I only needed macos-arm64.

super+w seems like user preference. also, usually the keybind is ctrl+w to close a tab. apps typically dont bind to super (windows key), but idk if macos invers ctrl and super. anyway, i dont think this keybind fits

I added Cmd+W because it's the standard way of closing windows on macOS.

changes to default scroll amount and smoothing seem unjustified and just personal preference. if the issue is scaling on macos causing too much/little scrolling, thats an issue to address, not to change the default value

Issue to address. It scrolls way too fast by default. I just picked the default settings that work best for me on macOS. The current values on my fork have the most native macOS scroll feel, so I kept those changes. If you want to can test and keep only for macOS builds.

_build_mdi_range() is superfluous, the mdi font uses basically all characters in that range, the resulting range is almost exactly the same as including all characters in the full range, its 7430 with your solution vs 7446 with full range. youre doing a lot of expensive computation for basically no reason

ill double check the changes to the noto sans font range, those might make sense

I just did a launch time analysis using Claude, and added the changes that minimized it. I assumed you might have stopped development on your repo so I figured out whatever changes I could do to help. The launch time is way too high (at least on macOS) for the current code state.

render_when_unfocused change, draw_next of either 0.5 or 0.2 and glfw.wait_events_timeout(): again, just did an analysis with Claude, I'm not fully knowledgeable on the code. It has worked well for my purposes, for the past months since the change. Idle + active both have much lesser resource usage with no noticeable change in behavior for me. Resource usage is a genuine issue with the whole software rn. Your call on how it can be fixed since you're the dev and know the codebase better than me.

changes related to the tray icon dont make sense to me, what do they accomplish?

Currently on macOS, the menu bar icon context menu is inert/disabled. Can't click anything. Claude came up with the root cause as something openGL related, so I added those and now even tho it doesn't look like native macOS it opens properly and all buttons work.

and what about the qt.conf patch, any more explanation of what it actually fixes user-facing side?

I added this to fix rendering in integrated browser. With current code if I try to open any download links, it just opened f95zone login page link and rendered as blank. After that fix everything renders properly and links redirect to selected default browser after login. I think it's described in this issue: #181

[WillyJL]

I added Cmd+W because it's the standard way of closing windows on macOS.

will add it as a keybind only on macos then, makes sense.

Issue to address. It scrolls way too fast by default. I just picked the default settings that work best for me on macOS. The current values on my fork have the most native macOS scroll feel, so I kept those changes. If you want to can test and keep only for macOS builds.

i feel like this is likely related to dpi. it should take dpi into account when applying the scroll multiplier to the actual scroll event. related to #24 and #203, will check that code again.

The launch time is way too high (at least on macOS) for the current code state.

how many games do you have?

Resource usage is a genuine issue with the whole software rn. Your call on how it can be fixed since you're the dev and know the codebase better than me.

this in general isnt really fixable. python is just slow. to fix this it needs to be ported to a more performant language, which i was doing rewriting in C, but takes a long time and its on pause for now. i hope to get back to it eventually.

Currently on macOS, the menu bar icon context menu is inert/disabled. Can't click anything. Claude came up with the root cause as something openGL related, so I added those and now even tho it doesn't look like native macOS it opens properly and all buttons work.

makes sense, though there are no opengl related changes. theres just these really:

I added this to fix rendering in integrated browser. With current code if I try to open any download links, it just opened f95zone login page link and rendered as blank. After that fix everything renders properly and links redirect to selected default browser after login. I think it's described in this issue: #181

i see. gonna merge those then. thanks!

[cantunborn]

I made some PRs for the independent changes, you can look at those.

how many games do you have?

I have 52. I don't know if that's much. Your 11.1 release loads fine as well, the intel release though was horrible. But the changes on my fork do add noticeable speed, probably about 1s or more.

i feel like this is likely related to dpi. it should take dpi into account when applying the scroll multiplier to the actual scroll event. related to #24 and #203, will check that code again.

Yeah, it was really weird which is why I made changes for myself. If it's possible for you to add defaults per OS, or like check for macOS yourself I would encourage you to. I just disabled the custom smooth scroll and tweaked multiplier to get close to macOS native scrolling, since it's quite good on its own . People on macOS probably won't go around changing scroll for that reason.

this in general isnt really fixable. python is just slow. to fix this it needs to be ported to a more performant language, which i was doing rewriting in C, but takes a long time and its on pause for now. i hope to get back to it eventually.

I don't know why, but after the changes in my fork, the usage stays relatively normal. So if it's to your standards you can add those until you finish your rewrite.

makes sense, though there are no opengl related changes.

I forgot what it was, QT I guess. It would be great if you could get the macOS native one to work somehow, but functinally these changes do work.

[WillyJL]

I have 52. I don't know if that's much. Your 11.1 release loads fine as well, the intel release though was horrible. But the changes on my fork do add noticeable speed, probably about 1s or more.

so im guessing it was mostly an emulation issue. additional speed might be to smaller character set for noto sans if i had to guess. and no, 52 is actually very little. i ask because with more games it has to check more files on disk for images and executables, so it takes longer to open due to that. with 52 games it should be basically the same as with no games, so its basically just the time the app itself takes to load. theres people with 8000 games lol

Yeah, it was really weird which is why I made changes for myself. If it's possible for you to add defaults per OS, or like check for macOS yourself I would encourage you to. I just disabled the custom smooth scroll and tweaked multiplier to get close to macOS native scrolling, since it's quite good on its own . People on macOS probably won't go around changing scroll for that reason.

what im thinking of doing for the scrolling is keeping 1.0 as default, but for example dividing that by the dpi at runtime, rather than changing the default value. anyway, i will do some tests.

I don't know why, but after the changes in my fork, the usage stays relatively normal. So if it's to your standards you can add those until you finish your rewrite.

thats probably mostly from removing self.focused from draw logic. currently, it was always drawing while focused. that i agree is a bad idea, and its good to remove. what i meant is that going from 1s to 0.5s draw_next shouldnt make much of a difference and id rather be cautious, and that to get it even lower usage (while already removing self.focused from draw) it would need rewriting.

I forgot what it was, QT I guess. It would be great if you could get the macOS native one to work somehow, but functinally these changes do work.

yes im also planning to remove the custom qt styles forthe tray menu on macos, so hopefully it will look native