Developers on who can move to Apple Silicon - and who should wait
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.
Tim Cook says Apple Silicon will take the Mac to the next level
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.
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.
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
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.
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."
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)
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."
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
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.
Tim Cook says Apple Silicon will take the Mac to the next level
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
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)
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
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.
Comments
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.
As a home consumer, sure, it should be great. As a professional, I have a number of concerns that I suspect will mean we have to move away from Macs in a number of use cases.
- Bootcamp - One of the major advantages to Macs for our needs are that we can run Windows on them as well. I have by Bootcamp partition running in VMWare Fusion about 95% of the time to access Windows only tools.
- Scientific software - I support a research department at a university. We have a lot of macOS because we can easily compile and run a LOT of scientific software. A lot of that software is dependent on OpenGL, which Apple had already deprecated. I fully expect that this was simply so Apple didn't have to migrate it to Apple Silicon. This alone may push a lot of our users toward Windows, where we now can run a full on Linux layer. We may be able to get around this with virtualization and running Linux on the new Macs, we'll need to test, but it won't be nearly as convenient as running the software directly within macOS.
I'm hoping the updated 16" MBP that may be announced next week will still be an Intel processor. I'll likely buy that machine for myself so that I have at least a few years before I need to worry about no longer having Bootcamp and hope new options become available.I think the code examples above are provided as representative of the kinds of hardware and platform level dependencies and limitations that are inevitable when porting from one architecture to another architecture. These kinds of issues will ALWAYS arise in these situations because at some point in the software stack you no longer have any more abstraction cards to play. I wouldn’t make any claims whatsoever about the quality of code that was provided as an example of situations where underlying platform affects the behavior of system functions.
https://developer.apple.com/forums/thread/12135
It's hard to tell what the developer was trying to do with that code snippet, but most would agree CFAbsoluteTimeGetCurrent() should be used. I've used this with a benchmark application I was working on.
Somewhat agree and simply sticking an SoC with A14X-like performance basically gets even the lowliest ASi MacBook close to a high end Intel MacBook. But I think the boxes for "Notebooks" and "Desktops" represent more of a median range.
Parallels running a virtual arm64 machine or running an emulated x64 machine? Emulation will take huge performance hit, but I think it will still be fairly adequate for most basic tasks and applications.
You can still use your current Mac if you need x86. Don't see how that prevents you from buying an Apple Silicon Mac?
My web server is running OpenBSD in vmWare on a Mac mini and will continue to do so even if I buy an Apple Silicon Mac.
https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code
As you can see, this is only one of several issues or "gotchas" that need to be addressed when porting apps to support Apple Silicon. This is to be expected and especially for date, time, and timer related functionality, which is notorious for being heavily dependent on underlying hardware and sometime OS architecture. I have seen at least a half dozen different time/date functions and data types that define a different date and time for what they consider the beginning of date and time, i.e., the zero reference.
Thankfully, Apple has already done a lot of the heavy lifting to identify, and in some cases, provide compensation for hiding architectural issues that app developers will encounter as part of Apple's development of iOS and iPadOS. There should be no concerns about endian issues, integer sizes, string termination, etc. This bodes well for applications that use the APIs that Apple provides. There will still be challenges for developers who are writing lower level code like system extensions and using compiled third party libraries but the vast majority of apps should have a fairly straightforward and deterministic path to follow to get onboard Apple Silicon Macs.
The reminds me of the transition from pixels to points, or whatever it was, when Apple introduced resolution-independent UI design in advance of the double-resolution retina displays. Apple, in my limited experience as a one-time iOS developer, does a really nice job of making developers away of these types of changes they need to incorporate. It's work, but it's manageable, understandable work.
Software that exists over a long period of time always has to deal with these kinds of chicken & egg problems in addition to having to deal with moving target issues. It's the nature of the beast and why we have to be somewhat tolerant of the lack of perfection in all things that have software dependencies - and be willing to compromise to get stuff to work.