Can Intel Turn Things Around?

Introduction

Last week, Intel reported earnings of 20 billion in revenue, a new record. Leading up to that their CEO, Bob Swan, resigned and they rehired Pat Gelsinger. Pat was most recently the CEO of VMWare, but is well known within Intel from when he was the chief architect of the 80486 processor. The hope is that Gelsinger with his engineering background can turn Intel around. In this article, we’ll look at why with record revenue, people are saying Intel is in trouble. Then we’ll discuss what their prospects are.

Intel is all About the Process

My first job out of University was at Epic Data and the first thing they did was send me on a two week course at Intel down in Santa Clara on the then new 80186 processor which they were using as an embedded controller. In the course’s introduction, there was a bit of corporate propaganda where they discussed how the process technology that they used to build their chips was the core of the company and their competitive advantage. How having a better process technology for building chips was their number one priority and the foundation of everything they did.

Building chip foundries is expensive and few companies have the billions required to build new foundries with each new generation of chip technology. Intel had the resources to do this and many of their competitors fell by the wayside. There are only a few companies now creating CPU chips, but the model has changed where you can now design a chip and then have a third party manufacture it for you. AMD designs Intel compatible chips, but doesn’t manufacture them, it now contracts TSMC or Samsung to do that for them. Similarly for ARM chips and even nVidia GPUs.

This is where Intel has fallen down. Their transition from 14nm to 10nm technology (this is the size of transistors on the chip) ran into problems. Most Intel CPUs are still 14nm with a few of the newer ones finally coming out at 10nm. This then delays their next generation which will be 7nm for several years into the future.

Meanwhile, nearly all AMD CPUs are produced by TSMC at 7nm today. There are some differences between these, but Intel is only maintaining a performance lead by running hotter and using much larger amounts of power. At the sametime Apple is the first adopter of TSMC’s 5nm technology which is in the new Apple Silicon M1 chip and the newer iPad Air. Once TSMC meets Apple’s need for chips and brings more production capacity online, then AMD will go to the 5nm technology while Intel is still struggling with 10nm. By next year, TSMC will be on to 3nm technology and this will be used by AMD and all the ARM chips before Intel makes its transition to 7nm. Samsung is a bit behind TSMC, but well ahead of Intel and spending like mad to catch up and overtake TSMC. Suddenly instead of being the process leader, Intel is finding themselves several generations behind and even looking to TSMC to manufacture some of their chips. Meanwhile AMD is taking more and more market share away from Intel.

The smaller the transistor size, the more transistors you can put on a chip. For CPUs this means more CPU cores, better integrated GPUs, integrated AI cores, etc. Often this also reduces power utilization and increased speed due to shorter paths.

Brutal Competition

When IBM selected Intel as the CPU for their IBM PCs, they insisted that there was a second source for the CPUs, and so Intel was forced to grant a license to AMD to produce Intel compatible chips. This decision then created a huge competition between Intel and AMD to create the best x86 compatible chips. Each company kept leapfrogging the other with better designs and better processes. During this competition, there was a lot of interest in RISC processors which were simpler and it was believed that these would provide better performance than the Intel x86 CISC chips. There were Sun’s Sparc processors, IBM’s Power CPUs, MIPS and several others. In spite of all the theoretical advantages of RISC, the ferocious battle between Intel and AMD left them all in the dust. The PC market was large and profitable enough to provide both Intel and AMD with lots of money for R&D. The rewards of producing the best x86 chip were huge. By the time Intel launched the Core2 architectures, the x86 world was way ahead of the RISC world in computing power and at a far lower cost. The old Power, Sparc and MIPS processors are mostly memories now.

Power is the Game Changer

When Apple was looking to produce the iPod music player, they would have been happy to use familiar Intel chips, except that they ran the battery down too fast and Steve Jobs felt it would be useless as a result. Apple instead chose a small RISC chip that had been developed for a new version of the BBC Acorn computer. This chip wasn’t particularly powerful, but it didn’t use much power and was sufficient for a single use music player.

Acorn computer then spawned off the ARM chip as a separate entity that would design new versions of the chip. The resultant ARM Holdings never manufactured chips or even contracted others to manufacture chips. Instead it licensed its designs to companies like Apple to modify for their needs and to manufacture anyway they felt like. The success of the iPod was enough to fund R&D to produce more powerful ARM chips, like for the iPod Touch, then the iPhone and then the iPad. Once the iPhone forced all cell phones to be smart phones, everyone adopted the ARM processor for their mobile designs.

