[Feature] macOS native arm64 builds

[eirnym]

What feature would you like to see?

Could you please add macOS M1/M2 native builds?

How will this feature be useful to you and others?

No need to install Rosetta 2 or every time build manually

Request Type

• I can provide a PoC for this feature or am willing to work on it myself and submit a PR

Additional context?

No response

[WerWolv]

Hey

I'd love to add ARM builds in the future however I don't have a Mac to try any of this and GitHub doesn't have any M1 build servers. Therefor we're stuck with what we have right now.
ImHex builds just fine on ARM though so you can compile it yourself if you want to

[eirnym]

Xcode can build universal apps even on x86_64 and since Xcode 12 it's a default behaviour

[WerWolv]

ImHex is built using GCC on macOS, we don't really use Apple's compiler or XCode at all because it's so outdated.

Of course we could still cross compile but figuring out how to do it without having access to any Mac is basically impossible.
I'm very happy to merge pull requests adding support for this though. I just really don't want to do any more macOS debugging through GitHub Actions myself ever again lol

[eirnym]

Xcode uses clang and it's quite fresh. Older Xcode versions use older clang, obviously.

I personally prefer clang over gcc

[eirnym]

BTW, cmake can generate Xcode project.

[WerWolv]

The problem is that Apple uses their own clang version that is not the same as regular clang. And it's always multiple version behind regular clang.
Various features I'm using in ImHex simply aren't supported by AppleClang yet while they are supported by regular Clang or GCC. The reason I chose GCC here is because it makes my life much easier when debugging build issues since all other platforms use GCC as well.

If I had a Mac, I'd probably put in more effort into supporting their toolchain but since I have absolutely no way of debugging using their tools, it's really just frustrating to use.

[eirnym]

Nevertheless, could you please keep this feature request open. I guess somebody will find a solution faster if it'd be open.

[WerWolv]

I created a new pinned issue now with this request amongst other things that I really need help with. #1111

[eirnym]

About clang/debug issue, could you explain it further? In way it's described it's very unclear, what is the problem and how to overcome it if somebody would want to look into.

[WerWolv]

I don't know how to better explain it to be honest.
We were using clang at the start which sometimes caused the build to break when I made changes. Mostly because either features weren't available yet, standard library features were implemented wrongly or differently than on other platforms, etc.
When these things happened, I always had to make a new branch, make small changes to my code, push them to github to build, wait like 20 minutes for it to fail and then continue until I found what was wrong. That was extremely frustrating. Using GCC on all platforms allows me to verify that things are correct on Windows or Linux and can simply expect them to work properly on macOS as well.
Again, no issue if I had a mac but I don't so this is the best I can do realistically. ImHex is using very modern C++20 and C++23 features and I don't want to give up on that.

[iTrooz]

Hey, we've decided to use this issue as the "official" one for discussion about this problem.
So essentially we're going to close any other issue and point at this one instead.

