Mac arm64 Native Build?

[alexclst]

About a year ago there was a comment on a thread by a Local software engineer that mentioned a native build was “months”, not “years” away. I understand that it is not easy to make a native build necessarily, but any update on when a native Local build will be released?

Anything about complexity I see as basically an excuse, because on my M1 Mac I have other Electron apps that are native, as well as native versions of all the tools used by Local (PHP, MySQL, etc.). So what is the holdup?

I understand from my own experience that running Local under Rosetta 2 is just fine, it is for me and I have it running nearly all the time. But Rosetta 2 is transitional technology, it will eventually go away. I would much prefer to have Local safely native years before Apple announces a Rosetta 2 end date (which I expect to still be years away).

Are we now in the “months” timeline that was quoted a year ago?

[austinwendt]

Hi @alexclst,

I am happy to provide some context. Local currently ships with Electron 13 due to several different dependencies. Native M1 support comes standard with current Electron, v18+.

We’re actively in the process of updating the version of Electrons shipped with Local, but we’re blocked from supporting those native builds until we resolve the dependencies necessary to make that possible.

I don’t have a date for you, but the work to resolve those dependencies and upgrade Electron is actively in progress with the development team.

Thanks,
Austin

[alexclst]

Thanks for the update. As I said, Rosetta 2 isn’t detrimental to my Local experience (I use a Mac mini, which means battery concerns aren’t relevant), so this isn’t an urgent issue. But I was curious, and I am glad to hear that work is still actively underway. I’ll await hearing more in the coming months.

[alexclst]

Just curious if there is any progress on this. It seems that Rosetta 2 is at least with us through macOS Ventura, but still hoping to see Local 6.x or 7 end up with Electron 18+.

[austinwendt]

Hey @alexclst, thanks for checking back in! Yes, still making progress - we’ve unblocked ourselves by removing some dependencies that have been deprecated. We’re nearly there on upgrading our Electron version.

Part of this upgrade will also be shipping native binaries for PHP (and other services packaged with Local), which the engineers are working on first. Even just with a native build for PHP, we’ve seen sites performing nearly 2x as fast on M1 machines, so that will be a big step forward too! The updated PHP versions (including the native PHP) will be included in the next release of Local. Once those are out, full-steam ahead on updating Electron.

[alexclst]

Yay! Yeah, I assumed native versions of the “lightning services” would be coming too, and it makes sense for those to be coming sooner. After all, most of the same tools I have from Homebrew native already.

Frankly, I barely look at the main Local app as I mostly use it to configure sites, but then have Tasks in VS Code set up to start and stop them as needed from my development environment via the local-cli. So this very next update will bring most of my use native, which is nice. Looking forward to that 2x speed boost.

Of course, with no ability to create sites in the CLI yet I do use the main app from time to time, so having that be native in the nearish future will be nice too. Thanks for the update!

[alexclst]

It occurs to me (looking from the outside as just a user of Local) that one way these lightning services can function is just by the replacement of them in site settings from the current Intel-only variants to Apple Silicon-only variants being an option for those of us on Apple Silicon. I am hoping, though, that this next update makes this more invisible than that (and hence part of why it is taking time), because though most services can be replaced, MySQL cannot, at least in the current version of Local, and I’d prefer having all lightning services Apple Silicon native even on my dozen or so existing sites. I’d rather not need to recreate any Local sites after this upcoming update just to take advantage of native lightning services. So hopefully part of what you guys are taking time to figure out is how to invisibly “update” the services to native versions on whatever architecture is the current one. Maybe this becomes one app us Apple Silicon folks just need to download a purely Apple Silicon build of to make the app-packaging side of things a bit cleaner on your end.

[alexclst]

So, just for curiosity, is this beta the one that begins to bring the lightning services native? Or, as honestly I’d expect, it to take a while longer before such transitions see the light of day?

[plaidpowered]

Hello, fellow M1 user here,

I tried the beta @alexclst linked and don’t think it does have new services, activity monitor shows httpd running as an Intel process.

This build introduced some major issues for me, namely in response time. It was already slow, a reason I was eager to try a native beta, it would take Local sometimes 5-10s to respond and return a page, while Query Monitor shows wp-admin pages generated in around 2-3s. It does the same for non-php files, even small CSS files will have a TTFB of somewhere around 5s.

But that was the current public release build of 6.4.2, on this beta, the response time has jumped up to 30s or more! For php and non-php files, running Apache / PHP 8.0.22

I don’t know if it was this particular build that caused the slowdown, I jumped from public to the most recent beta, but needless to say, I’m going back to the stable release and crossing my fingers that the issue is resolved before 6.4.3 goes public.

