Hi @asmod3us, this is a good question and one I've been thinking about, as I can't wait to get my hands on an M1 Mac. However, this probably is not coming terribly soon, as there are some significant issues I need to overcome. The main problem is that Brave is not released as a "universal" app, meaning they are releasing two separate versions, one for Intel and one for M1. That would mean I'd either need to include both in Epichrome, which would nearly double the size of the package and require me to figure out how to auto-sense which architecture it's being run on, or I'd need to branch and release two separate versions with each release, which is its own logistical problem, as my auto-update code would need to be completely rewritten to handle that.

So the short answer is, I haven't figured out how to do it elegantly yet. Once I've released 2.4.0, it's on my list to grapple with, but it may be several months. Sorry for that delay. I've heard good things about the Rosetta 2 translation, so I hope that will suffice for you lucky M1 users for now...

The browsers really benefit from native support compared to Rosetta, I'll support work on this best as I can. I have access to an M1 Mac and I'm happy to provide feedback.

Would using the Chrome engine make it easier to offer initial support? The binary available at https://www.google.com/chrome/ for M1 Macs is actually a universal binary:

❯ file Google\ Chrome.app/Contents/MacOS/Google\ Chrome
Google Chrome.app/Contents/MacOS/Google Chrome: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
Google Chrome.app/Contents/MacOS/Google Chrome (for architecture x86_64):	Mach-O 64-bit executable x86_64
Google Chrome.app/Contents/MacOS/Google Chrome (for architecture arm64):	Mach-O 64-bit executable arm64

Hi @asmod3us,

Thank you for the tip! I never even downloaded the ARM version of Brave as I just assumed it would be ARM-only. After your comment, I tried it, and it too is universal. I was worried it would have other differences that would cause headaches in incorporating it, but it appears to work just fine. But of course, I only have an Intel system to test it on.

Anyway, I'm about to release 2.3.27 with the universal Brave engine, but wanted to post it here first so just in case it doesn't work well on your M1 Mac I can pull it until we can figure it out. Would you please give it a try and let me know how it goes? Thanks!

Here's the link:

https://www.dropbox.com/s/hgnl6i46ima9b3l/epichrome-2.3.27.pkg?dl=1

Hi @dmarmor,

Thank you for the tip! I never even downloaded the ARM version of Brave as I just assumed it would be ARM-only. After your comment, I tried it, and it too is universal. I was worried it would have other differences that would cause headaches in incorporating it, but it appears to work just fine. But of course, I only have an Intel system to test it on.

Oh that's great, I had no idea about Brave being universal too!

Anyway, I'm about to release 2.3.27 with the universal Brave engine, but wanted to post it here first so just in case it doesn't work well on your M1 Mac I can pull it until we can figure it out. Would you please give it a try and let me know how it goes? Thanks!

Thank you, I took it for a test ride, so far I have mixed results:

• I updated an older Brave app created with Epichrome 2.3.25 and it's still running with Intel Brave engine
• I created a new Brave App 'Foo' and on first launch there are processes called 'Foo' running as Intel as well as ARM64. The Brave engine is ARM. When I quit and re-open the app the Brave engine runs as Intel and it stays that way.

LMK what logs and other details I can provide.

That's very puzzling. I'm not sure what logs would be helpful for me. Having no experience with running on an M1, I don't even know how you determine which architecture a process is running. Is that something that the ps command shows you? If you could send me the output of that showing your test app running both correctly and then incorrectly, that might be helpful. At least I could see which processes are using the right architecture the first time.

The real problem is that I have no idea if I can do anything to change what you're seeing. Most of Epichrome is based on shell scripts, which don't have any architecture, so I don't understand how non-browser processes can be running as Intel. I'll try to do some research and see if there's anything I can do to try to hint that the entire Epichrome system should be considered universal...

I'm going to go ahead and release 2.3.27, as it appears to at least run as well as the previous Intel versions for you.

Meantime, we can keep working on this. The only other compiled code I have in an app is the small launch app, which is Intel-only. I've just built my own custom universal build of Platypus, which is what I use for the launch app. I'll make a beta using that and post it here for you to try. I'm not super hopeful it'll help, but it's the only idea I have at present. Hopefully tomorrow sometime...

That's very puzzling. I'm not sure what logs would be helpful for me. Having no experience with running on an M1, I don't even know how you determine which architecture a process is running. Is that something that the ps command shows you? If you could send me the output of that showing your test app running both correctly and then incorrectly, that might be helpful. At least I could see which processes are using the right architecture the first time.

Indeed. Activity Monitor shows the architecture of running apps:

On the shell, I think ps shows a flag for the process. Apple Docs suggests it's the proc_translated flag, which I think is P_TRANSLATED in sys/proc.h. ps -eww -o flags,pid,args shows both P_TRANSLATED and P_CLASSIC, i.e. a 3 for the Rosetta processes I checked. E.g. Bartender:

❯ ps -eww -o flags,pid,args|grep Bartender
    4004  8721 /Users/asmodeus/Applications/Bartender 4.app/Contents/MacOS/Bartender 4

has 4004 as flags, 'Evernote Helper' (still Intel...):