The main companies that produce ARM chips are Apple, Samsung, Qualcomm, MediaTek and Broadcom. Most of these are manufactured either by Samsung or TSMC.

Competition in the cell phone market is far more intense than the battle between Intel and AMD and we have history repeating itself where the cell phone manufacturers have put in huge investments to produce the best ARM chip for their flagship phone. We are now at a point where ARM chips are just as powerful as high end Intel or AMD chips but using only one tenth the power.

Using less power is a huge competitive advantage since:

• Saving electricity saves money, especially in data centers
• Using less power generates less heat and requires less cooling hardware
• Systems don’t have to slow down because they are overheating
• Laptops don’t require annoying fans

All of a sudden we see ARM chips entering the laptop, desktop and data center worlds where Intel is king. This is a huge threat to Intel and their market dominance in these spaces.

Follow the Money

Intel just reported revenue of 20 billion last quarter, which is pretty good and should provide lots of money for R&D. However, Apple just reported 111 billion last quarter and Samsung 59 billion and Qualcomm 6.5 billion. Intel may be huge, but the phone market is so huge that suddenly the industry that Intel dominates is small by comparison. Can Intel invest in the R&D necessary to compete? Meanwhile TSMC and Samsung aren’t even looking at Intel as they compete with each other for the best process technology. This is Intel’s big problem, that suddenly they find themselves in the same boat that Sun and IBM found themselves in with their Sparc and Power processors. Will they be able to overcome this challenge?

Intel’s Strategy

Pat Gelsinger hasn’t even officially started at Intel yet and he is already enticing various ex-Intel engineers that have either retired or moved on to other companies to return. He feels that Intel has gotten away from their engineering roots and has let key talent get away. The other thing Intel has been doing is going on a media blitz announcing future products that probably won’t appear for years, basically saying just wait a bit and we’ll have something for you in the future rather than buying AMD now (or switching to ARM). Hopefully once Pat officially assumes his new role next month, we’ll see some more concrete action plans on how Intel is going to proceed.

Summary

Intel is a powerful company that is making lots of money, however its products are getting old and it isn’t keeping up with the competition. At some point that is going to start affecting profits as loyal customers are forced to consider alternatives to stay competitive. Will reuniting the old team be enough to turn Intel around? I think more is required and everyone will be watching Intel closely over the next six months to see how they respond.

More Linux for Apple Silicon

Introduction

Last week, I covered Asahi Linux and their drive to port Linux to Apple’s new ARM based Macintoshes. This week, there was a new contender where Corellium, a virtualization and security company, have successfully gotten Ubuntu Linux running on Apple M1 ARM based systems. Corellium created a system to allow security researchers to run iOS in virtual machines to allow more rapid testing of Apps for security problems. No one had heard of Corellium until Apple sued them for copyright infringement for doing this. The lawsuit has mostly been thrown out and Corellium was able to use the knowledge they learned virtualizing iOS to produce Linux device drivers for the new Apple M1 chips.

Corellium Linux

Corellium starts with the Raspberry Pi version of Ubuntu Linux. This is a full complete 64-bit version of Linux that runs on the Raspberry Pi’s ARM processor and has all the development tools and applications bundled. They then add their Apple M1 Linux drivers to the kernel, rebuild it and replace the Raspberry Pi kernel. Viola, Ubuntu Linux on the new Apple Silicon Macs. All the source code is available in Github and the install instructions are available here.

To virtualize iOS, Corellium had to figure out all the hardware register accesses made by iOS, intercept them and translate them into matching calls in the operating system hosting the virtualized iOS. Accomplishing this was an impressive feat. We are lucky that the M1 SoC used in the new Macs is really just the next generation of the processor chips Apple has been using for all their iPhones and iPads (even AppleTV and iWatches). As a consequence, all the directly integrated devices like USB support are all the same. Corellium could then use all this hard fought knowledge to modify various Linux device drivers to work properly with Apple devices. It is still impressive that they were able to accomplish this in such a short time.

This version of Ubuntu Linux is fully GUI, but the graphics aren’t accelerated and no use of the M1’s fancy GPU cores are used. Basically they figured out how to get an area of memory that represents the screen and then use Linux’s builtin ability to deal with this simple sort of graphics (almost like going back to the days of VGA).

