ARM Binaries / Apple M1

Are there plans to also release native arm binaries for Logic 2?

For Apple M1 there is Rosetta - but that’s not really a long term strategy.
At least for me it would be a deal breaker if there isn’t anything on the roadmap.

So - what’s the plan?

1 Like

Unfortunately, we don’t have any official plans to announce for this yet. I added a comment/vote for you in the idea post below. Thanks for letting us know your need for this, and we agree… emulation isn’t great long term.

We initially had some stability issues with running the app on Rosetta. However, since releasing 2.3.38 almost a year ago, we implemented updates to the app to significantly improve performance on Rosetta, and we’ve been quite pleased with it so far.

Doing it this way for now has allowed us to work on other priority items in the pipeline. Rebuilding the app for ARM, although great long term, would halt our development efforts for a good amount of time short term (which we unfortunately can’t afford), especially given that our software team is only comprised of 3 members at the moment.

Are you a current user of our logic analyzers, or are you planning on purchasing one? If the former, I’m curious to know if you’re running into any specific issues on M1 right now that we could attempt to solve.

1 Like

Thanks for the detailed reply.

Publishing a build for ARM shouldn’t really mean “rebuilding for ARM”. Unless you have some optimisations written in assembler it should not take up that much time.

IIRC it was Logic 1 that I used before. I am now thinking of getting myself an analyzer.

I didn’t try Logic 2 yet - so I cannot speak to problems to solve. It’s more thinking of longevity. If there is no plan for supporting ARM - it becomes a statement. Or a risk. Whatever you want to call it.

If I buy standalone hardware it will just keep working. But I’ve had my share of hardware where outdated software compatibility rendered it useless. Hence my hesitance to invest if there is no commitment on your side.

No judgement - just stating my thoughts as a consumer.

1 Like

I completely understand.

Internally, this is something we’ve been looking into, but we’re not ready to make a public commitment yet.

In case anyone is curious what’s holding this up, we think we have a handle on most of the technical issues, but there is some non-trivial work that needs to be done.

  1. Our app’s front-end (an electron, JavaScript application) isn’t setup to do a cross build, as some native components that are redistributed are also used during the build process. The easiest solution for us would be to build releases of the application for M1 on M1 hardware. Unfortunately, M1-based cloud build solutions aren’t available through our current providers yet, so we’ll likely use M1 hardware at our office for builds.
  2. The back-end of our application does have some x86 SIMD accelerated code. We could likely start with a non-optimized version of this for M1 users, however it would be best if we could either add an equivalent implementation (NEON) or try out one of these other migration paths we’ve looked into.
  3. Our application also ships with a standalone copy of python, so that we’re able to run python extensions in a consistent environment across all machines. Exactly how this gets deployed, along with how it integrates with our C++ code, will need a pretty comprehensive upgrade in order to target M1.
  4. There are a handful of other sticking points that will need to be worked out too.

The biggest piece of this however is really the extensive testing, and commitment to supporting a new architecture. This is something we’ll likely release as a private beta first, and get some feedback on it, before we consider official support.

This is really only an issue due to the complex nature of our software stack, and our very small team. (We’re 3 software engineers, including myself.) I do look forward to getting this out the door eventually though.

  • Mark
4 Likes
  1. Our app’s front-end (an electron, JavaScript application) isn’t setup to do a cross build, as some native components that are redistributed are also used during the build process. The easiest solution for us would be to build releases of the application for M1 on M1 hardware. Unfortunately, M1-based cloud build solutions aren’t available through our current providers yet, so we’ll likely use M1 hardware at our office for builds.

Not sure what providers you are using - but I do know that some people work around this through QEMU - not sure this works for you. Just stating some people can make it work. Not sure about Electron. That said - I am sure there should have been plenty of people making it work. I would look at them for guidance.

That said - from testing perspective a native ARM worker might be indeed a good choice.

  1. The back-end of our application does have some x86 SIMD accelerated code. We could likely start with a non-optimized version of this for M1 users, however it would be best if we could either add an equivalent implementation (NEON) or try out one of these other migration paths we’ve looked into.

OK - that’s indeed a tricky one.

  1. Our application also ships with a standalone copy of python, so that we’re able to run python extensions in a consistent environment across all machines. Exactly how this gets deployed, along with how it integrates with our C++ code, will need a pretty comprehensive upgrade in order to target M1.

I personally would just start getting a build working on an ARM and worry about things like fat binaries later. I am not sure it really is that hard as it sounds.

Anyway - much appreciate the openness about this.

cheers,
Torsten

1 Like

Thanks for your openness about the technical challenges. I am sure you can manage them.
We would be happy to participate in a private beta and give extensive feedback for using Saleae on Linux/ARM64.

1 Like