Please comment here if you have ideas to share !
(Please don't just comment to say "plz do it")

[slinderud]

Note: I'm not a developer by any means. And i hardly know what I'm doing. But I got this working on my ARM mac.

Compiled following the guide here: https://github.com/WerWolv/ImHex/blob/master/dist/compiling/macos.md
Only changed this env since it complained:

MACOSX_DEPLOYMENT_TARGET="11" 

The only issues is that signing is much stricter on arm mac, than x86. So the generated .app won't work.
hyperion-project/hyperion.ng#1468

Worked around this by just copying the .app folder directly into /Applications:

cp -r imhex.app /Applications/

Hopefully this information might be a little bit useful.

I haven't actually used it much except checking if it starts

[iTrooz]

Hey ! The problem isn't so much to compile it, it is that neither of us has a M1 Mac to actually compile it.

[WerWolv]

Thanks for the help @slinderud!
The problem we're running into mostly is that we only have x86 macOS build servers available here on GitHub. That means we somehow need to cross-compile ImHex from x86_64 to ARM64. From what I've heard this is not super difficult if you just use Apple's Clang compiler but ImHex requires GCC as AppleClang lacks various features that we're using currently.

As none of us has any Mac, it's really difficult to setup these cross-build processes without tons of trial and error using the GitHub runners. And even if we get it to compile, we have no way of verifying if the produced binary actually runs

[eirnym]

I can help with testing

[imkebe]

I can help since I was a contributor in hyperion-project/hyperion.ng#1468
What I can say is that compilation was without issues, instead building the dmg package has the sign phase.

[iTrooz]

hey ! What we need is a way to build these binaries ourselves, possibly automatically. Do you think you can help with that ?

[imkebe]

The only way that would be possible from me i is to set up docker image that will be fetching code and trigger build jobs in cron like schedule and then push all results somewhere. However that would be limited to linux image.
I don't have server like hardware.

[Nemirtingas]

Hi, I don't know if you can use it for this project, but I made docker images for cross-compiling on Linux for Windows and MacOS (x86, x64, arm64) here: https://hub.docker.com/r/nemirtingas/osxcross_vcpkg
Using a cmake project should be doable.

[WerWolv]

@Nemirtingas Hey, thanks a lot for the suggestion! I tried it out but I can't seem to get vcpkg to build any libraries. The example command from your Docker hub page which installs zlib and libfmt fails with cmake throwing Could not find install_name_tool, please check your installation.. Did I do something wrong?

[Nemirtingas]

I don't know, I did the following thing and it worked:

docker run -it --rm nemirtingas/osxcross_vcpkg:SDK11.3 bash
cat >/vcpkg/triplets/community/x64-osx-mytriplet.cmake <<EOF
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
# You can override linkage type by package if needed
if(PORT STREQUAL "portaudio")
    set(VCPKG_LIBRARY_LINKAGE dynamic)
endif()

set(VCPKG_BUILD_TYPE release)

set(VCPKG_CMAKE_SYSTEM_NAME Darwin)

set(ENV{OSXCROSS_HOST} "x86_64-apple-$ENV{OSXCROSS_TARGET}")

set(VCPKG_CHAINLOAD_TOOLCHAIN_FILE /osxcross/target/toolchain.cmake)

set(ENV{VCPKG_TOOLCHAIN} "/vcpkg/scripts/toolchains/osx.cmake")

set(VCPKG_C_FLAGS "-stdlib=libc++")
set(VCPKG_CXX_FLAGS "-stdlib=libc++")

EOF

vcpkg install --triplet=x64-osx-mytriplet zlib fmt

And it worked 🤔

[WerWolv]

Thanks that indeed worked! I just used arm64-osx-release as the target tripple before to test it which doesn't work apparently

[Nemirtingas]

To build for arm64 macos, I use the following triplet:

set(VCPKG_TARGET_ARCHITECTURE arm64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
set(VCPKG_BUILD_TYPE release)
set(VCPKG_CMAKE_SYSTEM_NAME Darwin)
set(VCPKG_OSX_ARCHITECTURES arm64)
set(ENV{OSXCROSS_HOST} "${VCPKG_OSX_ARCHITECTURES}-apple-$ENV{OSXCROSS_TARGET}")
set(VCPKG_CHAINLOAD_TOOLCHAIN_FILE /osxcross/target/toolchain.cmake)
set(ENV{VCPKG_TOOLCHAIN} "/vcpkg/scripts/toolchains/osx.cmake")
set(VCPKG_C_FLAGS   "-stdlib=libc++ -D_LIBCPP_DISABLE_AVAILABILITY")
set(VCPKG_CXX_FLAGS "-stdlib=libc++ -D_LIBCPP_DISABLE_AVAILABILITY")
set(VCPKG_POLICY_SKIP_ARCHITECTURE_CHECK enabled)

[sambacha]

Building for macOS 14

#!/usr/bin/env bash
CC=$(brew --prefix gcc@12)/bin/gcc-12     \
CXX=$(brew --prefix gcc@12)/bin/g++-12    \
OBJC=$(brew --prefix llvm)/bin/clang      \
OBJCXX=$(brew --prefix llvm)/bin/clang++  \
PKG_CONFIG_PATH="$(brew --prefix openssl)/lib/pkgconfig":"$(brew --prefix)/lib/pkgconfig" \
MACOSX_DEPLOYMENT_TARGET="14"          \
cmake                                     \
  -DCMAKE_BUILD_TYPE=Release              \
  -DCREATE_BUNDLE=ON                      \
  -DCREATE_PACKAGE=ON                     \
  -DCMAKE_C_COMPILER_LAUNCHER=ccache      \
  -DCMAKE_CXX_COMPILER_LAUNCHER=ccache    \
  -DCMAKE_OBJC_COMPILER_LAUNCHER=ccache   \
  -DCMAKE_OBJCXX_COMPILER_LAUNCHER=ccache \
  -DCMAKE_OSX_ARCHITECTURES='arm64'  \
  --fresh \
  ..
gmake -j4 package;

I have also used a different linker, see https://github.com/keith/ld64.lld

Note
Additionally you can read this blog post by the author of an alt. linker, zld - https://eisel.me/lld

Universal Binary

You can build a universal binary using both.

Note
Here is a reference commit for actionlint showing macOS OS Compatibility matrix: https://github.com/rhysd/actionlint/pull/299/files.

Example Workflow

This is a rough example of a github action workflow using both macOS x86 and arm64:

This contains notary as well, which is not necessary but I include it as the build artifact is a .dmg file and not simply some binary executable (not that it makes a difference really).

    release:
        name: ${{ matrix.job.target }} (${{ matrix.job.os }})
        runs-on: ${{ matrix.job.os }}
   #     needs: prepare # this can be a job that creates a changelog, tags the commit and does other pre-release tasks
    env:
      TAG: ${{ github.ref_name }}
      strategy:
          matrix:
              job:
                  # The OS is used for the runner
                  # The platform is a generic platform name
                  - os: ubuntu-20.04
                    platform: linux
                    target: x86_64-unknown-linux-gnu
                    arch: amd64
                    svm_target_platform: linux-amd64
                  - os: ubuntu-20.04
                    platform: linux
                    target: aarch64-unknown-linux-gnu
                    arch: arm64
                    svm_target_platform: linux-aarch64
                  - os: macos-11
                    platform: darwin
                    target: x86_64-apple-darwin
                    arch: amd64
                    svm_target_platform: macosx-amd64
                  - os: macos-13
                    platform: darwin
                    target: aarch64-apple-darwin
                    arch: arm64
                    svm_target_platform: macosx-aarch64

    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Apple Silicon setup
        if: ${{ matrix.job.target == 'aarch64-apple-darwin' }}
        run: |
            echo "SDKROOT=$(xcrun -sdk macosx --show-sdk-path)" >> $GITHUB_ENV
            echo "MACOSX_DEPLOYMENT_TARGET=$(xcrun -sdk macosx --show-sdk-platform-version)" >> $GITHUB_ENV

      # execute cmake build for both x86 and arm64 macOS
      # This can be a script that invokes cmake and make
      - name: Build macOS x86 and arm64
        id: macos-build
        run: bash all_macos.sh
        shell: bash

      # Currently cmake does not create a subdirectory within build with the three-word target name
      - name: Darwin link as Universal
        id: macos-link
        run: lipo -create -output ImHex-macos build/aarch64-apple-darwin/imhex-1.30.1-Darwin.dmg build/x86_64-apple-darwin/imhex-1.30.1-Darwin.dmg
        shell: bash

      # The Rest of this is optional and only needed if you want to notarize the binary
      - name: Create keychain
        run: |
          printf ${{ secrets.APPLE_P12_BASE64 }} | base64 -d > dev.p12
          security create-keychain -p "${{ secrets.APPLE_TEMPKEYCHAIN_PASSWORD }}" "${{ secrets.APPLE_TEMPKEYCHAIN_NAME }}"
          security list-keychains -d user -s "${{ secrets.APPLE_TEMPKEYCHAIN_NAME }}" $(security list-keychains -d user | tr -d '"')
          security set-keychain-settings "${{ secrets.APPLE_TEMPKEYCHAIN_NAME }}"
          security import dev.p12 -k "${{ secrets.APPLE_TEMPKEYCHAIN_NAME }}" -P "${{ secrets.APPLE_P12_PASSWORD }}" -T "/usr/bin/codesign"
          security set-key-partition-list -S apple-tool:,apple: -s -k "${{ secrets.APPLE_TEMPKEYCHAIN_PASSWORD }}" -D "${{ secrets.APPLE_CODESIGN_IDENTITY }}" -t private ${{ secrets.APPLE_TEMPKEYCHAIN_NAME }}
          security default-keychain -d user -s ${{ secrets.APPLE_TEMPKEYCHAIN_NAME }}
          security unlock-keychain -p ${{ secrets.APPLE_TEMPKEYCHAIN_PASSWORD }} ${{ secrets.APPLE_TEMPKEYCHAIN_NAME }}

      - name: Sign the binary
        run: |
          codesign -o runtime --timestamp -s "${{ secrets.APPLE_CODESIGN_IDENTITY }}" -v ImHex-macos
          ditto -c -k ImHex-macos ImHex-macos.zip

      - name: Notarize
        run: |
          xcrun notarytool store-credentials --apple-id [email protected] --password "${{ secrets.APPLE_CRED }}" --team-id "${{ secrets.APPLE_TEAMID }}" altool
          xcrun notarytool submit ImHex-macos.zip --keychain-profile altool --wait

      - name: Rename ImHex binary
        if: startsWith(github.event.ref, 'refs/tags/v') # only on new tag creation
        run: mv ImHex-macos ImHex-macos-$TAG

      - name: Upload artifact to action
        uses: actions/upload-artifact@v3
        if: startsWith(github.event.ref, 'refs/tags/v') # only on new tag creation
        with:
          name: ImHex-macos-${{ env.TAG }}
          path: ImHex-macos-${{ env.TAG }}

[iTrooz]

$ xcrun dwarfdump --uuid _CPack_Packages/Darwin/DragNDrop/imhex-1.30.1-Darwin/imhex.app/Contents/MacOS/imhex UUID: FFB992BC-C9FB-36BE-9CC4-28F465150B2F (arm64) _CPack_Packages/Darwin/DragNDrop/imhex-1.30.1-Darwin/imhex.app/Contents/MacOS/imhex

I don't understand, what does this mean ?

[iTrooz]

Okay, I made some progress, available here: https://github.com/iTrooz/macos-crosscompile

Its not nearly finished tho, and I'm probably going to take a break from it because there are sooo much "small" problems to fix
For now, the biggest issue (so far) is tpoechtrager/osxcross#391, which I fixed by doing this iTrooz@6a2fdc3 (but its by no mean a definitive fix lol)

@Nemirtingas You might be interested in looking at what I did ^^

[Nemirtingas]

Well, I compiled quite some complex stuff with my toolchain and using clang/llvm for MacOS so I'm not interested in GCC

[iTrooz]

Would you have dealt with errors like this, by any chance ? https://cdn.discordapp.com/attachments/789840633414025246/1136801105666396261/image.png

[Nemirtingas]

No but I though you were trying to build for ARM while this instruction is an x86 FPU instruction.
I currently build some of my apps for Apple x86, x64 and arm64.

[iTrooz]

Well, I wanted to make a Dockerfile that worked for both x86 and Arm64, but now that you are saying it, its true that this assembler bug probably only happens in a x86 build, and the main goal is building ARM64

Oops, gotta try that

[mmmorks]

I had to add the following to CMakeLists.txt to work around a known issue with the Xcode 15 linker (https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking):

set(CMAKE_EXE_LINKER_FLAGS "-Wl,-ld_classic")
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,-ld_classic")

The resulting app needed signing, but included an extraneous copy of the imhex executable in the root of the package. So I had to do the following or else execution failed with "Namespace CODESIGNING, Code 2 Invalid Page"

rm imhex.app/imhex
codesign --force --deep --sign - imhex.app

[lucasaf04]

@WerWolv Intel builds require a minimum 12.7 macOS version but Apple Silicon ones require macOS 14.0. This means that M1 users that aren't in latest macOS version can use the Intel build but not the Apple Silicon one.

[WerWolv]

@lucasaf04 Thanks! This might be a remnant from us figuring out how to build the ARM build. I'll see if I can lower the requirement to 12.1 as well

[WerWolv]

@lucasaf04 The latest nightly builds only require 12.1 now.

I'll be closing this issue now since I decided to just bite the bullet and get a MacBook to properly be able to add support for Apple Silicon. If there's any more issues with these builds, please open a new issue.

[verhovsky]

Signing and notarizing would be nice. Currently when I download the app, move it to /Applications and run it I get "“ImHex” cannot be opened because the developer cannot be verified." error:

and have to got to System Settings > Privacy & Security > Security > Open Anyway

Also, please add the M1 build to the website.

[WerWolv]

@verhovsky I have no plans of ever doing that because it's expensive for no reason.
At least on my version of macOS you can just right click -> open the file and it will work

[verhovsky]

When I right click and press open on the app

I get the exact same error on macOS 14.2.1 on M1

[WerWolv]

If I do it, I get this popup instead:

I had to do the rightclick -> open thing twice sometimes for some reason but choosing Open there will launch it and add it as an exception automatically

[verhovsky]

Which macOS version?

[WerWolv]

Same as you. 14.2.1 but on a M2 MacBook Air

[kgantchev]

@WerWolv

I'll be closing this issue now since I decided to just bite the bullet and get a MacBook to properly be able to add support for Apple Silicon. If there's any more issues with these builds, please open a new issue.

Pardon me if I'm intruding here, but if there is a need for M1 or M2 runners for GitHub Actions, may I suggest giving FlyCI a try? We offer MacOS M1 and M2 runners (ARM64). For public repos, we offer 500 mins/month of free M1 usage (4 vCPUs, 7 GB RAM, 28 GB storage).

The setup is super easy:

1. Install the FlyCI GitHub app.
2. Give the FlyCI app permissions to this repo.
3. Change your runs-on flag whenever you implement the ARM64 MacOS workflow:

jobs:
ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m1
      steps:
      - name: 👀 Checkout repo
         uses: actions/checkout@v4

We're still in the public Beta phase and we currently don't have billing so you can use all of our runners for free. Once we enable billing, then contact me if you need more minutes and we might be able to work out something.

Do you think this might be a good option for ImHex?

Best Regards,
Kiril Gantchev
CEO and co-founder of FlyCI

Web: flyci.net | Twitter: flyciapp | LinkedIn: FlyCI | Discord: FlyCI

[iTrooz]

Hey ! For now, we have a cross-compiling system that somewhat works, and we feel we are able to fix the last few issues ourselves, so we probably won't need it for ImHex

That said, this is a really awesome project, and I am really glad that you advertised it to us ! I might use it in other projects in the future, of even ImHex if we can't get the current build process to work properly

Thanks a lot !

[kgantchev]

Thanks, hopefully, you'll find a good application for our runners in the very near future! :)

[grishka]

I get a different error on macOS 13.6.4:

This version of program "ImHex.app" can not be used with this version of macOS.

The problem is that the binary itself specifies a minimum system version:

I tried patching that version in various binaries in the bundle, and did get it to start, but then it still complains about being unable to load the "built-in plugin". I gave up. This feels like it's something that should be easy to fix as part of the build process.

Output when run in terminal

``` [08:24:44] [INFO] [main] Welcome to ImHex 1.32.2! [08:24:44] [INFO] [main] Compiled using commit master@a1edb1b [08:24:44] [INFO] [main] Running on macOS 22.6.0 Darwin Kernel Version 22.6.0: Sun Dec 17 22:12:45 PST 2023; root:xnu-8796.141.3.703.2~2/RELEASE_ARM64_T6000 (arm64) [08:24:44] [INFO] [main] Native scaling set to: 1.0 [08:24:44] [INFO] [main] Using 'Apple' GPU [08:24:44] [INFO] [main] Task 'Setting up environment' finished successfully in 0 ms [08:24:44] [INFO] [main] Task 'Creating directories' finished successfully in 0 ms [08:24:44] [INFO] [main] Task 'Loading settings' finished successfully in 0 ms [08:24:44] [INFO] [libimhex] Loading plugin 'ui.hexpluglib' [08:24:44] [ERROR] [libimhex] Loading plugin 'ui.hexpluglib' failed: dlopen(/Applications/ImHex.app/Contents/MacOS/plugins/ui.hexpluglib, 0x0001): Library not loaded: @rpath/libimhex.1.32.2.dylib Referenced from: <1566674B-830D-388A-8C48-FEBBF40E9BE3> /Applications/ImHex.app/Contents/MacOS/plugins/ui.hexpluglib Reason: tried: '/vcpkg/installed/arm-osx-mytriplet/lib/libimhex.1.32.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/vcpkg/installed/arm-osx-mytriplet/lib/libimhex.1.32.2.dylib' (no such file), '/osxcross/target/macports/pkgs/vcpkg/installed/arm-osx-mytriplet/lib/libimhex.1.32.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/osxcross/target/macports/pkgs/vcpkg/installed/arm-osx-mytriplet/lib/libimhex.1.32.2.dylib' (no such file), '/osxcross/target/macports/pkgs/vcpkg/installed/arm-osx-mytriplet/lib/pkgconfig/../../lib/libimhex.1.32.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/osxcross/target/macports/pkgs/vcpkg/installed/arm-osx-mytriplet/lib/pkgconfig/../../lib/libimhex.1.32.2.dylib' (no such file), '/mnt/ImHex/build/lib/libimhex/libimhex.1.32.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/mnt/ImHex/build/lib/libimhex/libimhex.1.32.2.dylib' (no such file), '/vcpkg/installed/arm-osx-mytriplet/lib/libimhex.1.32.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/vcpkg/installed/arm-osx-mytriplet/lib/libimhex.1.32.2.dylib' (no such file), '/osxcross/target/macports/pkgs/vcpkg/installed/arm-osx-mytriplet/lib/libimhex.1.32.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/osxcross/target/macports/pkgs/vcpkg/installed/arm-osx-mytriplet/lib/libimhex.1.32.2.dylib' (no such file), '/osxcross/target/macports/pkgs/vcpkg/installed/arm-osx-mytriplet/lib/pkgconfig/../../lib/libimhex.1.32.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/osxcross/target/macports/pkgs/vcpkg/installed/arm-osx-mytriplet/lib/pkgconfig/../../lib/libimhex.1.32.2.dylib' (no such file), '/mnt/ImHex/build/lib/libimhex/libimhex.1.32.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/mnt/ImHex/build/lib/libimhex/libimhex.1.32.2.dylib' (no such file)! [08:24:44] [INFO] [libimhex] Loading plugin 'builtin.hexplug' [08:24:44] [INFO] [ui] Library plugin 'ui' initialized successfully [08:24:44] [INFO] [libimhex] Loading plugin 'disassembler.hexplug' [08:24:44] [INFO] [libimhex] Loading plugin 'decompress.hexplug' [08:24:44] [INFO] [libimhex] Loading plugin 'hashes.hexplug' [08:24:44] [INFO] [libimhex] Loading plugin 'visualizers.hexplug' [08:24:44] [INFO] [libimhex] Loading plugin 'yara_rules.hexplug' [08:24:44] [INFO] [libimhex] Loading plugin 'script_loader.hexplug' [08:24:44] [INFO] [libimhex] Layout unlocked [08:24:44] [ERROR] [libimhex] Plugin 'builtin.hexplug' threw an exception on init: [json.exception.type_error.302] type must be string, but is number [08:24:44] [ERROR] [main] Failed to initialize plugin builtin.hexplug [08:24:44] [INFO] [libimhex] Plugin 'disassembler.hexplug' initialized successfully [08:24:44] [INFO] [libimhex] Plugin 'decompress.hexplug' initialized successfully [08:24:44] [INFO] [libimhex] Plugin 'hashes.hexplug' initialized successfully [08:24:44] [INFO] [libimhex] Plugin 'visualizers.hexplug' initialized successfully [08:24:44] [INFO] [libimhex] Plugin 'yara_rules.hexplug' initialized successfully [08:24:44] [INFO] [libimhex] Plugin 'script_loader.hexplug' initialized successfully [08:24:44] [ERROR] [main] Built-in plugin not found! [08:24:44] [WARN] [main] Task 'Loading plugins' finished unsuccessfully in 35 ms [08:24:44] [INFO] [main] Task 'Configuring UI scale' finished successfully in 0 ms [08:24:44] [INFO] [main] Task 'Checking for updates' finished successfully in 0 ms [08:24:44] [INFO] [main] Task 'Loading fonts' finished successfully in 240 ms [08:24:44] [INFO] [main] ImHex fully started in 351ms [08:24:44] [WARN] [main] All tasks finished, but some failed [08:25:24] [INFO] [main] Exit task 'Saving settings' finished successfully [08:25:24] [INFO] [main] Exit task 'Cleaning up shared data' finished successfully [08:25:24] [INFO] [main] Exit task 'Unloading plugins' finished successfully [08:25:24] [INFO] [main] Exit task 'Deleting old files' finished successfully ```

edit: it turns out there's a vtool command that comes with xcode that can add, change or remove those version requirement sections from mach-o files

[WerWolv]

macOS DMG x86_64.zip

Could y'all please try this build here? At least on my M2 it works fine.

[WerWolv]

On the latest nightly build it should really all be working now. Both the x86 and ARM version runs for me and only requires at macOS 12.1. Let's hope it stays at that.

For anybody who got here because they had issues, download the nightly from https://imhex.download/#nightly or from https://imhex.werwolv.net and the issue should be gone. Also 1.33.0 or higher will have the issue fixed.