Corellium recommends creating your Linux image on an USB storage device and then gives instructions on how to get your Mac to boot from this. Then you are running Linux. We’re probably still a distance away from dual booting Linux or MacOS and you probably don’t want to replace MacOS entirely from your new Mac. 

This is a great starting point to getting Linux fully supported on the new Macs, it seems progress is moving really fast. Asahi Linux is making good progress in understanding and using the M1’s GPU. With such a full featured working system, progress is accelerating.

What Next?

When new hardware appears, Linux support starts in local specialty source code repositories, that is the case now with Corellium and Asahi. The source code is all new, rough and needs cleaning up. Once this is done it is submitted to upstream source code repositories where it is reviewed and eventually accepted. Eventually, this will all make it into the main Linux kernel source code repository. When this happens, all the myriad Linux distributions will get it for free as they incorporate a newer kernel into their downstream repos. This may sound like a long process, but typically it happens quite quickly. Then we can look forward to Apple Silicon versions of all our favorite Linux distributions.

Summary

Apple Silicon Macs have only been in people’s hands for a very short time. It’s amazing that we already have a working version of Ubuntu Linux for these devices. We have the Raspberry Pi to thank for taking ARM based Linux mainstream so quickly and groups like Corelium and Asahi to thank for figuring out the hardware nitty-gritty details of these new Macs. All this just makes the new products from Apple more exciting and a nice alternative to the Intel/AMD world.

All of this requires a good knowledge of ARM 64-bit Assembly Language, so consider my book as a great way to learn all the details on how it works. I even have a chapter on reverse engineering which is hopefully helpful.

Porting Linux to Apple Silicon

Introduction

When Apple announced they were switching from Intel to ARM CPUs, there was a worry that Apple would lock out installing non-Apple operating systems such as Linux. There is a new security processor that people worried would only allow MacOS to boot on these new chips. Fortunately, this proved to be false and the new ARM based Macintoshes fully support booting homebrew operating systems either from the SSD or from USB storage. However, the new Apple M1 chips present a number of problems that we’ll discuss in this article as well as why so many people are so interested in doing this.

Linus Torvalds, the father of Linux, recently said that he wished the new MacBooks ran Linux and that he would consider this the ultimate laptop and really want one. Linus said he saw porting Linux as possible, but personally he didn’t have the time to commit.

Last week’s article on an Assembly Language “Hello World” program hit number 1 on Hacker News and based on the comments, the interest was largely generated by the challenge of porting Linux to these new Apple systems. As we’ll see, doing this is going to require both reverse engineering and then writing ARM 64-bit Assembly Language code.

Asahi Linux

Last week we saw the announcement of the Asahi Linux project. Asahi means “rising sun” in Japanese and “asahi ringo” is Japanese for Macintosh Apple. The goal of this project is to develop a version of Linux that fully supports all the new hardware features of the Apple M1 chip including the GPU and USB-C ports. This won’t be easy because even though Apple doesn’t block you from doing this, they don’t help and they don’t provide any documentation on how the hardware works. People already have character based Linux booting and running on the Apple M1 Macs, and you can run the regular ARM version of Linux under virtualization on these new Macs, but the real goal is to understand the new hardware and have a version of Linux talking directly to the hardware that uses all the capabilities, like the GPU, to run as well as or better than MacOS.

GPUs and Linux

GPUs have always been a sore point with the Linux community. None of the GPU vendors properly document their hardware APIs to their products and believe the best way to support various operating systems is to provide precompiled binaries with no source code. Obviously this roils the open source community. GPUs are complicated and change a lot with each hardware generation. Newer Intel and AMD CPUs all have integrated graphics that have good open source drivers that at least will work, but at the disadvantage of not using all the fancy hardware you paid for in your expensive gaming PC. Even the Raspberry Pi versions of Linux use a binary Broadcom drive for the integrated GPU, rather than something open source.

Over the years, intrepid Linux developers have reverse engineered how all these GPUs work, so there are open source drivers for most nVidia and AMD GPUs. In fact, since neither nVidia or AMD support their hardware for all that long, if you have a more than 10 year old graphics card and run Linux, then you are pretty much forced to use the open source driver or switch to Intel integrated graphics (if available) or just stop upgrading the operating system and drivers.

