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.
- 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.
- 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.
- 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.
- 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