Detect arm64 or Intel architecture

I have a script that runs a unix executable, and I want the script to decide which executable to choose, depending on whether it’s running under Apple Silicon or Intel.

On my borrowed Apple Silicon machine, I enter in the terminal uname -m and get the result arm64.

So, using SD7 on an Apple Silicon machine, I enter

set thisArch to do shell script "uname -m"
display dialog thisArch

and get the result x86_64. If I save this as an applet, and open it in the Big Sur Script Editor, I get the same result, but if I then export that script from the Big Sur Script Editor, and run it, it gives the result arm64.

My app that runs the unix executable can’t be edited in the Script Editor (too much stuff in the Contents folder, maybe), so I tried copying its main.scpt in to the Big Sur editor and exporting it, and then copying the exported script back into the app - but that continues to give x86_64 as the architecture, perhaps because the original droplet was made in that architecture.

Is there a better way to detect which architecture the current machine really is? Or should I wait until SD 8 arrives? (I’ve requested beta access.)

If you are running an Intel-only app on M1, then its child processes will inherit that as well.

For example, if I tell use ‘Get Info’ on and tell it to “Open using Rosetta” as shown here:

then uname -m will return x86_64

(This is also how people are getting brew to work on Apple Silicon… telling iTerm or Terminal to run under Rosetta, and then brew installs x86_64 utilities.)

So until there is an Apple Silicon version of Script Debugger, you’ll get an Intel result.

Alternative 1

It might be possible to find a file which exists on Apple Silicon Macs that does not exist on Intel Macs. For example, the file /System/Library/Extensions/AppleARMPMU.kext/Contents/MacOS/AppleARMPMU seems like it might be one.

If you run the file command on that file you can this

/System/Library/Extensions/AppleARMPMU.kext/Contents/MacOS/AppleARMPMU: Mach-O 64-bit kext bundle arm64e

Alternative 2

Since all current M1 Macs have an M1 graphics card, you could run this command:

system_profiler SPDisplaysDataType | awk -F': ' '/Chipset Model/{print $NF}'

and see if you get Apple M1 as a result. If yes, you are on an M1 Mac. That may not be useful in a year or two, but it’s an option for right now at least.

Thank you for these. I will experiment and report.

My AppleScript app runs the DOSBox-X unix executable, and in the app I’m experimenting with, that executable is arm64-only. Even though it’s launched from my Intel app, the process itself is native M1. This may be a weird special case.

I like your Alternative 1 - it’s likely to work a year or two from now, when I’ve forgotten why Alternative 2 isn’t working…

You could get the architecture a known app, like Finder, is running on:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use framework "AppKit"
use scripting additions

-- classes, constants, and enums used
property NSBundleExecutableArchitectureX86_64 : a reference to 16777223
property NSBundleExecutableArchitectureARM64 : a reference to 16777228 -- define if you use, because it won't be defined under older versions of the OS

set theArch to (current application's NSRunningApplication's runningApplicationsWithBundleIdentifier:"")'s firstObject()'s executableArchitecture()
if theArch is NSBundleExecutableArchitectureX86_64 then
	-- do your stuff
end if

An arm64-only executable sounds a weird beast…

That method works. Thank you. I’ve now got my application running one of two different unix executables depending on the architecture.

Here’s an arm64-only executable, compiled on an arm64 machine, in case anyone wants to look at it:

I meant weird in the sense of weird to not to distribute a universal build.

Another alternative is to use lipo to create your own universal binary.

Ah - thank you! I didn’t know about lipo - will experiment.