The past year has seen a significant change in things throughout the world. It has been almost a year since the entire world was turned upside down with Covid-19. One of the biggest changes that has been made is that many more users are working from home. This has included many people, like myself, taking their work laptops home in order to be able to work.
Quite often laptops are connected to a directory service, like Microsoft’s Active Directory, or LightWeight Directory Access Protocol, or LDAP. For many, when new devices are setup and configured, they are connected to Active Directory or LDAP. macOS can connect to an Active Directory domain. If you are physically in an office, then it is not a problem, it will always be connected. However, issues can arise when a device is connected remotely. I have run into an issue with my setup. It was originally configured while at the office, and it was connected to Active Directory. This has not been much of a problem, except for an issue that has only turned up since I have upgraded to macOS Big Sur. Before we get to the problem that I am experiencing, let me discuss the setup.
As mentioned, my work laptop is connected to an Active Directory domain. I connect to work by using a Virtual Private Network, or VPN. Once I am connected I have full access as if I was in the office. The VPN setup we use requires its own software to use, and I cannot connect using the native macOS VPN connection.
When the MacBook Pro was setup, it was configured to use a Mobile Account. This means that the network credentials can be used to login and be able to use the cached credentials when connecting to resources without needing to enter in the same credentials time and again. This configuration also allows me to use Touch ID on the MacBook Pro.
Along with being configured for a mobile account and active director, there are also two local administrator accounts, as a precaution. One that I know the password to off the top of my head, and the other I would have to look up, but I can look up if absolutely necessary.
When working from home, I typically use my 27-inch iMac for most of my work and my MacBook Pro is used for work-specific applications, like chat, email, and video conferencing. I have all of my favorite development tools on my iMac, so I prefer to use that; along with the larger screen size.
I have a Mac mini that sits at the office, which does not have the same issue, probably because it is always connected to the Active Directory domain. I am typically connected to the Mac mini when I am working, by using Screen Sharing. Now that we have discussed the setup, let us get to actual problem.
With each security update to macOS Big Sur I have run into an issue after upgrading. When the update finishes and the login screen shows, I attempt to log in to my account. But I get the following error: “This account has been locked. Please try again in 15 minutes”. This is on the first login attempt after upgrading.
The first time I got this, with the upgrade to macOS Big Sur 11.1, I was baffled, but after 15 minutes I was able to login. I noticed it, but was not too concerned. I experienced the same thing again when upgrading to macOS Big Sur 11.2. Again, it indicated my account was locked out for 15 minutes.
I recently upgraded to 11.2.1, and again the same thing issue occurred, albeit with a slight twist, and it was much worse. Instead of being 15 minutes, it was 30 minutes. As was the case in the past, I waited the necessary amount of time and attempted to login. Unlike the prior instances, my account would not login. After trying a couple more times, it indicated that my account was locked for an hour. Again, I waited the hour, attempted to login, but could not. I was able to find a workaround.
Since I could not login with my mobile account, I logged into one of the local administrator accounts, to verify that I could still login, and I could. I then connected to the office using the VPN. This was so that I could verify that it was an issue specific to the MacBook Pro and not my active directory account. The fact that I could login means that it was not an issue with my Active Directory account and this verified that the issue was definitely restricted to my MacBook Pro.
Since I was able to login using the local admin account, I then tried connecting my MacBook Pro to a hotspot to be able to try and connect via the VPN to be able to access resources. Unfortunately, this did not work. The routing just was not setup properly, and since the hotspot I was using was my iPhone, it would be quite difficult to setup a proxy and have everything work as expected.
On a whim, I tried to connect from my iMac to the MacBook Pro, using Screen Sharing, while I was logged into my local admin account. However, instead of using my local admin credentials to connect, I tried to use the mobile account credentials. Shockingly, they worked. It should be noted, that the login window still indicated that my account was locked.
Now, if you have used Screen Sharing before, once you have validated your credentials, whether they are local or in my case a mobile account, you are given two options. You can either “Share the Display” or “Login as yourself”. I opted to login as myself, in this case is the mobile account. Again, shockingly, this actually worked. I was logged in again to my Mobile Account, which is great. When I logged in, this disconnected the VPN connection on my local admin account.
At this point, I knew I was logged in, and that the account was working. I then logged into the MacBook Pro locally, and it was logged in. In order to verify that I would be able to login again, I closed the lid so that the laptop would sleep. I re-opened the lid, and guess what I saw. “This account is locked for 28 minutes”. Again, I waited 30 minutes, to give it a bit of extra time, and I was able to login without any issues. I repeated closing the lid, opening, and re-logging in two more times just to be sure. As of right now, it is working as expected. Even though I did find a work around, it is not something I would expect a normal user to be able to, nor have to, do in order to access their account. After doing some mulling on the issue, I have a notion as to what is happening.
What I think is happening
I think I have an idea as to what is happening. I think when macOS is performing its updates, it is logging back into the same user account that was logged in when the update was started, in my case my mobile account. When this login happens, I think one of the following situations is occurring.
The first possibility it is logging in and not waiting long enough to validate the credentials. The second possibility is that it is logging in with incorrect credentials and locking the account. The third possibility is that the credentials cannot be validated with the Active Directory server after a reboot, because it is not connected via the VPN, so it is locking the account due to trying to connect, but not being able to do so.
The fourth possibility is that macOS is just messing up and falsely indicating that the account is locked, when in fact it is not. In particular, the Login Window process thinks the account is locked and will not allow it to login. I suspect this may be a possibility because I was able to successfully login using Screen Sharing, which should not have been possible if the account was truly locked. Do not get me wrong, I am glad that I was able to login with Screen Sharing so that I could actually login properly.
If the mobile account was indeed locked and I was still able to login via Screen Sharing, then this would be a significant security issue. However, there may be an explanation for this. When I connected with my mobile account via Screen Sharing, I was connected to my office via the VPN using my local administrator account. Since the VPN was active, I think that it may have been able to authenticate with the Active Directory domain, which may have allowed me to login. Although, if the account was locked, it should not have allowed me to login.
I do not have a definite solution. However, I think the next time there is an update I may try logging out of the mobile account and using the local administrator account I have instead of using the mobile account and seeing if the mobile account is locked out again.
I am thinking that the root cause is the fact that it cannot connect to the Active Directory server. I think this because of the fact that I do not have any issues with the Mac mini when performing updates. The only difference is that the Mac mini is connected all of the time, whereas the MacBook Pro requires the VPN to connect the Active Directory server.
I am glad that I was able to find a way around the issue. However, I still suspect that the root cause is macOS Big Sur. There have been numerous other reports of this happening. Some are on JAMF, while there are other reports on the Apple Discussion forums, here, here, and here. It does appear as though all of the accounts are Active Directory accounts.
I hope that logging out of the mobile account and using the local admin account will fix the issue, but I will not be able to know for sure until I update to macOS 11.3, or 11.2.2. macOS 11.3 is currently in beta, and will likely be out sometime this spring. Regardless of this being a workaround, Apple needs to figure out how to work around this issue, particularly given that there will be an increasing number of people who are, and will continue to be, working from home.
Last week I posted about Apple’s Development Transition Kit (DTK), and how they were proving a $200 USD credit that expired at the end of May, 2021. There were some developers who were fine with what Apple offered, while there was a contingent who were a bit miffed at what Apple offered. On Friday, Apple sent an email that states:
Thanks again for participating in the Universal App Quick Start Program.
We heard your feedback regarding the 200 USD appreciation credit mentioned in our last email. Our intention was to recognize the tremendous effort that you have put into creating amazing universal apps. By partnering with us early, you showed your commitment to our platform and a willingness to be trailblazers.
So instead of the 200 USD credit that expires in May, we are giving you a 500 USD Apple credit and extending the time you can use it to get a new M1 Mac through the end of the year. If you already purchased a new M1 Mac, the Apple credit gives you the flexibility to purchase any Apple product to help with your app development work.
We’ll share details soon about how to ship the Developer Transition Kit (DTK) back to Apple. Note that the DTK will no longer receive publicly available software updates after macOS Big Sur 11.2. We encourage you to return it as soon as possible so that your development work is not interrupted. And once you return the DTK, you’ll receive your Apple credit.
Thank you again for making the Mac with M1 launch such a great success.
As I stated in my post
An alternative to providing an extension would be to extend the length of time that the code can be used. Maybe make it expire at the end of the year instead of the end of May. I am sure that some developers might still not end up using their code, but it would provide a bit more time for some developers to be able to purchase a machine
I am glad to see Apple extending the credit until the end of the year. Not everybody would have the means to purchase an M1 Mac prior to the end of May, depending on their business. Having it extended until the end of the year is definitely better. Honestly, I would have been fine with them just extending the amount, but I am not going to argue with $500 credit for those who had the DTK. In particular, for those whose DTKs stopped working after a few months and did not get any anywhere near the full usage of the devices.
What is even better though, is that if someone did purchase an M1 Mac already, then it can be used for other things to help with their development. I hope Apple ends up releasing a non-XDR monitor, but only time will tell if that actually happens or not.
It is not often that Apple makes the move from one type of architecture to another. For the Mac it has happened a total of three times. Motorola to Power PC in the early 90s, Power PC to Intel, in 2005, and now Intel to Apple Silicon; the last transition began last year with the release of the MacBook Air, Mac mini, and MacBook Pro with the M1 chip. In order to be able to make sure that the hardware and software was ready for users, Apple unveiled a program called the Universal App Quick Start Program. This program was announced on June 25th, 2020 at Apple’s World Wide Developer conference.
If a developer applied for, and was subsequently approved, they would be able to receive a Developer Transition Kit, or DTK, machine. The 2020 Developer Transition Kit has the form-factor of a Mac mini and has the follow specifications:
An 8 -core A12Z (the same processor as the 4th Generation iPad Pro)
16GB of RAM
Two USB-A ports
Two USB-C ports
One HDMI port
One Gigabit Ethernet port
802.11AC wireless networking
Bluetooth 5.0 connectivity
If you were an Apple Developer and you wanted to obtain one of these machines, you had to apply. If you were approved, you would be able to order one for $500. The program came with some stipulations. Some of these include:
The DTK is Apple’s property
The DTK would need to be returned to Apple.
The program was to last up to one year and Apple would let you know when you needed to return the machine. Apple has begun doing so. Many developers began receiving an email that states the following:
Thank you for participating in the Universal App Quick Start Program and your continued commitment to building great apps for Mac. Response to the new Macs has been incredible, and we love the fantastic experiences developers like you have already created for Mac users.
Now that the new MacBook Air, Mac mini, and MacBook Pro powered by M1 are available, it’ll soon be time to return the Developer Transition Kit (DTK) that was sent to you as part of the program. Please locate the original packaging for use in returning the DTK. We’ll email you in a few weeks with instructions for returning the DTK.
In appreciation of your participation in the program and to help with your continued development of Universal apps, you’ll receive a one-time use code for 200 USD* to use toward the purchase of a Mac with M1, upon confirmed return of the DTK. Until your program membership expires one year after your membership start date, you’ll have continued access to other program benefits, such as Technical Support Incidents and private discussion forums.
This $200 code has some stipulations. The first is that it can only be used towards an M1-based Mac. The second is that the code is only valid until May 31st, 2021.
With the previous transition from PowerPC to Intel, Apple also provided Developer Transition Kits to developers. At that time, when developers returned their machines, they received an iMac. I would not expect Apple to do the same thing this time, for a couple of reasons. The chief amongst these is that Apple is in a different situation this time. They have significantly more developers than before and likely have more 2020 Developer Transition Kits out in the world than in 2005. Secondly, Apple is not going to provide even a base model Mac mini for that price.
At no point did Apple indicate that there would be any sort of compensation for partaking in the program. However, precent did show that they had done it before. As we are all aware, that does not mean that what happened in the past will happen again.
Even with that though, there are a couple of issues as I see them. First, Apple made over $114 billion in revenue last quarter, and over $28 billion in profit. The $200 seems like a jab in the eye of developers, given how much profit that they made just last quarter. This is particularly true given that those who purchased the rental of the DTK helped Apple test and validate that the software and development tools were ready for production.
Second, many developers already purchased M1-based Macs. Having a one-time use code for $200 off of an M1-based Mac is not going to help them with their previous purchases. This means that either developers will end up purchasing another M1-mac, which starts at $700 for the base model Mac mini, or they will let the code expire. Neither of these provides any good will towards developers.
I think it would be great if Apple offered either $200 towards the purchase of an M1-based Mac or an extension to the Apple Developer program. I think this would make the most sense, because developers who already purchased an M1-based Mac would be able get some benefit without having to purchase another machine that they do not necessarily need. For individual developers that extension might be two years, and for enterprise developers it might just be for a year. Even though I like this idea, I do not see it happening. My reasoning for it not happening is the fact that the $200 towards the purchase of a new M1-based Mac only reduces the profits of Apple, but the cost of the machine is still covered. If Apple opted to give an extension, then that is services revenue that they would end up forgoing entirely, instead of just having a bit less profit overall.
An alternative to providing an extension would be to extend the length of time that the code can be used. Maybe make it expire at the end of the year instead of the end of May. I am sure that some developers might still not end up using their code, but it would provide a bit more time for some developers to be able to purchase a machine. What would be a real kick in the pants would be that if the higher-end MacBook Pros are not released until June or July, because then it would really look bad for Apple to not have the true developer machines be purchased by developers. Overall, given how profit-motivated Apple is, as well as how they put developers at the bottom of the list, I do not see them changing anything at all.
There are some developers that are perfectly fine with the $200, because they were not expecting anything. Honestly, that is the best approach to anything when it comes to Apple. Expect nothing, because then when you do get something, it is a big surprise. Ultimately, no matter what Apple does, it will just irk developers and may not generate all that much good will with them. It might have just been better for Apple to not offer anything, but they would get pushback for that approach as well. No matter what Apple decided to do, it would be a catch-22, but that is the burden you take on when you are the richest company in the world.
Today Apple announced that its current Senior Vice President of Hardware Engineering, Dan Riccio, will be transitioning into a new role as a “vice president of engineering”. Riccio will be reporting to CEO Tim Cook. Riccio will “transition to a new role focusing on a new project”. Apple has not specified what that project is, but I suspect we will see the results of that in the next few years.
After 23 years of leading our Product Design or Hardware Engineering teams — culminating with our biggest and most ambitious product year ever — it’s the right time for a change. Next up, I’m looking forward to doing what I love most — focusing all my time and energy at Apple on creating something new and wonderful that I couldn’t be more excited about.
Taking over the role of Vice President of Hardware Engineering will be John Ternus. Ternus previously held the role of vice president of Hardware Engineering. He has held this title since 2013. While you may not recognize the names, it is likely that you have seen them, particularly John Ternus.
There are some things that I purchase on a regular basis. Among these are groceries, gifts, and other various things. In terms of technology the chief among these is purchasing a new iPhone, iPad, and Apple Watch. I have purchased an iPhone and an Apple Watch each year since their respective introductions. I have purchased a number of iPads, but I have not purchased a new one every time one has been released. One type of device that I have not purchased on a regular basis is a computer, in particular Macs.
In my lifetime, I have purchased a total of five different Macs, three of these have been and two of these have been laptops. The first Mac that I purchased was a 20-inch 2.16GHz Core 2 Duo iMac that I purchased in March of 2007. The reason I ended up with a Mac was because I had nothing but issues with Microsoft Vista. I got tired of dealing with the constant crashing of the video drivers, even 6 weeks after its release, I opted to buy a Mac. This was in March of 2007, so it was after the transition from PowerPC to Intel. Here is the list of the other devices that I have purchased:
2017 – 27-inch – 4.2 GHz Quad-Core Core i7 with 24GB RAM, 3TB Fusion Drive HD
All of these devices have one thing in common, they are all Intel-based devices.
Apple announced that they would be transitioning away from Intel processors to their own Apple Silicon. This announcement was made at their 2020 World Wide Developer Conference. At the announcement Apple indicated that the first machines would be released this year and that the entire transition would take approximately two years. While many suspected that Apple would announce a laptop, they announced more than just a single device.
Apple announced two laptops, that had Apple Silicon chips in them. These are the 13-inch MacBook Air and the 13-inch MacBook Pro. As a surprise, Apple announced a desktop machine would have Apple Silicon in it as well, the Mac mini. All of these machines have the first Apple Silicon chip, which Apple has called the M1, inside them. Let us discuss a bit about the M1.
Computers, for most of their history, have been comprised of distinct chips. Some of these include the processor, the system memory, the graphics chip, and storage. As time has gone on, some of these items have been integrated onto a single board. Most commonly the processor and graphics. Many computers these days also have their system memory soldered in, so that this cannot be expanded. This is quite common with laptops and less common with desktop machines. This type of configuration is consistent between both Intel-based and AMD-based systems. Apple’s M1 takes a different approach.
The M1 is not just a processor. Instead it is a System on a Chip, or SoC. The M1 is not Apple’s first custom SoC. In fact all iPhone, iPad, and iPod Touch devices that have been equipped with an Apple A-series chip have been an SoC. This is also the case for the Apple Watch, Apple TV, and HomePods.
For the M1, the SoC consists of more than just the central processor. In fact it includes the processor, graphics, and a 16-core Neural Engine. Along with this, comes the Unified Memory Architecture, or UMA. In traditional computer configurations, you have memory that is a separated from the rest of the system and on their own dedicated chips that connect to the system on the motherboard. A Unified Memory Architecture is one where the the processor, graphics, and in Apple’s case, neural engine, all share the same memory.
In a traditional computer, each subsystem would have its own memory. For instance, there is the main system memory, which is accessed by the central processing unit, or CPU. The graphical processing unit, or GPU, has its own dedicated memory. There are some tasks that are better suited for a graphics chip while others that are better suited for the CPU. In order to be the most efficient and process things most efficiently, different segments of the memory need to be transferred between the two processors. This transfer, while it takes very little time in reality, it can still take some time.
With the M1, this processor, graphics processor, and neural engine all share the same memory pool. What this means is that there is no delay in switching between using the CPU, GPU, and Neural Engine. This results in the system processing items significantly faster.
The M1 chip is an 8-core chip, with four performance cores and four high efficiency cores. When you do not need top performance the efficiency cores will be utilized. However, when you need speed those processors will be used. This is beneficial for all Macs running the M1, but there is a specific benefit for portable systems. Significantly increased battery life. In particular, for the MacBook Air, you can get up to 50% more battery power, which is a significant increase, and a very welcome one.
The shared memory pool, for the current machines, all come with 8GB standard. These machines are configurable for up to 16GB of memory. While this seems like a small amount, the machines that have been released are not aimed at those who need significant amounts of memory. Instead, they are aimed at the general consumer. This is most apparent with the fact that the 13-inch MacBook Pro and Mac mini still have Intel models that can be configured for higher specifications available to order, should users need the extra memory.
The M1 Macs are based on the same technology that is used within Apple’s other devices. This has a side benefit, the ability to run iOS and iPadOS apps natively, right on the Mac. It is up to the developer of the app to determine if their app is available on the M1 Macs or not.
If you look at the machines I have purchased, I end up purchasing a new Mac desktop every four years, and a new laptop every 8 years, although with two data points I doubt that this will be the case. There is one more computer to add to that list, the M1 Mac mini.
M1 Mac Mini
Initially, I had not planned on buying an M1 Mac, at least not right away. My 2017 iMac works quite well and in reality my MacBook Pro needs to be replaced first, since it is older. I kept going back and forth on which configuration to get. Do I need the MacBook Pro, or would the MacBook Air suffice? I was not sure if I wanted to get the first-generation machines. Not because I think there would be any issues, but because I would want something with more than 16GB of RAM, and since I was looking at replacing my MacBook Pro, I wanted something with more than 2 ports. None of the devices that were released has more than two ports, so I was planning on waiting until the higher-end models were available.
Things came to a head when I asked a friend, who did get an M1 MacBook Pro, to try my app on the M1. He was able to install and most everything worked. Except there were a couple of things that ended up crashing. I could have attempted to trouble-shoot them, but that is not easy to do without being able to debug as you co.
Because of this, I had to order an M1 Mac. I decided to get the base model Mac mini, which comes with 256GB of storage and 8GB of ram. I opted to get the base model Mac mini for two reasons. The first is because it was the cheapest and second it was able to shipped right away. I ended up just getting the base model, because I primarily need it for development and since it will be a dedicated development machine, and not my main machine, I did not need it to be completely upgraded. In some respects, I wish I had upgraded it, but that is for discussion later.
I was able to figure out the issues that were crashing the app. The problem was not with the M1 specifically, instead the issue that my friend was experiencing turned out to be a server-side issue. I ordered the M1 Mac mini in late November, and doing so extended the return window to be in early January. I have not returned the Mac mini yet. I do not think I will. In fact, I had not purchased Apple Care initially with the Mac mini, but I did just purchase Apple Care for my M1 Mac mini.
The M1 Mac mini is fast. When I am using it, I can generally use it without any issues, slowdowns, or performance losses; most of the time anyway. Even though the model I have only has 8GB of RAM, this seems to be enough, and the 256GB of storage should be plenty since I am not using it as my primary machine.
The M1 Mac mini is the same physical form factor as the previous Mac mini, albeit in silver instead of Space Gray. The fact that it is the same form factor means that it includes a spinning fan. In the time that I have had the Mac mini I have not heard it spin up, even when performing system updates. This is not the experience that I have had with the 16-inch MacBook Pro. The fans on that will spin at full speed while updating. So, this is a nice departure. As a side note, the M1 MacBook Air does not have a fan, so you will never hear the fan on that machine ever.
The M1 Mac Mini does not have the same port configuration as the previous models. The M1 Mac mini has 2 USB-A ports, 2 Thunderbolt/USB 4 ports, a gigabit ethernet jack, and an HDMI 2.0 port. For most users this port configuration is plenty. I know it is more than I need. The Intel model has the option of configuring the ethernet port to 10 gigabits per second and includes four Thunderbolt/USB-C ports.
The M1 Mac mini includes Bluetooth 5.0 and a 3.5mm headphone jack. This is the same as on the Intel-based Mac mini. There is one last difference, and that is in wireless connectivity. The M1 Mac mini supports 802.11ax, also known as WiFi-6. If you have an 802.11ax router, you should see significantly faster speeds, when going between other 802.11ax devices.
The M1 Mac Mini is capable of supporting two monitors, including Apple’s Pro Display XDR, as well as a 4K monitor. You can also use the USB-C ports for a display, along with the standard HDMI port.
This should be a pretty quick section, as there is no way to upgrade the internals. The memory and storage are soldered onto the board, so nothing can be upgraded. Any storage upgrades would have to be external. There are not even any pins on the board to even begin to connect something internally.
One of the benefits of the M1 is that you are able to run both Apple Silicon-based apps and Intel-based apps on the same machine. The ability to run Intel-based apps on the M1 is done through Apple’s translation layer, called Rosetta 2.
I have only used one app that has been Intel-based on the M1 Mac mini and I have not experienced any issues with that app. It is likely that you will not experience any issues with Intel-based apps on an M1 Mac, but it is possible that some issues might exist depending on the app, but most should work without any issues. There might be some performance issues, but they should be minimal.
Having articulate the speed difference with the M1 Mac mini as compared to other devices. So, I opted to use unarchiving the Xcode 12.3 beta. Let us now look at quantifying the speed increases, with some benchmarks. What would a review be without them?
I was trying to find a way to be able to articulate just how fast a Mac running an M1 really is. I decided to unzip the Xcode 12.3 beta on a number of different devices that I have access to, and here are the results from slowest to fastest, formatted in minutes and seconds:
2018 Mac mini (3.0GHz 6-core 8th-generation Intel Core i5, 8GB):
2020 Developer Transition Kit (A12Z, 16GB):
2020 M1 Mac mini (8GB):
As you can see, the M1 Mac mini is blazingly faster when it comes to unzipping a 11.2GB xip file to its full 27.2GB size. This is just part of the speed that the M1 offers.
Any time you use a newer machine, whether you replace an older machine or just add another machine to your existing computers, you expect the machine to be faster. This is definitely the case with the Mac mini. It is not faster just in Geekbench benchmarks, it is, see the chart above, but just in the general feel it seems faster. I am sure part of this is the fact that it is an SSD only machine, as well as not having all of my usual apps on the machine, and the fact that it is a new machine.
However, the actual difference is borne out through the benchmarks that have been done using Geekbench 5.
iPod touch (6th Gen)
iPod touch (7th Gen)
iPhone 7 Plus
Early 2015 13.3-inch MacBook Pro
Late 2018 Mac mini
Mid-2017 27-inch iMac
12.9-inch iPad Pro (3rd Gen)
Late 2019 16-inch MacBook Pro
iPhone 11 Pro Max
iPhone 12 Pro Max
M1 Mac Mini
In Single Core performance, the M1 mac mini is 8.4% faster than my iPhone 12 Pro Max, 54% faster than my iPad Pro, and a whopping 62.8% faster than my 2017 iMac. Even crazier though, is the multi-core benchmarks. The M1 Mac mini is 57.4% faster than my iPad Pro, 68.2% faster than my 2017 iMac, and 71.4% faster than my iPhone 12 Pro Max. This difference is absolutely noticeable.
The biggest speed improvements that I have seen are actually while I have been doing development.
Developing on an M1 Mac mini
As mentioned earlier, the primary reason that I bought an M1 Mac mini was that my app was crashing on a friend’s M1 Mac. Although, the issue ended up being on the server-side, and not the app itself, I have done quite a bit of development using the M1 Mac mini. I have some things that I have noticed along the way, so let us look at some of those now, starting with the screen.
Screen, or lack there of
One of the possible downsides of the Mac mini is that it does not include a screen. While I can purchase a monitor, including a 4K or 5K monitor, it is not likely to be a P3 color gamut monitor, and since the Mac mini is not my primary machine, I do not want to invest too much into it. I do have a 27-inch 1090p monitor that I purchased earlier this year, and have been using that.
Using this setup is definitely not ideal and is a significant departure from what I am used to with my 27-inch iMac. The difference is not only in the color, but also in the amount of screen real estate. On my iMac I use a scaled resolution, to provide me more usable space. This does result in smaller font, which I have no problem seeing, for the most part.
However, with the Mac mini and a 1080p monitor, I am limited in the amount of space that I have available to me, so I have to do some juggling in order to be the most efficient. Sometimes I have multiple windows open, one for the current file I am looking at and another for the simulator that I have running. With the amount of space on the iMac, I am able to position all of the windows to be able to see everything at once. That is just not possible on the 1080p monitor I have. It is situations like this where I wish Apple had continued to sell a stand alone monitor. I understand that it is a very small market, but having quality monitors that work well with Apple’s hardware would be ideal.
Even though I have to do some juggling, I am able to get some development done. I do not necessarily need to use the Xcode simulator all the time. This is because I have begun using a slightly different way of doing development.
Most general computing tasks do not process things using more than a single core. Yes, there are a number of applications that are specifically designed to utilize all of the cores of a machine, but most do not necessarily utilize these to their fullest extent.
One area that can utilize the multiple cores simultaneously is when you are building an app. The reason that this is possible is because the compiler is able to handle multiple tasks at once. This is most noticeable when using a specific feature of Apple’s Xcode app, called SwiftUI Previews.
Despite having a 27-inch iMac, which should be able to handle most development tasks, there are some things that it is not able to do. Most notably, it is not able to use SwiftUI Previews. SwiftUI Previews is a technology built into Xcode that allows you, as the name states, preview SwiftUI views. SwiftUI is a user interface that takes the core aspects of the Swift language and builds a series of user interface elements on top of the language. When you create SwiftUI Previews, they are in almost real-time. This is possible because when you use SwiftUI Previews, your screen is divided in half. On the left side you see your code and on the right side you see the SwiftUI Preview. With this arrangement, when you make a change it should be instantly reflected in the preview. This has been my experience on the Mac mini, and is the intended experience for anyone using SwiftUI Previews.
The way that this works is by constantly re-building your app. If you have done development for any amount of time you likely realize that this seems like it would be a constant drain on the system. In most cases, it would be. However, Swift is able to recompile only the parts of the app that need to be recompiled, and this technique allows SwiftUI previews to work.
My initial thought is that the reason SwiftUI Previews has not worked on my iMac is because it has a fusion drive, where a majority of the drive is a traditional spinning hard drive and a smaller portion is an SSD. So, I thought I would try SwiftUI Previews on my 2015 MacBook Pro, which is a pure SSD. However, I never ever been able to satisfactorily use them either. I have a 16-inch late 2019 MacBook Pro for work, and while SwiftUI can work on this, there are times that it even has issues with SwiftUI Previews.
That is not the case on the M1 Mac mini. I am able to use SwiftUI Previews without any issues, including the near real-time recompiling of my app. Changes that I make are reflected in the previews, and that is previews plural. With SwiftUI Previews you are able to have multiple devices show in the preview canvas simultaneously. This can allow you to easily see how an app will look at various screen sizes.
Each of these previews is its own simulator. Any simulator requires some memory, and if you have a large number of SwiftUI previews, even for a single SwiftUI View, they can use significant amounts of memory. This can be problematic in some situations. On the topic of memory, let us look at that next.
Throughout most of the time I spent working on my app on the M1 Mac mini I did not experience that many issues. However, it seems as though Xcode will use as much memory as it can. At one point I started running into some performance issues and realized that Xcode was using 10.2 GB of memory, the LLVM process was using nearly 3GB of memory on its own. The amount of swap being used was 6.3GB.
This resulted in the Mac mini needing to use some swap, which I never experienced on my iMac. The reason for this is because my iMac has 24GB of memory in it The 8GB that came with it, and the 16GB of memory that I added after the fact. The 2017 iMac still has an access door for being able to add memory.
As you might expect, once I quit Xcode and waited for all of the processes to close and then restarted Xcode, I was back to having my regular performance. I guess that proves that sometimes it is best to just quit the app and restart it. However, the 8GB of memory does seem to be a bit of a bottle neck. This is most noticeable if I am working on SwiftUI Previews while also having simulators running at the same time.
Just as is the case with a tradition architecture, if the memory that is being used is full, anything not being used is swapped to the SSD. The speed of the SSD is fast enough where you will not likely notice the memory being swapped. However, as I experienced, there is a limit. Even though the memory swapped very fast, and I did not even notice it being done, it can have a slight performance impact.
One of the benefits to the M1 Macs is that users can run iOS apps natively, provided a developer opts in. Now, as a developer this has a benefit for you as well. You are able to test your iOS apps natively, including all of the features that are supported, such as handoff. This means that if you have an M1 Mac and an iPhone, you are able to do full handoff testing to verify that everything will work as expected without needing to have multiple iOS devices. Granted, this is provided that you are not offering a native macOS app, but only offering your iOS app for use on the M1 Macs.
Even though the M1 Mac improves your experience with macOS, and development using some of Apple’s most intensive development tools, it has not been entirely smooth sailing. So let us dive into some of the issues that I have experienced.
As much as we would like it to be the case, nothing is perfect. To quote John Siracusa, “Nothing is so perfect that it can’t be complained about.” I have actually experienced a few different issues with the M1 Mac mini. The first of these, and the most annoying as well as most prevalent, is with an item I use all the time, the Magic Mouse.
I use a Magic Mouse 2, and a Magic Keyboard, with my Mac mini. I did not buy these new when I got ordered the Mac mini. The whole idea of the Mac mini is to be able to use your existing Keyboard, Video, and Mouse, which is what I did. Most of the time these just work, however, the Magic Mouse seems to randomly disconnect. This happens right in the middle of me using it. Sometimes I am pasting text and other times I am simply scrolling. There is no rhyme or reason as to why it happens that I have been able to ascertain, yet.
Once the mouse disconnects, it will reconnect, then immediately disconnect again, and then reconnect again. Again, this is not consistent. There are times when the disconnect and reconnect only occurs once, sometimes it is twice, and yet on a few occasions it has been three times. Sometimes, the mouse will work after it reconnects, but sometimes it does not. I have tried manually disconnecting and then reconnect the mouse, and it will work again for a while. This could be a half hour, an hour, or even longer, but it will inevitably happen again.
At first, I thought it could be an issue with macOS Big Sur 11.0.1. It was the first release of macOS Big Sur after the M1 Mac launched. While using the Mac mini macOS Big Sur 11.1 was released. I, of course, updated to this version. I updated not just because of this issue, but because I prefer to stay on the latest version of macOS. After installing the update, the issue continues. So that did not fix it.
The next thing I tried was a different Magic Mouse, a first generation one, that requires batteries and is not rechargeable with a lightning cable. Unfortunately, this did not fix the issue either. While it seemed that the issue happened less often with the first generation Magic Mouse, it did still happen. The issue is transient and does not happen consistently enough for me to be able to identify a pattern. I will continue to see if I can identify what is causing the issue. I have not experienced any issues with the Magic Keyboard disconnected, that I know of, so I think the issue may be isolated to the Magic Mouse.
I am beginning to suspect that the issue is entirely related to Xcode. I have used the mouse quite extensively while browsing the web and other tasks on the Mac mini and they did not happen when I was doing that, so it seems like it might be an Xcode-specific bug. This is still problematic because I am intending to use the Mac mini as a development machine, so Xcode is pretty important.
The issue with the Magic Mouse has not been the only issue I have experienced. I have encountered some issues while doing development.
Problems with Development
The second issue is one that I have only experienced twice, and may only be due to the 8GB of memory on the machine. I was working on my app and I came across an error, while using Xcode, that states:
The current system settings are not sufficient to allow booting additional simulators: maxFiles: 1288, openFiles: 1163, enforcedFilesBuffer: 1868. Please see Simulator help for information on adjusting resource limits.
I have never seen this error before, or anything even like it. Even with my usual build and run cycle on my iMac I have never come across this, or anything similar. Now, when I saw this error I was a bit confused because I was not trying to actually boot a simulator. I was actually in the middle of coding and just trying to build the app. I am sure that the reason that I got this error was because I have been using SwiftUI Previews. SwiftUI Previews can have multiple previews and each preview can rebuild the current view in an incremental manner. This results in quick builds and I suspect that there were just too many preview windows that ended up using up the available resources.
Furthermore, I am thinking that the fact that I only have 8 GB of memory in the Mac mini is part of the cause. It could be that I have not experienced this on my iMac because it has 24GB of memory, therefore it has enough resources to handle this. Additionally, as mentioned earlier, SwiftUI Previews has never worked properly on my iMac. Therefore, it could be a combination of me not using and it not working properly on my iMac as the reason I have never experienced this.
The fix was quite simple and an easy one. I simply closed Xcode and made sure the simulator, and all of its associated processes were closed. After restarting Xcode, I was back in business. I have not experienced this issue again, but who is to say that I will not again in the future.
I did get another issue, one that is not related to memory, but what seems like a compiler bug. This is the error I received:
Please try again later. Failed to finalize LSBundleWrapper mutator instance for [bundle identifier]
One of the things that you can do with an M1 Mac is run iOS apps. In addition to this, you can run your iPad app right on your M1 Mac. In order to do this, you select the build target of ““My Mac (Designed for iPad)”” in Xcode. Each time you successfully run a build using this target, your iOS is wrapped in a bundle and copied to your debug folder. As is the case with other apps, if there is already an existing app with the same name the app is incremented. For instance, for my app wwriteLite, the first build would be “wwriteLite”, the next would be “wwriteLite 2”, the third “wwriteLite 3”, etc.
At first, I thought that I ran into the issue because the Mac mini has a limit on the number of builds allowed in the directory, but I do not think that is the case. I attempted to replicate the issue by purposely building and running, but I could not replicate the issue.
When this happened, I tried the first step in any troubleshooting, I tried quitting Xcode and re-opening it, but that did not fix the issue. I then decided to google the issue. The only result that I could find indicated that you needed to enable Mac Catalyst, build the app, and then disable it. To me, this does not seem like an appropriate solution because I was not building a Mac Catalyst app, and I did not want to deal with any possible problems that might arise from doing that.
At this point I opted to do the equivalent of nuke and pave for development: Clean the build folder and build the app again. Guess what, this fixed the issue. So, if you run into issues sometimes just doing a clean build folder and rebuilding the app fixes it. It the development equivalent of “quit and relaunch”.
There is yet another last issue I ran into, and this was also related to compiling.
Compiling Issue/Resource Utilization issue
A few times while I was compiling my app, I have had the entire system just stop responding. The mouse was able to move but that was it. Ironic, I know that the mouse, which has been causing other issues would continue to work, but I could not click on anything, I could not hit command-tab to switch to another app, nor could I bring up any windows. When this did happen, I let it sit and it would eventually catch up. Of course any actions that I had performed would replay. Obviously something locked up the system, but I am not sure what it was.
Read Only File System?
The last weird error that I have encountered while using the M1 Mac mini is an error that stated:
You can’t save the file ‘About.swift’ because the volume “Macintosh HD” is read only.
Now, when I got this message I was definitely confused, because I had been using the system, and therefore it the volume that the app is on is definitely “read only”. I do not use iCloud Document and Desktop syncing for my development iCloud account, because I do not need the feature since I do not have more than one machine dedicated for development. Even if I did, all of my code is source controlled, so I can just pull from source control.
As has been the case with many of the issues, quitting Xcode and restarting it fixed the issue. I have not experienced the same issue again. It is possible that I happen to try and save the file when the file system was taking a local Time Machine snapshot, but if so, then that was some really good timing on my part.
The M1 Mac mini is fast, even in its base configuration. The M1 Mac Mini is speedy with everything it does, from just interacting with Finder, to building the incremental SwiftUI previews, and even building an app from start to finish.
If you are a developer, I recommend getting an Apple Silicon Mac as your next development Mac. This is particularly true if you plan on supporting your iOS to run on the M1 Macs, but a necessity if you have a native Mac app. If you do need one, you do not need to break the bank to get a great machine. However, you may want to wait for larger memory configurations.
The speed of the Mac mini alone is worth it. This is particularly true if you use SwiftUI and utilize SwiftUI Previews. The Mac mini is able to render these in near-real time is quite nice. Furthermore, the speed of the Mac mini allows you to be more productive. The fact that the system can compile builds, and incremental builds, so quickly means that you will spend less time waiting for the system and more time actually developing.
One thing I would recommend would be to get at least 16GB of RAM. At the time of this writing, the maximum you can get is 16GB, and I would definitely recommend it. I am sure that some of the issues that I have experienced have been due the fact that the Mac mini I purchased only has 8 GB of memory and not 16GB. In some ways, I regret not ordering a machine with 16GB of RAM, and time will tell if this was ultimately the wrong decision.
On a similar note, since I am only using the Mac mini as a development machine, the 256GB of storage should be sufficient, but I will not really know until I have used the machine for a bit longer. The reason that I say this is because half of the space is already used up, and I do not have a lot on the device. I have Apple’s built-in apps, Xcode, BBEdit, and a couple of other small applications. I do not have much else on the machine. As any developer knows, Xcode and its associated files do take up a lot of space. I wish Apple would have some sort Xcode cleanup utility, or have ways of cleaning up some of the excess Xcode files.
While I think 256GB should be enough for this device, for my needs. If this was my main machine, it would definitely not be enough storage space. So, take that into consideration if you do decide to purchase an M1 Mac. Even thought I have experienced some issues, I can still recommend getting an M1 Mac, even if you are not a developer.
I am not the first one to say this, but it does need to be said, these are the SLOWEST Apple Silicon Macs we will ever see, and these are already super fast. I do not expect to see the same type of speed increases in the future, but this is a great baseline to compare to with future M1 Macs. These machines absolutely blow away all Intel machines, and even most of Apple’s other Apple Silicon-based devices, like in the iPad and iPhone.
Ultimately, I may end up getting a different Apple Silicon-based Mac in the not too distant future, depending on what Apple releases. Even if I do end up buying another Apple Silicon Mac and using that for development instead, the current Mac mini can be used for a number of different things, like a server. If used as a server, the limitations of the smaller internal storage and 8GB of memory would not necessarily be limiting factors in that, since storage can be external, and while possible, it is hard to see 8GB of memory not being enough, for a server.
Here is one last thing to keep in mind. Even if you are not planning on getting a Mac mini, because you would prefer a laptop, everything I have written also applies to those machines as well. This is because all of the M1 Macs are using the same processor. Therefore, regardless of M1 Mac that you get, you should see significant improvements. Furthermore, even if you are not a developer and just need a new Mac, I recommend getting an M1 Mac, it should be able to serve your needs for many years to come. Now, if Apple would only release a standalone 5K monitor, but again, that is a whole other story.