❯ ps -eww -o flags,pid,args|grep 'Evernote Helper'
   34004  8646 /Users/asmodeus/Applications/Evernote.app/Contents/Frameworks/Evernote Helper (GPU).app/Contents/MacOS/Evernote Helper (GPU) --type=gpu-process --field-trial- ...

is 34004.

A snippet from https://cutecoder.org/software/detecting-apple-silicon-shell-script/ allows to detect the architecture as as well as emulation:

#!/bin/zsh
 
arch_name="$(uname -m)"
 
if [ "${arch_name}" = "x86_64" ]; then
    if [ "$(sysctl -in sysctl.proc_translated)" = "1" ]; then
        echo "Running on Rosetta 2"
    else
        echo "Running on native Intel"
    fi 
elif [ "${arch_name}" = "arm64" ]; then
    echo "Running on ARM"
else
    echo "Unknown architecture: ${arch_name}"
fi

The real problem is that I have no idea if I can do anything to change what you're seeing. Most of Epichrome is based on shell scripts, which don't have any architecture, so I don't understand how non-browser processes can be running as Intel. I'll try to do some research and see if there's anything I can do to try to hint that the entire Epichrome system should be considered universal...

I looked into the Epichrome package and the binaries in Engine are still Intel binaries. Could that be the reason?

Here are a couple of screenshots from Activity Monitor:

1. Launching a newly created app 'Bar' for the first time. Bartender snuck into the picture ;-)
   

2. A second process becomes active shortly after. We are still on the first launch:
   

3. The Intel process disappears after a bit:
   

4. On second launch of the app, there is only an Intel process:
   

Hope this helps! I'll gladly try the beta with the Platypus universal binary.

This is very helpful to see! Yes, the behavior of Bar (on first run anyway) is what I'd have expected. That first instance is the Platypus launch app, which has been Intel-only. The second one should be the Brave engine, running native. What I don't understand is why it then runs Intel on subsequent runs. I'm hoping that maybe if the launch app is native too, that will help, but we'll see.

To that end, here's a 2.3.28 beta with the universal Platypus binary. Could you give it a try and see if it helps at all? Thank you!

https://www.dropbox.com/s/tpofl88447otoqw/epichrome-2.3.28b1.pkg?dl=1

This is very helpful to see! Yes, the behavior of Bar (on first run anyway) is what I'd have expected. That first instance is the Platypus launch app, which has been Intel-only. The second one should be the Brave engine, running native. What I don't understand is why it then runs Intel on subsequent runs. I'm hoping that maybe if the launch app is native too, that will help, but we'll see.

To that end, here's a 2.3.28 beta with the universal Platypus binary. Could you give it a try and see if it helps at all? Thank you!

I'm glad it helps! With the beta I notice once difference: a newly created app now launches with two Apple Silicon processes on first launch:

From the second launch it reports as an Intel binaries again:

The created app is now identified as a universal binary in Finder, this has changed from 2.3.27:

This is so confusing to me. I can't understand why it would work correctly on the first run, and then fail on subsequent runs. I've scanned an app bundle and now can't find any code in there that's not universal.

I'm assuming Baz launches and runs correctly on both the first and subsequent runs? My only working theory is that somehow the native code isn't running properly, so then the system falls back to the Intel code on the next run. But I figured you'd see some evidence of that somewhere.

For now, I'm out of ideas, unfortunately. I'll keep poking around the internet to see if I can find anything out, but without my own M1 device to experiment on, I'm not sure what else I can try now...

I agree, it's very confusing. I reattempted this with only the Epichrome beta installed version but got the same result.

If I delete the engine from /Applications/Epichrome/EpichromeEngines.noindex/USER/Snafu after I created the app and then re-launch, it starts as an Intel binary right away. The logs where it puts the engine back in place:

❯ ./Epichrome
 [47866]Snafu(1554): Core 2.3.28b1 initialized in app Snafu.
 [47866]Snafu(268)/lockset(182)/writevars(1366): Writing to lock: lockPID='47866'
 [47866]Snafu(268)/lockset(182)/writevars(1366): Writing to lock: lockLogFile='/Users/asmodeus/Library/Application Support/Epichrome/Apps/Snafu/Logs/epichrome_app_log_20210308_092115.txt'
 [47866]Snafu(268)/lockset(182)/writevars(1366): Writing to lock: lockCmd='/bin/bash /Users/asmodeus/Applications/Snafu.app/Contents/Resources/script'
 [47866]Snafu(268)/lockset(182)/writevars(1366): Writing to lock: lockEnginePID=''
 [47866]Snafu(268)/lockset(182)/writevars(1366): Writing to lock: lockEngineCmd=''
 [47866]Snafu(268)/lockset(182)/writevars(1366): Writing to lock: lockEnginePath=''
 [47866]Snafu(268)/lockset(187): Lock set.
 [47866]Snafu(314)/readconfig(2608): SSBAppPath='/Users/asmodeus/Applications/Snafu.app'
 [47866]Snafu(314)/readconfig(2608): SSBLastRunVersion='2.3.28b1'
 [47866]Snafu(314)/readconfig(2608): SSBLastRunEngineType='internal|com.brave.Browser'
 [47866]Snafu(314)/readconfig(2608): SSBUpdateVersion='2.3.28b1'
 [47866]Snafu(314)/readconfig(2608): SSBUpdateCheckDate='1615795526'
 [47866]Snafu(314)/readconfig(2608): SSBUpdateCheckVersion='2.3.28b1'
 [47866]Snafu(314)/readconfig(2608): SSBUpdateCheckError=''
 [47866]Snafu(314)/readconfig(2608): SSBEnginePath='/Applications/Epichrome/EpichromeEngines.noindex/asmodeus/Snafu'
 [47866]Snafu(314)/readconfig(2608): SSBEngineAppName='Snafu.app'
 [47866]Snafu(314)/readconfig(2608): SSBNMHInstallError=''
 [47866]Snafu(319): Overriding SSBEngineSourceInfo from config.sh with built-in value.
 [47866]Snafu(401)/getepichromeinfo(288): Found Epichrome 2.3.28b1 at '/Applications/Epichrome/Epichrome Beta.app'.
 [47866]Snafu(401)/getepichromeinfo(317): Current version of Epichrome (2.3.28b1) found at '/Applications/Epichrome/Epichrome Beta.app'
 [47866]Snafu(443): Setting engine path to '/Applications/Epichrome/EpichromeEngines.noindex/asmodeus/Snafu'
 [47866]Snafu(629)/checkengine(1921): Engine is in an unknown state.
 [47866]Snafu(636): Replacing damaged engine.
 [47866]Snafu(665)/createengine(2085): Creating internal Brave engine at '/Applications/Epichrome/EpichromeEngines.noindex/asmodeus/Snafu'.
 [47866]Snafu(673)/setenginestate(2000): Engine activated.
 [47866]Snafu(680)/updateenginemanifest(2301): Writing new engine manifest.
 [47866]Snafu(725)/launchapp(2738): Launching app engine.
 [47866]Snafu(756)/waitforcondition(999)/checkforengine(752)/getengineinfo(2567): Found running engine '/Applications/Epichrome/EpichromeEngines.noindex/asmodeus/Snafu/Snafu.app' with PID 48146.
 [47866]Snafu(762)/launchhelper(2830)/waitforcondition(1002): Waiting for Epichrome helper to launch...
 [47866]Snafu(771): Leaving lock in place for Epichrome Helper.
 [47866]Snafu(787)/writeconfig(2687): Configuration variables have not changed. No need to update.

I understand it's not ideal, but I am happy to poke around further if you can provide some directions :)

I've been poking around to see what I might be able to do. Have you looked at the Get Info window for both the launch app (the one you created) and the engine app (the one in EpichromeEngines.noindex)? Do they show an option to run under Rosetta or native? I can't see this option on my system, but of course I'm on Intel. If you see that, does changing it to turn of Rosetta for those apps help?

It wouldn't be ideal to have to do that for every app, but if that option is at least there it might point me toward a solution I could try. Thanks!

I've been poking around to see what I might be able to do. Have you looked at the Get Info window for both the launch app (the one you created) and the engine app (the one in EpichromeEngines.noindex)? Do they show an option to run under Rosetta or native? I can't see this option on my system, but of course I'm on Intel. If you see that, does changing it to turn of Rosetta for those apps help?

It wouldn't be ideal to have to do that for every app, but if that option is at least there it might point me toward a solution I could try. Thanks!

That's a great question! I first checked the app itself, and it has the Open using Rosetta box unchecked:

The app in EpichromeEngines.noindex does not have that option in 'Get Info':

All the other apps in EpichromeEngines.noindex also have it unchecked. All binaries in there seem to be universal or shell script:

❯ gfind -type f -executable -exec file {} \; |grep -v 'for architecture '
./TestFoo.app/Contents/MacOS/Brave Browser: Bourne-Again shell script text executable, ASCII text
./Payload/MacOS/Brave Browser: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Resources/install.sh: Bourne-Again shell script text executable, ASCII text
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Libraries/libEGL.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Libraries/libswiftshader_libEGL.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Libraries/libvk_swiftshader.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Libraries/libbrave_rust.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Libraries/libGLESv2.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Libraries/libswiftshader_libGLESv2.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/XPCServices/AlertNotificationService.xpc/Contents/MacOS/AlertNotificationService: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Helpers/Brave Browser Helper.app/Contents/MacOS/Brave Browser Helper: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Helpers/chrome_crashpad_handler: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Helpers/Brave Browser Helper (GPU).app/Contents/MacOS/Brave Browser Helper (GPU): Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Helpers/app_mode_loader: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Helpers/Brave Browser Helper (Plugin).app/Contents/MacOS/Brave Browser Helper (Plugin): Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Helpers/Brave Browser Helper (Renderer).app/Contents/MacOS/Brave Browser Helper (Renderer): Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
./Payload/Frameworks/Brave Browser Framework.framework/Versions/89.1.21.73/Brave Browser Framework: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]

I forgot to mention that the flag does not change during or after the first launch.

OK, that's useful to know. I'm going to post a new beta for you in a little bit. Menatime, I forgot to ask: have you tried to create any Chrome-based apps? If not, could you try one? I'd like to know if they also run under Rosetta, or if they manage to run natively.

Good news - just tried a Chrome-based app and they start as and stay a Apple SIlicon binary!
Only issue I encountered was a warning about Epichrome helper failing to launch on startup when I started the app the first time. Went away on second launch after installing the extension.

