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

Posted:
in General Discussion edited November 2020
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
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
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.
dewme
«1

Comments

  • Reply 1 of 30
    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. 
    SpamSandwichrandominternetpersondm3williamlondonanonconformistprismatics
  • Reply 2 of 30
    crowleycrowley Posts: 10,254member
    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.
    edited November 2020 dewmeOfermacpluspluselijahgmuthuk_vanalingammwhite
  • Reply 3 of 30
    Great article.  Thanks for pulling together these perspectives from various interviews/blog posts.
    d_2watto_cobra
  • Reply 4 of 30
    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.
    docno42watto_cobra
  • Reply 5 of 30
    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.
    dm3williamlondonuraharaanonconformistprismaticsDeelron
  • Reply 6 of 30
    I'm not sure you talked to that wide of an array of users if you didn't find any that are concerned about this transition.

    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.
    edited November 2020 viclauyycelijahg
  • Reply 7 of 30
    roakeroake Posts: 784member
    I’m curious how Parallels will do on Apple Silicon.
    watto_cobra
  • Reply 8 of 30
    dewmedewme Posts: 4,314member
    Wgkrueger said:
    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.
    I respectfully disagree with your broad brush assertion regarding coding practice in this case. You are mistaking the general principle of not relying on behavioral observations, i.e., observations made in isolation to infer general behaviors, to using fully sanctioned APIs provided on a specific platform, ones that may very well have platform specific limitations. In this case these functions are calling APIs that are (ultimately) exposed by the kernel to allow callers to perform time interval related calculations. Functions that ultimately result in kernel calls are by definition dependent on the underlying hardware and the hardware dependencies and limitations should be documented and well known to the caller. 

    If you need to determine a nanosecond level time interval on a Mac, using an API like the one noted is perfectly fine as long as you provide accommodations that address the limitations associated with the API call. In this case you’d have to deal with overflow/rollover and what happens during processor sleep states. If you know that an API call is processor specific and you know that your app may run on multiple platforms, each of which has known dependencies and limitations, you would certainly write your code so it provides an abstraction around a set of processor specific kernel functions that are platform specific, but ultimately your code must still resolve down to kernel API calls that are bound to specific hardware implementations. This has nothing at all to do with coding best practices - at some point you (or the kernel is on your behalf) are touching the metal/hardware and you don’t have any abstractions available to you. None.

    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. 
    edited November 2020 elijahgmuthuk_vanalingam
  • Reply 9 of 30
    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.
    Actually, there are discussions like this on Apple's developer forum.  
    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. 
    randominternetpersonmacplusplusanonconformistwatto_cobra
  • Reply 10 of 30
    crowleycrowley Posts: 10,254member
    techconc said:
    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.
    Actually, there are discussions like this on Apple's developer forum.  
    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. 
    That's probably for the developer to say.  In any case, using mach_absolute_time() seems like a reasonable thing to do that Apple Developer Relations are happy to recommend.
  • Reply 11 of 30
    mjtomlinmjtomlin Posts: 2,572member
    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.

    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.


    roake said:
    I’m curious how Parallels will do on Apple Silicon.

    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.
    edited November 2020 watto_cobra
  • Reply 12 of 30
    mjtomlinmjtomlin Posts: 2,572member

    tomahawk said:
    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....

    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.
    watto_cobra
  • Reply 13 of 30
    dewmedewme Posts: 4,314member
    crowley said:
    techconc said:
    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.
    Actually, there are discussions like this on Apple's developer forum.  
    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. 
    That's probably for the developer to say.  In any case, using mach_absolute_time() seems like a reasonable thing to do that Apple Developer Relations are happy to recommend.
    In fact, Apple has provided specific guidance around the issues related to the use of mach_absolute_time() function because of its known dependencies on processor architecture. 

    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.
    edited November 2020 macplusplusanonconformistwatto_cobra
  • Reply 14 of 30
    If that code snippet is a good example of where developers have to "change their thinking" then that speaks volumes for how easy this migration will be in practice.  Literally that code requires one change: swapping in one procedure call for another.  Presumably this is well documented in the release notes as things the developers need to look out for.  Namely something like "With Intel every 'tick' was a nanosecond; with Apple Silicon that's not the case, so use ... in place of ... if you are looking for nanosecond timing."

    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.
    watto_cobra
  • Reply 15 of 30
    asdasdasdasd Posts: 5,685member
    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. 
    You are right. They did mention that particular issue in the WWDC sessions on silicon Mac development anyway. 
    randominternetperson
  • Reply 16 of 30
    dewmedewme Posts: 4,314member
    If that code snippet is a good example of where developers have to "change their thinking" then that speaks volumes for how easy this migration will be in practice.  Literally that code requires one change: swapping in one procedure call for another.  Presumably this is well documented in the release notes as things the developers need to look out for.  Namely something like "With Intel every 'tick' was a nanosecond; with Apple Silicon that's not the case, so use ... in place of ... if you are looking for nanosecond timing."

    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.
    I agree with your line of reasoning. The only thing I'd add is that some platforms, for example Windows, do provide a little "scaffolding" around system functions that allow the caller to implement compensation for architectural differences on their own. Basically, this comes down to the platform providing a way (API) for the caller to ask the platform "What is the tick timing reference on the system I am running on now?" so the caller can adapt to the platform specific nuances on the fly. But like Crowley said, this scaffolding may not even exist if the platform code never had a need to know about these kind of issues because the platform was always the same and always predictable.

    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.
  • Reply 17 of 30
    asdasdasdasd Posts: 5,685member
    There’s plenty of ways to get the time at higher level abstractions using the Date or TimeInterval classes and the only downside is that a change in the settings or locale could result in a negative time elapsed. It depends on how likely you think that is. 

    randominternetperson
  • Reply 18 of 30
    mattinozmattinoz Posts: 1,877member
    I know Appleinsider is a fairly general user oriented site but could you not have found more production software developers to talk to.
    Even if it isn't my field I think the experience of a developer making a big multi-headed piece of business software would be a better indication of how the software we use to generate income might fair in the transistion?

    These developers make apps that are useful and interesting but if they don't work it's not going to stop us buying.
    Pascalxx
  • Reply 19 of 30
    While I am as excited as anybody for Nov '10, I don't think I will be spending any of my own money on it at least till 2nd gen of these products are out. But, if my employer wants to spend money on it...:D
    seanjwatto_cobra
  • Reply 20 of 30
    GeorgeBMacGeorgeBMac Posts: 11,421member
    This brings back nightmarish memories of one of my projects:   My company had just taken over another computer company who had hired contractors to convert an ATM application from Tandem computers  to IBM.   They had used programmed, automated functions to convert the code rather than doing it by hand.

    The application had just gone into production when my company took everything over and fired the half dozen people responsible and handed it all to me.   It ran nightly doing the accounting for tens of thousands of ATM transaction -- and it blew up several times a week.   It was a disaster in progress.  

    I had been assigned a temporary supervisor who knew nothing about applications and instead spent his time harassing me instead of supporting me -- while I was working day and night 70-80 hours a week to keep the monster going.   Meanwhile I was telling executives at my company that this thing was on the edge of a cliff and it was inevitable that something really bad was going to happen and things needed to change -- i simply couldn't keep that monster going by myself.

    Then one Friday night after getting back from Detroit (where the application was running) quite exhausted and looking forward to an evening off the thing blew up again as I landed at the airport.   So, instead of going home I went to my office where I was working to get it up and running again when the supervisor called giving me a hard time.  I dropped the phone and put my fist through a wall giving myself a compound fracture in my hand (where the bone poked through my skin).   But regardless, i continued working with one hand and resolved the problem.

    Shortly after I had surgery on my hand to repair the break the company executives stepped in, fired the supervisor and hired 7 people to my place.  I never heard another word about that application -- and that was a good thing.

    Hopefully Apple's transitions go a bit more smoothly.
    randominternetperson
Sign In or Register to comment.