Hi eM Client team,
I have just bought a new Surface Pro 11th Edition with a Qualcomm Snapdragon Elite SoC running Windows on Arm (WoA).
Most of my main productivity applications, e.g, Microsoft Office and Affinity Suite v2, are already available in Arm native versions.
When can I expect an eM Client for WoA?
Best wishes,
Thomas
eM Client already runs on ARM based devices. Please see this post where I described our reasons for using a single release for all: emClient 64 bit for extra native security features access - #14 by Gary
Hi Gary,
I do of course understand that you offer a 32-bit installer only “to simplify distribution”.
On WoA, though, this means that eM Client is running in emulaltion mode, which clearly has performance constraints compared to native.
Others handle this with a two-pronged approach. At Mozilla for example, users are presented with a “best guess” installer on the download page, but can also download other installers (including native Windows ARM64/AARch64) if they would like to.
So, regardless of your distribution, I would still like to have a native Windows on Arm version. I understand that this market is still niche, but the Copilot-Plus-PC marketing machine will surely change this to a certain extent.
Best wishes,
Thomas
I guess you didn’t read the other post:
“There is no visible performance penalty of running the application as 32-bit because the dominant operations are not CPU bound. They are mostly constrained by the disk and network throughput performance. Also, the reliance on the .NET platform allows us to use even recent CPU extensions in the 32-bit mode without resorting to supporting the lowest common denominator when it comes to CPU models.”
Of course I have read the other post. Let me reply with a quote from Microsoft:
While having your app run under emulation on Arm devices is a great place to start, your app will benefit from native performance gains and the unique qualities of Arm-powered devices if you rebuild to add Arm support to your app.
(How emulation works on Arm | Microsoft Learn)
I hope that you might change your mind over time about this and will enjoy eM Client in emulated mode for the time being.
Have a great Sunday!
Given the June 2024 release of the latest ARM processors, with more to come in 2025, are you planning an ARM version?
And eM Client would cut a fine figure at Windows ARM software | ‎Home (ver.lt) for sure.
I do not want to rub it in, but I too would like a native version of eM Client. After all, it is because of the lackluster New Outlook forced experience on ARM devices that I am switching over to you guys.
I agree with @Gary I don’t think it really would be much faster creating a native arm version.
Eg: I have an Arm CPU based Mac M1 8GB Ram and run eM Client on the Mac side (Sonoma) & eM Client in Parallells (Win 11) and both r really quick.
Unless there is a massive advantage, the cost for a developer to do that probably is not worth it. The CPUs & GPUs are getting so quick now anyway where even virtual boxes run amazingly quick.
Then why do so many companies, big and small, offer native ARM versions of their apps? I simply want all of my daily drivers (and eM Client is one of them) to be native. And that is why I brought up the question.
If the effort for eM Client is to costly, then please be honest and state that clearly. Everybody will understand.
They must find the effort worth the benefits, or do it for marketing purposes. In the case of eM Client, they decided the benefits didn’t outweigh the cost as explained by Gary. So it looks like at this point if your goal is to have all your OS applications ARM native only, then eM Client won’t meet that requirement unfortunately.
I personally stopped worrying about 32bit vs 64bit and non-native vs native if the application met my needs. Of course if there was a huge benefit, like in the case of needing a 64-bit version so it could support more then 4GB of memory (like software for graphics or video editing), then yes of course it would be highly expected and needed. Even today I run a mix of 32-bit and 64-bit Windows applications without much concern. I don’t think an email client is software that has a requirement of needing to be 64-bit or native for most functions, so it doesn’t concern me how it is delivered as long as it meets my expectations in how it performs.
At this point your best option would be to add it to SleekPlan (https://emclient.sleekplan.app) and if enough people vote for this because they find it a necessity, eM Client might consider an ARM native version.
Been there, done that: Offer a native Windows on Arm (WoA) version | Improvement | eM Client. Thank your for the tip.
Is there any update on this? I’d like to throw my hat in.
It’s actually quite naive to say that, and the program is going to be left behind. Arm64 is all about the optimizations, battery life etc. and I think it’s time for the developer to revisit it. Rebuild and optimize this mail client, make native versions for Windows Arm64.
Run through Prism Emulation on Windows 11 ARM (Microsoft Surface Pro 11th Edition), there’s a clear lag when using it with a significant impact on battery life.
There is no visible performance penalty of running the application as 32-bit because the dominant operations are not CPU bound.
There is quite visible performance penalty when running in emulation mode on Surface Pro, as well as battery penalty (which means I cannot run email client in the background when I need battery). It is most likely due to emulation layer itself, but it could be a non-issue with an extra binary.
New to Windows ARM, I find this to be the best Mail app. However, I will not use it as a non-native 32-bit program. Too bad.
How is it that you can build an installation for 64-bit MacOS but cannot offer one for Windows ARM? The current market share (of Windows laptops) of Windows ARM laptops is about 20%. 80% of all laptops sold are Windows-based, meaning ARM laptops have about a 16% share of the total laptop market. Apple currently has a 10% share of the total laptop market.
We are not completely ruling out release of the WoA version, it largely depends on demand and overcoming technical constraints. Historically, the two big blockers were our use of Chromium Embedded Framework and installers.
We ship a customized version of Chromium which is used as the engine for displaying HTML content in emails and elsewhere in the app. The binaries for Chromium are rather large which makes it impractical to bundle the ARM binaries in the same installer as the x86 version.
In an upcoming major version we will be moving to a new version of Chromium and dropping support for old Windows versions. This will allow us to do some more substantial changes, including evaluation of more modern installer technologies (eg. MSIX / MSIX Bundles).
The biggest challenge is still distributing multiple versions for multiple CPU architectures without unnecessarily big downloads. We need to support several distribution mechanisms (web page + direct updates, Windows Store, and installation through group policy on enterprise systems).
There is no visible performance penalty of running the application as 32-bit because the dominant operations are not CPU bound.
This is not just an empty claim. We actually test eM Client on Windows on ARM devices. Our macOS version is ARM64, and we internally produced native Windows ARM builds for testing which we can directly compare to the regular Windows version running on the same WoA device. The benefits from running the native version never outweighted the negatives of additional complexity in the app distribution and testing. Prism emulation is actually doing really good job at the translation and caching the results of the binary translation. While there’s a penalty for the first application run this penalty diminishes rather quickly after the cache is populated and the app is in steady state.