[austinwendt]

@alexclst You’re correct, that is our goal! That beta, as of yet, doesn’t make the services native. We are working on a full-native build of Local that will include native binaries of services like PHP. That will mean that new releases of Local will have an additional link for “Apple Silicon” or something similar that M1 users will download instead of the “Intel” build (names TBD). It is closer than you think, but no, it is not yet in that 6.4.3 build.

@plaidpowered That is interesting! Definitely no pressure to use the beta, that is why we use that for development purposes to catch things before it is out in the wild. Two questions that could help us troubleshoot:

1. Can you use the same site from the public stable release in the new beta build and compare the response times? You should be able to export the site from the stable build of Local and then import that into the Local Beta build.
2. Can you share your Local logs so that we can dive in? I wasn’t expecting 6.4.3 to make it faster for M1 users, but it certainly shouldn’t have slowed it down that dramatically. Here’s a guide on doing that, you can just upload the log .zip in a message here - Retrieving Local’s Log File - Local

[plaidpowered]

So, I feel like a complete idiot.

I was collecting logs and taking screenshots between the two versions of Local and finally as I was wrapping up, I noticed something in my Inspector’s Network panel: throtlling was turned on. To “Fast 3G”.

I’m not sure how long it’s been like that, the last time I remember throttling my connection for testing was months ago. So essentially whenever I have the Developer Tools open, which is basically all the time I’m working, it’s been throttling my connection back to the internet’s Iron Age.

So with that discovered and addressed, I am actually experiencing zero problems with the latest beta. If anything, it’s running a little faster on PHP 8.0.22 than on the public release Local running 8.0.0. There does not seem to be any major discrepancy between Query Monitor and the TTFB. Usually just a couple hundred ms at most. Local beta is running my sites almost as fast as my Ubuntu-based LAMP virtual machine, which honestly is quite impressive considering Ubuntu is native ARM build and Local is running through Rosetta.

So no problems to report from me at all, thanks for all your hard work and again, sorry about this wild goose.

[austinwendt]

No worries at all, that is great to hear! That is especially awesome, given that Local’s binaries in the build you’re referencing aren’t native, like you said.

We’re really close with an Apple Silicon build for Local along with those native PHP binaries; I’m eager to see how much faster we can get!

[alexclst]

Yeah, looking forward to Apple Silicon native builds! Local is the only app on my Mac that relies on Rosetta any longer (after a few other apps got native updates in just the last two weeks). It does not exactly feel too slow to me, but I am sure the native versions will feel somewhat faster.

It occurs to me, this thread alone is how I and @plaidpowered and a few others who’ve interacted here may know the update is out assuming that you let us know here, but if this update will require a separate re-download of Local, you guys should think about how to alert everyone else. Or perhaps the auto-update mechanism can be smart enough to shove Apple Silicon Macs over to that build when it comes out?

[austinwendt]

That is a good point - we’ll have a few different methods for communicating that when it is available. It is has been requested by a lot of users, so we’ll make a big deal out of it.

Our initial plan was to ask users to download the correct build when they’re installing Local, or if they’re an existing user, to grab the new ARM64 build from our localwp.com/releases page. The problem is that the current production Local (v6.4.2) does not know the MacOS architecture the user is running on. This would be a one-time cutover, and when updating in the future again, Local would grab the appropriate build.

It would be nice to find for Local to detect when users are on an M1 Mac but using an older Intel build and prompt them to switch over. Let me check with our engineers on what it would take to make that possible.

[alexclst]

I don’t think that Local v6.4.2 can sense Apple Silicon easily. At any rate, when I run a shell in Terminal under Rosetta 2, running arch returns i386, so I doubt that there is a great way to detect the architecture.

One thing that comes to mind is system_profiler SPHardwareDataType and check results since Intel Macs have “Processors” rather than “Chips”. But run that under Rosetta 2 and the output really shows Processor Name: Unknown. So maybe looking for that is one idea for your engineers? Or checking the specific Model Identifier info against a known list of Apple Silicon Macs.

But all of that seems a bit more work than is necessary, as long as current Local builds can make it loud that Apple Silicon users should redownload the app in the update dialog that Local shows.

[alexclst]

Looks like the wait for this is almost over! The latest Local beta 6.5.0 has native support. Of course, since the beta uses a completely separate set of data I don’t like using them much, so will wait for the final release to use this.

[afragen]

It seems to work great. I haven’t quite figured out how to test the speed.

[afragen]

BTW brew install --cask local-beta will install whichever binary is appropriate for your Mac.