The good news is that the open source community has a lot of experience figuring out how GPUs work, including those from nVidia, AMD, ARM and Broadcom. The bad news is that it takes time to first work out a disassembler of the GPU instructions to go from the binary form and work out what each bit means to produce a mnemonic Assembly Language source form. Then once this is known, write an Assembler for this and then use the tool to create the graphics driver. The Apple GPU isn’t entirely new, originally it was based on Imagination Technologies GPU design and then went through several iterations in iPads and iPhones before the current newest version ending up in the M1. Hopefully this history will be some help in developing the new Linux drivers.

Leveraging Existing Drivers

All the CPU vendors including ARM Holdings are motivated to contribute to the Linux kernel to ensure it runs well on their hardware. Linux is big enough that it greatly benefits vendors adoption to have a solid Linux offering. There is already really good ARM support in the Linux kernel and its tool chain such as GNU GCC. This is a solid first step in producing a working version of Linux for Apple Silicon.

Further, Apple doesn’t do everything themselves. There is hope that even if components are integrated into the M1 SoC that they still used standard designs. After all, Apple didn’t want to write all new drivers for MacOS. Hopefully a lot of the hardware drivers for the Intel Macs will just need to be recompiled for ARM and just work (or require very little work).

I haven’t mentioned the Apple integrated AI processor, but the hope here is that once the GPU is understood, that the AI processor is fairly similar, just missing the graphics specific parts and containing the same core vector processor.

There are quite a few other components in the SoC including sound processing and video decoding, hopefully these are known entities and not entirely new.

Why Do All This Work?

It’s hard enough writing device drivers when you have complete hardware documentation and can call a vendor’s support line. Having to reverse engineer how everything works first is a monumental task, so why are all these open source developers flocking to this task? Quite a few people like the challenge, if Apple provided lots of good documentation, then it would just be too easy. There is an attraction to having to connect hardware diagnostic equipment to your computer and iteratively write Assembly Language to figure out how to control things. None of this work is paid, besides the odd bit of gofundme money, these are mostly volunteers doing this in their spare time separate from their day jobs.

Humans are very curious creatures. Apple, by not providing any details, has piqued everyone’s curiosity. We don’t like being told no, you’re not allowed to know something. This just irritates us and perhaps we think there is something good being withheld from us.

There is also some fame to be had in hacker circles, as the people who solve the big problems are going to become legends in the Linux world.

Whatever the reason, we will all benefit from their hard work and determination. A well running Linux on Apple Silicon will be a great way to get full control of your hardware and escape App store restrictions and Apple’s policies on what you can and cannot do with your computer. It might even be a first step to producing Linux for iPhones and iPads which would be cool.

Summary

Apple has set a mythic challenge to hackers everywhere. By not providing any hardware documentation, Apple has created an epic contest for hackers to crack this nut and figure out how all the nitty gritty details of Apple Silicon work. This is a fun and difficult problem to work on. The kind of thing hackers love. I bet we are going to see prototype drivers and hardware details much faster than we think.

All of this requires a good knowledge of ARM 64-bit Assembly Language, so consider my book as a great way to learn all the details on how it works. I even have a chapter on reverse engineering which is hopefully helpful.

Apple M1 Assembly Language Hello World

Introduction

Last week, we talked about using a new Apple M1 based Macintosh as a development workstation and how installing Apple’s development system XCode also installed a large number of open source development tools including LLVM and make. This week, we’ll cover how to compile and run a simple command line ARM Assembly Language Hello World program.

Thanks to Alex vonBelow

My book “Programming with 64-Bit ARM Assembly Language” contains lots of sample self contained Assembly Language programs and a number of iOS and Android samples. The command line utilities are compiled for Linux using the GNU tool set. Alex vonBelow took all of these and modified them to work with the LLVM tool chain and to work within Apple’s development environment. He dealt with all the differences between Linux and MacOS/iOS as well. His version of the source code for my book, but modified for Apple M1 is available here:

https://github.com/below/HelloSilicon.

Differences Between MacOS and Linux

Both MacOS and Linux are based on Unix and are more similar than different. However there are a few differences of note:

• MacOS uses LLVM by default whereas Linux uses GNU GCC. This really just affects the command line arguments in the makefile for the purposes of this article. You can use LLVM on Linux and GCC should be available for Apple M1 shortly.
• The MacOS linker/loader doesn’t like doing relocations, so you need to use the ADR rather than LDR instruction to load addresses. You could use ADR in Linux and if you do this it will work in both.
• The Unix API calls are nearly the same, the difference is that Linux redid the function numbers when they went to 64-bit, but MacOS kept the function numbers the same. In the 32-bit world they were the same, but now they are all different.
• When calling a Linux service the function number goes in X16 rather than X8.
• Linux installs the various libraries and includes files under /usr/lib and /usr/include, so they are easy to find and use. When you install XCode, it installs SDKs for MacOS, iOS, iPadOS, iWatchOS, etc. with the option of installing lots for versions. The paths to the libs and includes are rather complicated and you need a tool to find them.
• In MacOS the program must start on a 64-bit boundary, hence the listing has an “.align 2” directive near top.
• In MacOS you need to link in the System library even if you don’t make a system call from it or you get a linker error. This sample Hello World program uses software interrupts to make the system calls rather than the API in the System library and so shouldn’t need to link to it.
• In MacOS the default entry point is _main whereas in Linux it is _start. This is changed via a command line argument to the linker.

Hello World Assembly File

Below is the simple Assembly Language program to print out “Hello World” in a terminal window. For all the gory details on these instructions and the architecture of the ARM processor, check out my book.

//
// Assembler program to print "Hello World!"
// to stdout.
//
// X0-X2 - parameters to linux function services
// X16 - linux function number
//
.global _start             // Provide program starting address to linker
.align 2

// Setup the parameters to print hello world
// and then call Linux to do it.

_start: mov X0, #1     // 1 = StdOut
        adr X1, helloworld // string to print
        mov X2, #13     // length of our string
        mov X16, #4     // MacOS write system call
        svc 0     // Call linux to output the string

// Setup the parameters to exit the program
// and then call Linux to do it.

        mov     X0, #0      // Use 0 return code
        mov     X16, #1     // Service command code 1 terminates this program
        svc     0           // Call MacOS to terminate the program

helloworld:      .ascii  "Hello World!\n"

Makefile

Here is the makefile, the command to assemble the source code is simple, then the command to link is a bit more complicated.

HelloWorld: HelloWorld.o
     ld -macosx_version_min 11.0.0 -o HelloWorld HelloWorld.o -lSystem -syslibroot
             `xcrun -sdk macosx --show-sdk-path` -e _start -arch arm64 

HelloWorld.o: HelloWorld.s
     as -o HelloWorld.o HelloWorld.s

The xcrun command is Apple’s command to run or find the various SDKs. Here is a sample of running it:

stephensmith@Stephens-MacBook-Air-2 ~ % xcrun -sdk macosx –show-sdk-path
objc[42012]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x1edb5b8f0) and ?? (0x122dd02b8). One of the two will be used. Which one is undefined.
objc[42012]: Class AMSupportURLSession is implemented in both ?? (0x1edb5b940) and ?? (0x122dd0308). One of the two will be used. Which one is undefined.
objc[42013]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x1edb5b8f0) and ?? (0x1141942b8). One of the two will be used. Which one is undefined.
objc[42013]: Class AMSupportURLSession is implemented in both ?? (0x1edb5b940) and ?? (0x114194308). One of the two will be used. Which one is undefined.
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk
stephensmith@Stephens-MacBook-Air-2 ~ %

After the ugly warnings from Objective-C, the path to the MacOS SDK is displayed.

Now we can compile and run our program.

stephensmith@Stephens-MacBook-Air-2 Chapter 1 % make -B
as -o HelloWorld.o HelloWorld.s
objc[42104]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x1edb5b8f0) and ?? (0x1145342b8). One of the two will be used. Which one is undefined.
objc[42104]: Class AMSupportURLSession is implemented in both ?? (0x1edb5b940) and ?? (0x114534308). One of the two will be used. Which one is undefined.
ld -macosx_version_min 11.0.0 -o HelloWorld HelloWorld.o -lSystem -syslibroot `xcrun -sdk macosx –show-sdk-path` -e _start -arch arm64 
stephensmith@Stephens-MacBook-Air-2 Chapter 1 % ./HelloWorld 
Hello World!
stephensmith@Stephens-MacBook-Air-2 Chapter 1 %