Another update: after running the Apple Silicon Chrome-based app for a while, there's again a bash process running as Intel:

❯ ps aux|grep bash
asmodeus         62407   0.0  0.1  8384608  24208   ??  S     2:45PM   0:01.81 /bin/bash /Applications/Foo.app/Contents/Resources/EpichromeHelper.app/Contents/MacOS/EpichromeHelper Cleanup

If we could find out what launches this process...?

Thank you for this info! Promising that Chrome-based apps at least run natively. And thank you for the report on Epichrome Helper. I'd forgotten about that process (it's gone in 2.4.0, which I've mostly been working on), and need to make a quick update to the beta I was about to send you. Will post that as soon as it's ready...

OK, here's 2.3.28b2. I've added a key to the Info.plist files that Apple suggests might encourage M1 systems to run everything natively, but we shall see. Looking forward to hearing how it goes. Thanks!

https://www.dropbox.com/s/kjbgv23iah2hdlm/epichrome-2.3.28b2.pkg?dl=1

OK, here's 2.3.28b2. I've added a key to the Info.plist files that Apple suggests might encourage M1 systems to run everything natively, but we shall see. Looking forward to hearing how it goes. Thanks!

https://www.dropbox.com/s/kjbgv23iah2hdlm/epichrome-2.3.28b2.pkg?dl=1

Success! With this version apps created with Brave engine stay Apple Silicon apps on second (and subsequent) launches.

2.3.28b2 works very well for me on an M1 MacBook Air. I tried both the Brave and the Chrome engine, and all processes are listed as Apple in the Architecture column of Activity Monitor.

Complete startup time using the Chrome engine is around 1.5 sec quicker for 2.3.28b2 (~3 sec) compared to 2.3.26 (~4.5 sec).

That's great, @asmod3us & @richard-vd ! Thank you for the reports, and for the impressive benchmark. I'm jealous of you M1 folks!

I've just posted the release version of 2.3.28 with this fix in it, so you should be good to go with all subsequent releases. Closing for now, but if more problems occur, please let me know and we can reopen.

Heads-up that starting with Epichrome 2.4.16 (which I'll be releasing shortly), Epichrome apps will no longer run natively on Apple Silicon. As of Brave 1.27.111, Brave is (for reasons I can't fathom) no longer being released as a universal package, but only as separate packages for Intel and M1. So I now have no clean way of bundling it for both architectures. Since M1 Macs can run the Intel version, that's the version I will be packaging going forward until and unless they change this stupid way of doing things. Sorry about this...

Thanks for the heads-up. I only use the Chrome engine with Epichrome, so I will stay on 2.4.15.

I disabled checking for updates by replacing value prompt by never at key updateAction in ~/Library/Application Support/Epichrome/epichrome.plist:

<key>updateAction</key>
<string>never</string>

Hi @richard-vd,

Two things:

First, if you use the Chrome engine with Epichrome, then there's no reason not to update to 2.4.16. Whatever version of Chrome you have installed on your system, which presumably works, will continue to be the engine. This change only affects apps that use the built-in Brave engine.

Second, if you do want to set an app not to prompt for updates, changing epichrome.plist will not do that. That only sets the default value for new apps you create in Epichrome (and it gets automatically set by whatever is the last way you created an app in Epichrome).

If you want to change the setting for an app you already have you need to edit the app in Epichrome, either by drag-and-dropping it on Epichrome.app, or running Epichrome.app and clicking the Edit button and then choosing the app.

Click through until you get to Step 8, then click Advanced Settings and go to Advanced Setting 2. Then click Other Options and choose Never Update. Click on through and save the app and then it won't ask to update itself any more.

I now edited the apps as per your instructions. Thanks for clearing this up!

Heads-up that starting with Epichrome 2.4.16 (which I'll be releasing shortly), Epichrome apps will no longer run natively on Apple Silicon. As of Brave 1.27.111, Brave is (for reasons I can't fathom) no longer being released as a universal package, but only as separate packages for Intel and M1. So I now have no clean way of bundling it for both architectures. Since M1 Macs can run the Intel version, that's the version I will be packaging going forward until and unless they change this stupid way of doing things. Sorry about this...

What would be the steps to swap the bundled Brave Engine manually? I upgraded to 2.4.16. and all my apps are now Intel binaries again...

Hi @asmod3us, sorry, I tried to do this on my system and it doesn't work. It breaks the codesigning, as you end up trying to run an originally-signed version of Brave with a modified Info.plist, which causes it to refuse to run.

Did anyone come to some solid end results in getting Apple Silicon running reliably? Would like to keep this project going - albeit maybe via a fork with a native coded app and perhaps an easy(ish) interface for code signing if necessary... There just don't seem to be any other real drop in replacements for Epichrome at this point.

Apple Silicon used to work, but then maybe 6 months ago, Brave stopped distributing as a universal app. I didn't want to put two whole distributions of Brave into the package, which would've bloated it too much, and didn't have the bandwidth to start delivering two versions of Epichrome. So as of 2.4.16 (2021-08-05), the Brave engine is no longer native on Apple Silicon...

