TurboActivate for macOS ARM64?Solved

Yes, when production Arm64 macOS machines start shipping well have a fully tested version available.

Hello,

Is there (at least in beta) a version of TurboActivate for Apple Silicon ?
Did Wyday invested in Developer Transition Kit to do so ?

Indeed, we're in the sam situation of John, where we can port an application to Apple Silicon but we're missing TurboActivate library.

Thank you. Philippe

We don’t develop for pre-production hardware. Never have, never will.

The good news is that we already support arm64 builds for Windows and Linux. Meaning making arm64 builds for macOS will be trivial. Most of the effort will be on testing.

We’re getting some production model arm64 macs late November, and we’ll have fully tested builds out early December.

Hello,

Thank you for your answer.
I don't share your opinion about developer-kits (that is not pre-production hardware at all), but you may have your reasons. We own a DTK and it's very good. I guess Apple will give a discount on a full machine when returning it (as they did when transitioning to Intel CPU).

Anyway, if the Apple Silicon version of TA is coming a few weeks after the release of these new machines, it's good. If it's after a few months, it's bad.

Keep up with your good work. Philippe

I agree with Philippe here, too.  I'm not sure why you would skip applying for the Developer Kit from Apple here.  It does not make too much sense — by the time the Developer Kit comes around Apple is done with the majority of its work for releasing to production.  Yes, there are kinks they have to work around, but it lets third-party developers build on their platform.

You have MANY customers that depend on your libraries to protect their intellectual property.  We happily pay you and your team for the excellent product you ship.  However, when the platform makers decide to move forward it's important to listen.  Apple may not be well liked by the developer community — and I understand that — but they sell MANY machines around the world.

I have a great deal of respect for the work that you all do at WyDay, and so understanding your rationale to wait for production machines would be beneficial.  Can you give insights as to why you wouldn't develop using Apple's Developer Kit especially as they announced that their chipset would be transitioning to arm64?

Thanks for your time.

—Arie

I have a great deal of respect for the work that you all do at WyDay, and so understanding your rationale to wait for production machines would be beneficial.  Can you give insights as to why you wouldn't develop using Apple's Developer Kit especially as they announced that their chipset would be transitioning to arm64?

Because the compilation step for TurboActivate / TurboFloat / TurboFloat Server for ARM64 macOS takes several minutes. Why? Because we already optimize our software for x86, x64, ARM64 (and a handful of other architectures).

Yes, Apple has released an ARM64 machine. This is new for them. This is not new for other OSs. Windows did it several years ago. Linux did it several years before that. And we've been targeting these "embedded" platforms for years.

My point is building our products for our machines is not the time consuming part. We already have a ton of experience doing it.

So, why wait for the "production" machine? Because that's where the rubber meets the road. The chip differences alone between the "dev kits" and the production machines was reason enough to wait. To say nothing of working around bugs in a beta OS for a new architecture.

To sum up: we have a certain number of employees with a finite amount of time. It's a bad use of our resources to do extensive testing on beta hardware running a beta OS. Why? Because we'd have to extensive testing on production hardware on the production OS anyway before we felt confident to release the versions to the public.

Us not getting test machines didn't slow anything down because we'd still wait until we tested everything thoroughly on production machines.

Thank you Wyatt, I understand your rationale.  As far as you know, will your latest builds of the TurboActivate an TurboFloat libraries build so that they function properly on Big Sur as of today?

Yes.

Any update on how close this is now? I have actual customers with M1 Macs now who are unable to use my product. The rest of my product is written in Java, so TA is the obstacle. Any ETA you can provide is very much appreciated so I have something in turn that I can share with my users. Thanks!

ASAP. This week if testing completes successfully. Next week if not.

That's great! Thanks for the update. And now for a somewhat dumb question most likely. Right now my app is being run in Rosetta 2. Will this explain how to use the correct shared lib for both 100% native and when running in Rosetta? Or will it just be the same thing?

Like we did with PPC processors (back when those were still a thing) we're releasing universal binaries. That is, the binaries work "natively" on both Intel 64-bit and ARM64 processors.

Your app will be able to link these.

If you're using Java you'll be stuck with using the Intel 64-bit code until JNA gets around to building support for ARM64.

Thanks, Wyatt. Nice work! The good news is that I've confirmed on my own M1 Mac Mini that my app works just fine under Rosetta 2, and it actually seems quite snappy. JetBrains is actively working on getting all of their apps--including their Java runtime and JNI--running natively on the M1. Once they've completed that work hopefully I'll be able to release a 100% native M1 version of my app leveraging the work that you and JetBrains have done.

FYI, JetBrains released an EAP of their native ARM/M1 support and I just tested my plugin with the latest TA distribution. Everything's working perfectly so far, so kudos to both this team and the one at JetBrains for turning around updates so quickly!

No problem, Scott.