Affiliate Disclosure
If you buy through our links, we may get a commission. Read our ethics policy.

Developers on who can move to Apple Silicon - and who should wait

Tim Cook says Apple Silicon will take the Mac to the next level

Last updated

It's the biggest change to the Mac since the move to Intel, and it comes on top of the biggest change to macOS since OS X. Apple Silicon and macOS Big Sur are going to work, but it will take time.

Apple makes it sound very easy for everyone to move to using macOS Big Sur on the forthcoming Apple Silicon Macs. In fairness, Apple has also actually made it very easy — with Rosetta 2, with the developer transition kit, and with all the resources it can offer.

There's no question that Apple Silicon will work and that's actually a remarkable thing. Apple is replacing the very core of the Mac and they've convinced us all that they're going to do it seamlessly.

Yet as deep as the change goes into the heart of the Mac, the effects of that also go extremely wide. As well as every app and utility that every user has, it also affects every piece of hardware that plugs in to every Mac.

Although all developers and all users that AppleInsider asked are positive and looking forward to Apple Silicon, that doesn't mean they plan to switch on day one. There are issues which are small enough that you can expect them to be addressed, but not necessarily immediately.

Ready and waiting for Apple Silicon

One developer that is typical of the attitude to macOS Big Sur on Apple Silicon is the Omni Group. Maker of OmniFocus, OmniOutliner, and more, it has been developing software applications since the days of Steve Jobs's NeXT company.

Consequently its apps have decades of work in them, which means potentially very old code — which certainly leverages every nook and cranny of macOS. Yet Ken Case, CEO, is entirely positive.

"Yes, our apps do have pretty deep roots!" says Case. "As a long-time Apple developer, there's nothing about switching over to Apple Silicon which concerns me— in fact, I'm really, really looking forward to it."

"This transition is in some ways much easier than many of Apple's earlier transitions (PowerPC, Intel, 64-bit, etc.), because in this case most of our app logic has already been running on Apple Silicon (in our iPhone and iPad apps)," he continues.

"So as Mac transitions over to Apple Silicon, we're building apps for an architecture that's already familiar [and] using a toolset that's already familiar," says Case.

Apple Silicon and Big Sur security

At the opposite end of a quite short spectrum is Mike Bombich, creator of backup app Carbon Copy Cloner (CCC). Ultimately, he says in a new blog post, he is "really stoked" and "optimistic" about Big Sur on Apple Silicon, but early users of any backup app are coming up against a new move by Apple.

From Big Sur onwards, macOS itself is installed on a Signed System Volume. No one but Apple can copy the system, so at first it appears that no one can make a bootable backup. According to Bombich, you can install Big Sur on an external volume and then back up to it, but that is one more thing to know about.

And it comes on the heels of the T2 security processor, which for a couple of years now has prevented Macs being booted from any external drives. There's a way around that, but again it takes preparation in advance, it's not a problem you want to find when things have gone wrong.

In the case of Carbon Copy Cloner, though, work now is ultimately going to be worthwhile because of the difference the new OS and the new architecture should make in the future.

"Our solution is tied so closely to the logistics of the startup process," writes Bombich, "[that we]spend about a quarter to a half of our year just making CCC work with the next year's OS."

Craig Federighi introducing Apple Silicon Craig Federighi introducing Apple Silicon

With Big Sur, Bombich expects that there will come a "perfect division of responsibility," between Apple protecting the Mac's startup volume, and CCC being able to concentrate on backing up data.

Emulation and universal binaries

It's specific details like this that are giving concerns to developers, although again none expect problems to persist. Sergey Krivoblotsky, software developer at MacPaw, told AppleInsider that he is worried about how developers may be using third-party tools or libraries.

Apple's documented advice is that "if your project depends on any third-party libraries, contact the original vendors" and get them to produce Universal Binaries, or versions that will work with Apple Silicon. "You cannot produce a universal version of your binary without universal versions of all linked libraries," continues Apple.

Krivoblotsky is also a little wary of how Intel-based apps may be slowed down when running under Rosetta 2 emulation. "I remember Rosetta 1," he says, "and it wasn't always the best experience."

"[Plus] new technologies use previous experience and fix some of the old bugs but at the same time they create new, often unexpected, ones," he continues. "And only the official release of ARM-based macs will show how stable they are."

Code-level changes in Apple Silicon

Apple makes it sound as if you can run your old Intel apps just fine under emulation, or you can quickly recompile them to work directly on Apple Silicon. This is all true, but if it means old code can be recompiled for the new platform, it can still mean that the thinking behind that code may need to change.

Serhiy Butenko, software engineer on CleanMyMac X, sent us an example of an unexpected issue that was affecting coding. "On Apple Silicon, you need to request the absolute time in a different way [to Intel]," he says.

Top: app code in Catalina. Bottom: the same code in Big Sur. It's not just about recompiling, it can be about rethinking. (Source: MacPaw) Top: app code in Catalina. Bottom: the same code in Big Sur. It's not just about recompiling, it can be about rethinking. (Source: MacPaw)