I understand. I spent some time today attempting to yank out the Intel Brave engine and replace it with the ARM64 (Apple Silicon) version, but for some reason each time I start an app it simply still uses the older Brave engine.

I was thinking that the Brave Browser Framework.framework in /Applications/Epichrome/Epichrome.app/Contents/Resources/Runtime/Engine/Link/Frameworks could be replaced, but it seems like something else is going on...

At this point my thought / goal is to get Brave-AS(ARM64) working before doing doing some significant reworking with a compiled version to replace all of the compiled scripting componentry just to eke out some more life/time. Presently the Intel execution of Brave is murdering some of my use cases due to the additional heaviness that might not be noticed by "lighter" users.

Have you gotten your own build working? That would be the real way to make an ARM build. You'd just need to put the latest ARM version in the app/Engines directory and it would build an ARM version.

Hi, should I assume you're meaning cloning the repo and make'ing the project in with the app folder prior to make? And if so, what would I drop into the app/Engines/ folder? The full Brave Browser.app or the Brave Browser.app/Contents/Frameworks/Brave Browser Framework.framework?

I guess I need to read through the Makefile to get an idea of how things tie together rather soon.

I'm sorry it's taken me (and @ylluminarious) some time to circle back to this. We've had some things that have taken up an inordinate amount of time the last few months.

Yeah, you should be able to build on your own system once you get a few dependencies in place. You'd need a full Brave installer package or DMG (however they're distributing it now--the Makefile will work with either) in the app/Engines directory, and it has to be renamed with the Brave version number at the end (you'll be able to find the pattern it's looking for in the Makefile). You'll also need to set up some codesigning stuff, which I laid out in my latest reply to issue #336 .

FYI, current download from https://laptop-updates.brave.com/latest/osxarm64 is: Brave-Browser-arm64.dmg with version info: Version 1.36.112 Chromium: 99.0.4844.51 (Official Build) (arm64) (I guess this can be had here as well: https://brave.com/latest/)

Strangely I thought the version numbers before (eg, last build) used 96.xxx vs 1.xxx and so I was thinking it was using the Chromium version instead...?

@dmarmor I set some time aside, finally, to start to dig into this situation. I was initially thinking it might be either:

A) a matter of doing as you instructed and (my interpretation) just push the Brave-Browser-arm64.dmg into epichrome/appEngines and it could pick it up, but unfortunately it needs a version number postfixed to it. I manually changed it to Brave-Browser-arm64-1.37.113.dmg and a couple other permutations, but no luck. Or...

B) perhaps simply change the URL for engineUrl to the one you have commented out, which seems to still be a viable URL, but that also blows up.

The script is a little muddy at points and I need to really trace it better and/or begin rewriting things. I had HOPED I would be able to get Brave updated to an arm64 build to tide me over as I started working through the rewrite, but I'm guessing that's not going to be possible at this point.

I think, sanity wise, I might start with either rewriting each script at a time and replacing it while retaining your general logic... But I might need to essentially rewrite everything with a textual UI initially and then migrate to a GUI after I have things working. To be honest, a TUI for Epichrome is perfectly acceptable for me and probably many, but I'd eventually convert that to a GUI... Anyway, just some musings here as I poke about.

Hmm...as I recall, option A should've worked. I think the naming convention Brave-*-X.XX.XXX.dmg should've been picked up by the Makefile. Did it just not find the engine at all, or did it fail with an error somewhere else? Any error messages or other info you could post would help me remember what might've been different. I really thought there was no other difference between building the ARM and Intel engines...

Well this is very interesting. I just tried it again - with the modified engine line:

engineUrl='https://laptop-updates.brave.com/latest/osxarm64/release'

And it actually pulled the new browser down this time. The only differential between when I last tried it and now is an Xcode update and time... Perhaps something was off at the time with something on the Brave site or otherwise. Well hmm - I guess this is good.

So I did get a bit further, obviously:

1. I got to a point where it wanted the trash command, and it seems that brew install macos-trash fills that need just fine (the MacPorts version does not).

2. I got to a sips command and got this:

$ make
cat: private/codesign_identity.txt: No such file or directory
Current Brave engine 1.37.116 is the latest!
sips --setProperty format png --out build/icons/login_app.png ../images/icons/login_app.psd
~/epichrome/images/icons/login_app.psd
  ~/epichrome/app/build/icons
mkdir: build/icons: File exists
make: *** [build/icons/login_app.icns] Error 1

I ran it again and got this:

make                                                                                                                                                                                                                                  
cat: private/codesign_identity.txt: No such file or directory
Current Brave engine 1.37.116 is the latest!
sips --setProperty format png --out build/icons/login_app.png ../images/icons/login_app.psd
~/epichrome/images/icons/login_app.psd
Error: Unable to write image to file ~/epichrome/app/build/icons/login_app.png.rLOlL
  ~/epichrome/app/build/icons/login_app.png
Error 13: an unknown error occurred
Try 'sips --help' for help using this tool
make: *** [build/icons/login_app.png] Error 13

Not worried about the codesign line at the moment, but apparently sips must have changed in some fashion - unless you had some kind of a custom method for running it?

