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:
- 2007 – 20-inch iMac – 2.16 Core 2 Duo, 8GB RAM, 500GB 7200RPM HD
- 2007 – 13.3-inch MacBook – 2.16 Core 2 Duo, 8GB RAM, 750GB 7200RPM HD
- 2011 – 21.5-inch iMac – 2.7 GHz Intel Core i5, 12GB RAM, 1 TB 7200 RPM HD
- 2015 – 13.3-inch MacBook Pro – 2.7GHz Dual-Core Core i5 16GB RAM, 256GB SSD
- 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.
Apple's 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.
Overall Thoughts
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.
Upgradeability
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.
Intel-based Apps
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?
Obligatory Benchmarks
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:
| Device |
Time (Hours:Minutes:Seconds): |
| Mid 2011 21.5-inch iMac (2.7 GHz Intel Core i5), 12GB): |
1:36:35 |
| Mid 2014 iMac (1.4 GHz Dual-Core Intel Core i5 8GB): |
45:25 |
| Early 2015 MacBook Pro (2.7 GHz Dual-Core Intel Core i5 16GB): |
26:21 |
| Late 2019 16-inch MacBook Pro (2.6GHz 6‑core Intel Core i7, 16GB): |
17:57 |
| Mid 2017 27-inch iMac (4.2 GHz Quad-Core Intel Core i7, 24GB): |
12:58 |
| 2018 Mac mini (3.0GHz 6-core 8th-generation Intel Core i5, 8GB): |
9:05 |
| 2020 Developer Transition Kit (A12Z, 16GB): |
8:29 |
| 2020 M1 Mac mini (8GB): |
5:00 |
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.
| Device |
Single Core |
Multi Core |
| iPod touch (6th Gen) |
258 |
528 |
| iPod touch (7th Gen) |
553 |
1077 |
| iPhone 7 Plus |
740 |
1355 |
| Early 2015 13.3-inch MacBook Pro |
746 |
1652 |
| Late 2018 Mac mini |
992 |
4442 |
| Mid-2017 27-inch iMac |
1068 |
4377 |
| 12.9-inch iPad Pro (3rd Gen) |
1124 |
4680 |
| Late 2019 16-inch MacBook Pro |
1170 |
5391 |
| iPhone 11 Pro Max |
1328 |
3252 |
| iPhone 12 Pro Max |
1604 |
4297 |
| M1 Mac Mini |
1739 |
7366 |
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.
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.
Memory Usage
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.
Problems
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.
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.
LSBundleWrapper
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]
![Xcode error that states "Please try again later. Failed to finalize LSBundleWrapper mutator instance for [bundle identifier]"](https://www.waynedixon.com/wp-content/uploads/2020/12/m1-mac-mini-issue-unable-to-install.png)
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.
Closing Thoughts
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.