Big Sur on Apple Silicon will take a request for time from an app and return it a numeric value counted in what are called ticks. "It has so happened on Intel processors that 1 tick equals 1 nanosecond," continues Butenko. "Everyone has used this method and it's been OK because there have only been the Intel processors. Then Apple Silicon appeared and 1 tick no longer equals 1 nanosecond, so it's not clear what the result will be."

MacPaw developer Serhiy Buchnev, agrees that "sure, there will be some difficulties during transition," and also that Rosetta 2 will have some issues. "But I think this difficulties are worth it. Developers in the Apple ecosystem have already passed through similar transformation back in the days during the transition from PPC to Intel and it was done pretty smoothly."

User demand for Apple Silicon hardware

The presumption is that Apple Silicon Macs will be faster than Intel ones. "When we make bold changes," said Tim Cook at the announcement, "it's for one simple and powerful reason. [It's] so we can make much better products."

Doubtlessly, every Apple user, most especially pro ones whose work depends on Macs, wants faster machines. However, for those who need speed the most, they also need total reliability.

Nobody expects Apple Silicon Macs to go wrong, but of the different users AppleInsider talked with, one was certain that they would not be committing to the new machines right away.

Musicians. It used to be that musicians were drawn to Apple gear because PCs famously added latency problems, so keeping instruments in sync would be an issue.

Faster Macs should help ensure that's still true, that Apple performs well for musicians, but they're not just dependent on Apple. None of the major music hardware developers were willing to discuss future plans, but their hardware depends on drivers for Macs and these will all have to be tested.

The prevailing attitude amongst musicians is that they'll let these manufacturers do the testing, they won't unbox an Apple Silicon Mac and bring it out on stage just yet.

Apple's expectation for Apple Silicon performance Apple's expectation for Apple Silicon performance

Optimism for the future

So there are issues, that there will be a transition period for users, developers, and hardware manufacturers as well as for Apple. Again, though, every person we spoke with fully expects Apple Silicon to be good for their business.

That is partly because of how faster Macs can be expected to sell better, but it's also because of how Apple's moving to ARM processors is likely to make serious chip updates more frequent.

"[This will all mean] moving to a CPU platform whose roadmap has had strong year-over-year improvements for the past decade (unlike what we've seen on the Mac)," said the Omni Group's Ken Case.

"I might be a bit sad to lose compatibility with some older Mac software — although a lot of that already happened in Mojave and Catalina," he continues, "but I'm looking forward to gaining compatibility with a whole, much larger world of iOS apps that will already be available on day one."

We just don't know yet when Day One will actually be. However, that's surely something Apple is going to reveal at its November 10 event.

Keep up with AppleInsider by downloading the AppleInsider app for iOS, and follow us on YouTube, Twitter @appleinsider and Facebook for live, late-breaking coverage. You can also check out our official Instagram account for exclusive photos.



30 Comments

Wgkrueger 8 Years · 352 comments

Who writes code like that? Having code that depends on the specifics of the CPU like the CleanMyMac X example is the very definition of bad coding practices. How embarrassing for them. 

crowley 15 Years · 10431 comments

Wgkrueger said:
Who writes code like that? Having code that depends on the specifics of the CPU like the CleanMyMac X example is the very definition of bad coding practices. How embarrassing for them. 

Could I borrow your Coding Practices manual to see where it says that? And then maybe you could let the developers know what they should have done to fulfil the same function.

Moreover, it looks from the code snippet and explanation that the architecture is interpreting a request in a different way and returning a different result. How would the developer have know AppleSilicon would do that when they wrote the app years ago?

easy to be an armchair critic with the benefit of hindsight.

randominternetperson 8 Years · 3101 comments

Great article.  Thanks for pulling together these perspectives from various interviews/blog posts.

randominternetperson 8 Years · 3101 comments

You know what's interesting about that orginal Apple Silicon Power x Performance slide?  I'm sure it's not an accident that the "blue area" (that shows where Apple Silicon will appear) is entirely above the box for "Notebooks."  I read this as a commitment that every Apple Silicon Mac will at minimum match the performance of the fastest MacBook Pros currently sold.  That's a bold assertion.  I'm looking forward to hearing more about this next week.  It's possible that the slide is misleading in this way, but I doubt it.

Wgkrueger 8 Years · 352 comments

crowley said:
Wgkrueger said:
Who writes code like that? Having code that depends on the specifics of the CPU like the CleanMyMac X example is the very definition of bad coding practices. How embarrassing for them. 
I could I borrow your Coding Practices manual to see where it says that? And then maybe you could let the developers know what they should have done to fulfil the same function.

Moreover, it looks from the code snippet and explanation that the architecture is interpreting a request in a different way and returning a different result. How would the developer have know AppleSilicon would do that when they wrote the app years ago?

easy to be an armchair critic with the benefit of hindsight.

Nope, I have the benefit of having made those mistakes 25+ years ago and developed those good practices over time. I’m sure you can find any number of books on the subject ... if only there were a way to easily search for them. My main beef is not that they made the mistakes but characterized them as needing “rethinking” rather than an outright development mistake.