Will anyone know my app is not Silicon native?

Will the average user even notice that a run of the mill app is not a universal binary? Apart from power apps like multimedia creation and games, will it even be noticeable?

I’m trying to justify not buying a Apple Silicon machine until the Macbook 16" comes out. :wink:

It’s not urgent to have every utility native right away.

So you can do that somewhere in 2021 and you will be fine.

When Apple switched to Intel, they provided Rosetta which ran PowerPC apps transparently, so for all intents and purposes, users could not see the difference. It took Apple removing Rosetta in Lion to force users to upgrade to Intel able apps.

From what I read, Big Sur on Apple Silicon runs Intel apps transparently thanks to Rosetta 2. So unless users insist on Apple Silicon apps (some will do), most users won’t see the difference.

Personally, I am waiting for Apple Silicon iMac, which may show by the end of next year, to replace my current machine.

Your users are going to ask you “Is your app Silicon native”? And you need to display “Silicon native” on your website so that at least the few users who can read won’t ask you.

Get a Mini until the 16inch comes out.

1 Like

You can offer an experimental release version when Xojo is capable of shipping ARM Mac apps.

1 Like

In most uses, I would say the user will see no difference.
But … I already got a lot of mails asking when my app will be AS native. Many users do seem to think it is faster/better when they have an AS device. In fact, if you do not make an AS version available you could loose sales atm

About speed comparison:
I have done many tests now with x265 (open source HEVC encoder). And the Intel compiled version is about 150% faster compared to a native ARM build version (compared with about equally CPU specs/cores)
Reason is that many code, like x265 uses highly optimised Intel instructions that are absent in ARM CPUs. There are some interesting reads about this to be found with Google.
Huawei has contributed some ARM optimisations for x265 but still the Intel version is way faster.
Try telling that to your users that bought an AS device and think it’s faster then ‘older’ Intel devices. Figures…

1 Like

The average Joe will check the information in finder and see that it is not a universal and running in Rosetta, and might complain. But as currently 99 percent of all apps are not yet native, I agree that you will have a bit of time.

Why will it show as running in Rosetta? That’s on first run only, isn’t it?


I have a screenshot in the article below. The user can basically decide himself, which part of a universal app he wants run. Default is ARM, but you could force the system to use Rosetta. Obviously macOS will only show you this option, if the app is universal. Otherwise it can only Run in Rosetta2 and you can’t change this setting. But it is visible and transparent to the endusers.

And I expect that soon some magazines will explain this in all depth and I do expect people looking at this (exactly how it happened in the old PowerPC move days) and they might ask when universal will be available, even though Intel might still work perfectly fine.

Two ways:

  • In the Activity Monitor
  • The ‘Get Info’ has a option ‘Open in Rosetta’. If this is enabled, it runs in Rosetta.

Side note about Homebrew.
Any reason why you should use Homebrew? There are much better ways to compile sources and even better … getting them static build which is something Homebrew cannot do (which is major flaw and a very good reason not to use it).
Homebrew is lazy-mans way of compiling. Avoid it and do it the proper way - only compile static builds that are portable.

My understanding is that this time, Rosetta translates the app from Intel to Arm code, on first run. Presumably meaning that the translated app is then stored so that on second and subsequent runs, you are running an Arm app (I’m not talking about Universal here). Whereas last time Rosetta interpreted each PowerPC instruction, which was why Apple had to keep and maintain PowerPC versions of all APIs and frameworks as well as Intel ones.

If this is the case for how Rosetta works this time, there’d be no penalty for Apple to keep Rosetta around for a long time, because I’d like to think they’d arranged matters such that the translated apps could use the native APIs and frameworks.

I need one Postgres library, that’s all and I’m lazy :-).

My understanding is that this time, Rosetta translates the app from Intel to Arm code, on first run

So in the time-honoured spirit of cheating, if we

  • take our intel app and
  • run it on our own machines,
  • could we find the translated version,
    package, codesign, and notarise it,
  • ship it as an ARM build?
1 Like

Here’s what Apple says:

“Rosetta is a translation process that allows users to run apps that contain x86-64 instructions on Apple silicon,” its developer page reads. “Rosetta is meant to ease the transition to Apple silicon, giving you time to create a universal binary for your app. It is not a substitute for creating a native version of your app.”

What is the translation process, exactly?

“If an executable contains only Intel instructions, macOS automatically launches Rosetta and begins the translation process. When translation finishes, the system launches the translated executable in place of the original. However, the translation process takes time, so users might perceive that translated apps launch or run more slowly at times,” Apple explains.

I don’t know exactly, but I assume that the initial process is only a kind of “pre-parsing” and I assume that the Neural Engine plays a role as well. At least I can observe that those apps I’m running regularly have less delay than others but there is always a notable but small delay compared to ARM builds.

Well, an executable that is thus translated from one hardware to another won’t be as good as having the original source compiled for the final target; the code won’t be as well optimised. But I read that this process is only on first run, meaning that the translation would therefore need to be stored. This win’t be as good as a native app, but if this is how it works AND the translated app can use native APIs then there’s a lot less pressure on Apple to remove Rosetta sooner rather than later (as there was with the PowerPC/Intel move).

1 Like

This “at times” is an indicator to me, that it is translating on every call. Why the first translation runs longer? I have no idea. As a developer I would assume that on the first run they are already doing some pre-translation, analyzing the beast etc. but I don’t think that there is magically an ARM app there which you could run separately. Otherwise Xojo would most likely already run natively :-). Might be one reason why you can’t uninstall Rosetta2.

@ChristopheDV Can you please share your recommendations? I’m willing to learn and looking at alternatives, I have those rare moments in life where I’m not lazy :-). I used homebrew for only library I need for datagrip for one particular customer, and I only followed the description from the vendor’s forum.

Learn how to compile static builds. The best way is to use a Ramdisk and point the export path to a folder inside the Ramdisk.
I will send you a PM with some pointers…

No, that will not work.

1 Like