Summary

The new Apple M1 Macintoshes are running ARM processors as part of all that Apple Silicon and you can run standard ARM 64-bit Assembly Language. LLVM is a standard open source development tool which contains an Assembler that is similar to the GNU Assembler. Programming MacOS is similar to Linux since both are based on Unix and if you are familiar with Linux, most of your knowledge is directly applicable.

Apple M1 as a Development Workstation

Introduction

I’ve been playing with my new M1 based Apple MacBook Air for a few weeks now, so I thought I’d blog about how it is as a development machine. These are now the best way to develop iOS Apps for iPhones and iPads. These systems are really new so there are a few missing pieces, but these are filling in fast. You can run most MacOS Intel based programs using Rosetta 2, but I’m interested in what runs in natively compiled ARM code that ideally uses the builtin M1 functionality where appropriate.

XCode

XCode is Apple’s IDE for development. The whole XCode system is a combination of Apple created software along with a number of open source development tools. As long as you don’t compile or debug for Intel, you don’t need Rosetta installed to run all these. That means besides XCode and Swift, you also get natively compiled versions of LLVM, Python and a number of other tools. After installing XCode (which is huge), you can run command line tools to compile C code and Assembly language code. There is a version of make installed and you can do this all from a command shell without using the XCode IDE at all. All these tools are very fast and seem to work perfectly in the native ARM environment. This shouldn’t be too much of a surprise as these have all been working fine on the ARM based Raspberry Pi for quite a few years now.

If you develop iOS or MacOS applications using Cocoa then this is the platform for you. On older Intel based Macs, to test the application the computer had to emulate the ARM processor and the iOS simulators were quite slow and clunky. Now that everything is using the same processor, suddenly the iPhone and iOS simulators are fast and much more productive. In fact currently the M1 processor is faster than any existing iPhone or iPads, so iOS apps actually run fastest on the new Macs.

What’s Missing?

Apple has fully embraced the LLVM open source toolchain and helped have that project fully support the new Macs. Sadly they didn’t provide the same level of help to the GNU GCC open source toolchain. There are now test builds of the GNU toolchain, or you can build it yourself, but not a released one yet. This then slowed down the development of any applications that depend on the GNU toolchain. The most notable case is anything written in Fortran was stalled because GNU has the good Fortran compiler.

Now you might ask, so what? Who uses Fortran these days anyway? The thing is nearly all scientific libraries were written in the 60s and 70s in Fortran and have all been made open source. These libraries are highly reliable and work great. Now you might ask, so what? Not many people do scientific computing? The thing is that all modern machine learning and AI applications make extensive use of these libraries especially for things like linear algebra. This means that even though Python itself is available natively for the Apple M1, all the scientific libraries, most notably numpy are not as they contain Fortran components. Again there are test builds available, but it could be a few months before these are all generally available.

Another problem is the Apple M1 GPU and machine learning accelerator components. Even once these all compile and are available for the M1, which should be soon, it may be considerably longer before versions are available that can make use of the GPU or TPU for vector acceleration. Most of these libraries have support for nVidia and AMD GPUs, however now that Apple has gone their own way, it may be a bit of a wait for Apple versions. Apple has allocated engineers to help with these projects so hopefully it is sooner than later, and any project that previously supported acceleration on an iPhone or iPad will be good to go.

Meanwhile if you use some other programming language or system, like say ERLang, you will have to check their website for native availability, compile them yourself or use Rosetta 2.

The new XCode is great for Apple mobile development, but what about Android? Android Studio is currently being ported to the M1 and there are test builds available, but with lots of missing pieces. Once complete, this will be the best way to develop Android applications since again, you can run the apps natively and don’t require an ARM emulator for testing and debugging.

Summary

Whenever a new generation of hardware is released, there is always a delay as software catches up. If you do a lot of development for iOS then you need one of these new Macs as these are now the best environment for mobile development. Once Android Studio finishes their M1 version, the new Apple M1’s will be by far the best platform for mobile development. Apple has done a really good job of having so much work at release for their new generation of Macintosh computers; but, as is always the case at the bleeding edge, there are a few holes to be filled in. Of course most of these projects are open source so if you need them, you can always contribute to help them move a little faster. As more and more M1 based Macs ship and get into people’s hands these problems will start to be knocked off and more things will move into the “it just works” category.