Hmm. That is odd. I just used the default version of sips (though that part of the Makefile is not well-tested as I used a custom Photoshop droplet I used which did a better PSD to PNG conversion). It looks like there's a file called icons in the build directory when icons should be a directory? Have you had a look to see what's in there?

One warning--if you build a version without codesigning it, you will likely run into some issues running those apps. I had trouble getting the Apple Keychain to accept credentials from those apps and I think ended up having to unlock the keychain every time I ran those apps (or something like that--it's been a long time), which is why I started re-codesigning the Brave engine...

Anyway, if you can give me any more detail on what's going on with the sips problem I can try to help diagnose...

When I run the command manually from the shell it does seem to execute:

cd app
rm build/icons
$ sips --debug --setProperty format png --out build/icons/login_app.png ../images/icons/login_app.psd
~/epichrome/images/icons/login_app.psd
  ~/epichrome/app/build/icons
$ ls -lha build/icons
.rw-r--r-- user staff 624 KB Wed Apr 20 18:18:24 2022  build/icons

And a subsequent build of course fails:

$ sips --debug --setProperty format png --out build/icons/login_app.png ../images/icons/login_app.psd
~/epichrome/images/icons/login_app.psd
   assert: mktemp(temp_path)=0 [/AppleInternal/Library/BuildRoots/d0e2ba33-ac89-11ec-ad7b-8a4162d8a34d/Library/Caches/com.apple.xbs/Sources/sips/ImageProcessing.c, line 1162]
Error: Unable to write image to file ~/epichrome/app/build/icons/login_app.png.UvaMk
  ~/epichrome/app/build/icons/login_app.png
Error 13: an unknown error occurred
Try 'sips --help' for help using this tool

I guess I'm not yet following why mkdir fails - or even is done in the first place if/when this build/icons exists via sips... Hmm.

The mystery is why on earth sips would generate the build/icons file instead of build/icons/login_app.png for me in my situation whereas it appears as if it may have built properly for you with the full filename hitherto.

Thanks for the codesigning warning - I'm going to cross that bridge soon (I need to renew my ADC account; kinda been frustrated with Apple and let it run out some months ago due to the way they seem to ignore my bug reports anymore or take VERY long times to address even very important ones. In the past they were quite timely, but the last few years have become horrible).

Continuing on the sips issue, it appears I found the problem. sips does not create paths. It simply generates the output file as the last path argument that exists prior to executing. Thus if app/build/ exists, but the icons folder does not, it will create the output as the file icons instead of the final filename on the path given it. If app/build doesn't exist then it will, for example, generate the output file as build in the app folder. If you mkdir -p build/icons then sips generates app/build/icons/login_app.png just fine.

Putting an extra mkdir at the beginning of the else seems to brute-force resolve it:

    ...
    else \
        mkdir -p '$(dir $@)' ; \
        echo $@ ; \
        echo $< ; \
        cmd=( sips --setProperty format png --out $@ $< ) ; \
		echo $cmd ; \
        echo "$${cmd[@]}" ; "$${cmd[@]}" ; \
    fi

I think I'm close to the finish line here @dmarmor... You mentioned something before about a custom build of platypus and so I was wondering if I'm hitting an issue and I'm at a pausing point this evening as far as time allowance.

Ran into a problem with platypus - please let me know if you recall anything about this or if I'm not setting it up properly, etc.:

$ cd ~/epichrome/modules
$ git submodule update --init --recursive
Submodule 'modules/fileicon' (https://github.com/mklement0/fileicon) registered for path 'fileicon'
Submodule 'modules/platypus' (https://github.com/sveinbjornt/Platypus) registered for path 'platypus'
Cloning into '~/epichrome/modules/fileicon'...
Cloning into '~/epichrome/modules/platypus'...
Submodule path 'fileicon': checked out 'b270924171346807186b37b0697e19283e45aaa3'
fatal: remote error: upload-pack: not our ref 3e3f85c1ed3adfcbbf15ba602de28b4f937cc713
fatal: Fetched in submodule path 'platypus', but it did not contain 3e3f85c1ed3adfcbbf15ba602de28b4f937cc713. Direct fetching of that commit failed.

So then tried to reset this:

$ cd ~/epichrome/modules/platypus/
$ git reset --hard origin/master
$ cd ..
$ git clean -n
$ git add platypus
$ cd ../app
$ make clean
$ make

and got a Epichrome Platypus not yet built. message at the end:

cat: private/codesign_identity.txt: No such file or directory
Current Brave engine 1.37.116 is the latest!
sed -e 's/EPIVERSION/2.4.27[001]/g; s/GITHUBUPDATEURL/https:\/\/github.com\/dmarmor\/epichrome\/releases\/latest/g' \
		src/main.js > build/main.js
echo >> build/main.js
cat src/libapp.js >> build/main.js  # EVENTUALLY OPTIMIZE MAIN.JS?
cat src/libreporterr.js >> build/main.js
cat src/vcmp.js >> build/main.js
osacompile -l JavaScript -x -o build/main.app build/main.js
.: replacing existing signature
codesign --remove-signature build/main.app
chmod 444 build/main.app/Contents/Resources/Scripts/main.scpt  # lock main.scpt so it doesn't get altered with each run
mv -f build/main/Contents/Resources/Scripts/main.scpt Epichrome/Epichrome.app/Contents/Resources/Scripts/main.scpt
mv -f build/main/Contents/PkgInfo Epichrome/Epichrome.app/Contents/PkgInfo
mv -f build/main/Contents/MacOS/droplet Epichrome/Epichrome.app/Contents/MacOS/droplet
mv -f build/main/Contents/Resources/droplet.rsrc Epichrome/Epichrome.app/Contents/Resources/droplet.rsrc
rmdir build/main/Contents/MacOS
if [[ -d build/main/Contents/_CodeSignature ]] ; then rmdir build/main/Contents/_CodeSignature ; fi
sed 's/EPIDISPNAME/Epichrome/g; s/EPISHORTNAME/Epichrome/g; s/EPIVERSIONCODE/204027.100.1/g; s/EPIVERSION/2.4.27[001]/g; s/THISYEAR/2022/g' 'src/Info.plist' > 'Epichrome/Epichrome.app/Contents/Info.plist'
sed -e 's/EPISCANMODE/login/g' 'src/scan/ScanExec' > 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app/Contents/MacOS/EpichromeLogin'
chmod 755 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app/Contents/MacOS/EpichromeLogin'
sed 's/LOGINDISPNAME/Epichrome Login/g; s/LOGINSHORTNAME/EpichromeLogin/g; s/EPIVERSIONCODE/204027.100.1/g; s/EPIVERSION/2.4.27[001]/g; s/THISYEAR/2022/g' 'src/scan/Info.plist.login' > 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app/Contents/Info.plist'
cp 'build/icons/login_app.icns' 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app/Contents/Resources/app.icns'
sed 's/EPIVERSION/2.4.27[001]/g; s/EPIDEBUG/1/g; s/EPILOGPRESERVE/9/g; s/EPIBACKUPPRESERVE/9/g' 'src/core.sh' > 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/core.sh'
cp 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/core.sh' 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app/Contents/Resources/Scripts/core.sh'
cp 'src/filter.sh' 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/filter.sh'
cp 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/filter.sh' 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app/Contents/Resources/Scripts/filter.sh'
sed 's/EPIVERSION/2.4.27[001]/g' 'src/apputil.js' > 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/apputil.js'
echo >> 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/apputil.js'
cat 'src/libapp.js' >> 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/apputil.js'
cp -a 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/apputil.js' 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app/Contents/Resources/Scripts/apputil.js'
sed 's/EPIEXTIDRELEASE/ngbmbabjgimgbfobhfhjpfhpmpnhbeea/g; s/EPIEXTIDBETA/cknkfdhlojihpopgbmoknioompcojicj/g; s/GITHUBUPDATEURL/https:\/\/github.com\/dmarmor\/epichrome\/releases\/latest/g' 'src/launch.sh' > 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/launch.sh'
cp 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/launch.sh' 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app/Contents/Resources/Scripts/launch.sh'
xattr -cr 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app'
codesign -vv --force --options runtime --entitlements src/package/entitlements.plist \
		--sign - 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app'
Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app: signed app bundle with generic [org.epichrome.Login]
codesign --verify --deep --strict --verbose=2 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app'
Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app: valid on disk
Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app: satisfies its Designated Requirement
spctl --assess --type execute --verbose=4 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app'
Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app: accepted
override=security disabled
touch 'Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app'
osascript Epichrome/Epichrome.app/Contents/Resources/Runtime/Contents/Resources/Scripts/apputil.js '{"action": "register", "path": "Epichrome/Epichrome.app/Contents/Library/LoginItems/EpichromeLogin.app"}'
cp 'build/icons/epichrome.icns' 'Epichrome/Epichrome.app/Contents/Resources/droplet.icns'
cp 'build/icons/apptemplate_bg_white.png' 'Epichrome/Epichrome.app/Contents/Resources/Icons/apptemplate_bg_white.png'
cp 'build/icons/apptemplate_bg_gray.png' 'Epichrome/Epichrome.app/Contents/Resources/Icons/apptemplate_bg_gray.png'
cp 'build/icons/apptemplate_bg_black.png' 'Epichrome/Epichrome.app/Contents/Resources/Icons/apptemplate_bg_black.png'
cp 'build/icons/apptemplate_shadow.png' 'Epichrome/Epichrome.app/Contents/Resources/Icons/apptemplate_shadow.png'
cp 'build/icons/doctemplate_fg.png' 'Epichrome/Epichrome.app/Contents/Resources/Icons/doctemplate_fg.png'
cp 'build/icons/doctemplate_bg.png' 'Epichrome/Epichrome.app/Contents/Resources/Icons/doctemplate_bg.png'
cp 'build/icons/scan_app.icns' 'Epichrome/Epichrome.app/Contents/Resources/scan.icns'
cp 'src/epichrome.sh' 'Epichrome/Epichrome.app/Contents/Resources/Scripts/epichrome.sh'
cp 'src/legacy.sh' 'Epichrome/Epichrome.app/Contents/Resources/Scripts/legacy.sh'
cp 'src/makeicon.sh' 'Epichrome/Epichrome.app/Contents/Resources/Scripts/makeicon.sh'
cp 'src/makeicon.php' 'Epichrome/Epichrome.app/Contents/Resources/Scripts/makeicon.php'
sed -e 's/EPIVERSION/2.4.27[001]/g' 'src/update.sh' > 'Epichrome/Epichrome.app/Contents/Resources/Scripts/update.sh'
sed -E 's/^epiVersion=.*$/epiVersion='\''2.4.27[001]'\''/' 'src/version.sh' > 'Epichrome/Epichrome.app/Contents/Resources/Scripts/version.sh'
sed -E -e 's/EPIVERSION/2.4.27[001]/g; s/EPIRUNTIMEIDS/"chrome-extension:\/\/ngbmbabjgimgbfobhfhjpfhpmpnhbeea\/",\'$'\n''        "chrome-extension:\/\/cknkfdhlojihpopgbmoknioompcojicj\/"/' src/org.epichrome.runtime.json > Epichrome/Epichrome.app/Contents/Resources/NMH/org.epichrome.runtime.json
sed -e 's/EPIVERSION/2.4.27[001]/g' 'src/epichromeruntimehost.py' > 'Epichrome/Epichrome.app/Contents/Resources/NMH/epichromeruntimehost_2.4.27[001]'
chmod 755 'Epichrome/Epichrome.app/Contents/Resources/NMH/epichromeruntimehost_2.4.27[001]'
sed -e 's/EPIVERSIONCODE/204027.100.1/g; s/EPIVERSION/2.4.27[001]/g; s/THISYEAR/2022/g' 'src/Info.plist.runtime' > 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Filter/Info.plist'
cp 'src/AppExec' 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Filter/AppExec'
sed -e 's/EPIVERSION/2.4.27[001]/g' 'src/main.sh' > 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Filter/main.sh'
sed -e 's/EPIVERSION/2.4.27[001]/g; s/EPIMAJORVERSION/2.4/g; s/EPIEXTIDRELEASE/ngbmbabjgimgbfobhfhjpfhpmpnhbeea/g; s/EPIEXTIDBETA/cknkfdhlojihpopgbmoknioompcojicj/g' 'src/welcome/welcome.html' > 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Filter/welcome.html'
cp 'src/profile/bookmarks.json' 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Filter/Bookmarks'
cp 'src/profile/prefs_com_brave_Browser.json' 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Filter/Prefs/prefs_com_brave_Browser.json'
cp 'src/profile/prefs_com_google_Chrome.json' 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Filter/Prefs/prefs_com_google_Chrome.json'
sed 's/"restore_on_startup": 5/"restore_on_startup": 1/' 'src/profile/prefs_com_brave_Browser.json' > 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Filter/Prefs/prefs_nourl_com_brave_Browser.json'
sed 's/"restore_on_startup": 5/"restore_on_startup": 1/' 'src/profile/prefs_com_google_Chrome.json' > 'Epichrome/Epichrome.app/Contents/Resources/Runtime/Filter/Prefs/prefs_nourl_com_google_Chrome.json'
scripts/platypus.sh --name Epichrome \
		 --interface-type None \
		 --app-icon build/fake.icns \
		 --document-icon build/fake.icns \
		 --interpreter /bin/bash \
		 --app-version 2.4.27[001] \
		 --author 'David Marmor' \
		 --bundle-identifier org.epichrome.APPBUNDLEID \
		 --droppable \
		 --background \
		 --quit-after-execution \
		 --uniform-type-identifiers 'com.compuserve.gif|public.html|public.jpeg|com.netscape.javascript-source|com.microsoft.word.mhtml|org.videolan.ogg-audio|org.videolan.ogg-audio|org.xiph.ogg-video|com.adobe.pdf|public.png|public.svg-image|public.plain-text|org.videolan.webm|public.webp|public.xhtml' \
		 --uri-schemes 'http|https|ftp|file' \
		 --optimize-nib \
		 build/fake.sh build/runtime.app
Epichrome Platypus not yet built.
make: *** [runtime] Error 1

If I do go into ~/epichrome/modules/platypus/ and build it, it seems to "work":

$ cd ~/epichrome/modules/platypus
$ make
...
** BUILD SUCCEEDED **

make: *** [build_unsigned] Error 65

Perhaps I could / should just use Homebrew or MacPorts and just link the script up to that (new path) on line 50:

...
platypusShare='/usr/local/share/platypus'
...

I should, however, indicate that Platypus was built properly and does live in epichrome/modules/platypus/products/Platypus.app and runs seemingly without any problem when executed by itself.

Hmm, I did also notice that there is a build of it in the build/ folder, but it doesn't rm when make clean or make distclean is executed. Also, when I do manually rm it it appears as though something else is going on here now so I have to investigate further.

After some more fiddling around, I think the final issue even with Platypus I may be facing here may be codesign. I'd like to really get this to build and run before paying Apple so what is the preferred method for the disabling codesign identity? I thought it should be just a matter of changing the value to "-" in the Makefile:

#CODESIGN_IDENTITY:=$(shell cat private/codesign_identity.txt)
CODESIGN_IDENTITY:="-"

Sorry for the long delay--did you get this working? I remember adding codesigning to everything mostly defensively as apps simply wouldn't run without it, so I never built in an official mechanism to build without signing. It might require editing the Makefile, but at this point I really can't remember how deeply entwined in the build the codesigning was...