It is now about two weeks since I got my Apple Macbook Pro M1 delivered. It is the one with 16 GB of RAM and 2 TB SSD. Delivery time was quite long, I ordered it at the beginning of December. But now when I have used it as my primary machine for a while it is time for a review.
I primarily use it for .NET development including app development using Xamarin and backend development using .NET Core 3 and .NET 5. I also, do some development using Blazor from time to time.
To overall impression is that it is a really fast machine. macOS and applications that are optimized for the machine are really fast. Applications that not are optimized are faster or at least not slower than on my old MacBook Pro from 2017.
What is great is that it never became hot, not so far, it can be a little bit warm, but I have never heard the fan. On my old MacBook, the fan sounded like a jet plane.
As always with a Macbook it is very solid. I like that they have switched back to the old keyboard. The only downside is that it only has two thunderbolt/USB-ports. So you probably need a USB-hub. I have a display connected with USB-C that has USB-ports and it also powers the computer.
As we could expect, iOS development is not an issue, because Apple has of course optimized XCode for the new M1 Macs. And Visual Studio for Mac runs good with Rosetta 2, But what about Android? The development worked well, but to run my app on an emulator I had to go and download a preview version of the emulator for the new Macs. But the emulator works really well and it is really fast. But right now (preview 3) you cannot run Chrome on it. You can download it from here. https://github.com/google/android-emulator-m1-preview
To do backend development with .NET Core 3+ and .NET I had to install the beta of Big Sur 11.2. Before that, it crashed every time that I tried to debug an application. But with the beta, it is working like a charm.
For Visual Studio Code there is an insider build that is compiled for ARM. That version is really good, it is much faster than the "old" Visual Studio Code.
Docker has a preview for M1, https://docs.docker.com/docker-for-mac/apple-m1/. It works great, there are some problems with images that not are for ARM. I tried with an SQL Server 2019 image for example and that one did not work. https://github.com/docker/for-mac/issues/5170#issuecomment-767803717. But a colleague found an image that I can use for SQL-server that had enough features for me, mcr.microsoft.com/azure-sql-edge. I also run a container for MongoDB without any issues.
Streaming and media
I have tried Streamlabs OBS and there are no problems running it with Rosetta 2. It feels more smooth compared to running it on my old Mac.
For editing videos, I have tried iMovie, an app that Apple has optimized for M1. It works really great, I imported and 6-hour long video with a size of 13 GB and it worked like I imported just a short video.
I also have tried Adobe Photoshop without any issues.
Microsoft Office including Word, Excel, Outlook, and Teams, etc. runs fine. But I could not get OneDrive sync working. The same with Google Drive sync.
You cannot run Bootcamp on the M1 Macs. But Parallels Desktop has a technical preview, https://www.parallels.com/blogs/parallels-desktop-apple-silicon-mac/, that are able to run Windows ARM. The problem is that Windows ARM images can be hard to find. But after I asked on Twitter I got an answer that there are insider builds that is available for download. So I did and Windows runs much better on Parallels now than compared with the x64 version on my old Macbook. I also was able to run Visual Studio (x86) on it and it works ok, it is as good as running it on Parallels on my old Macbook.
MacBook Pro M1 is a really good and fast computer, there are some small issues, but if you should buy a new Mac now, I recommend you to buy an M1, Intel Mac feels old!
To build and publish TinyMvvm I have used Azure Pipelines and a classic build pipeline together with a release pipeline. For the upcoming 3.0 release (in preview right now) I have migrated the pipeline to GitHub Actions. There are several reasons for that:
I want to make the CI/CD open so all can see what happend. You can have an open project in Azure DevOps as well, but the project we use for building TinyStuff libraries are to old to make public and I felt that I it was better to use the time to migrate to GitHub Actions according to the other reasons.
I want to have everything together, GitHub Actions is according to me better integrated in GitHub.
I feel that GitHub Actions is the future, both Azure DevOps and GitHub is Microsoft products and what I can see, Microsoft have mor focus on GitHub Actions.
GitHub feels like the natural place for Open Source.
To define the build I decided to use Cake and the reasons for that is:
- Cake is cross-service. So if I want to move it to an other service I can resuse the most parts. Many services using yaml, but with different flawors of it, so it cannot be reused, not even between the both Microsoft controlled products GitHub Action and Azure Pipelines. The Cake scripts will be easy to use in all major services.
- It is C# and I like to be able to use C# for defining the build and publish steps.
- It is Open Source and easy to extend.
The only downside for Cake is that thera are not much good documentation about how to use it. There are good API-documentation, but not so much "How to"-documentation. But if you know how the underlying processes works it will be pretty easy to get started anyway.
I have defined two actions so far for TinyMvvm, one for when codes is pushed and one for when a released is published.
Everytime code is pushed to either the master branch or to a pull request the code is built to verify that noting is broken.
You can find details about the action here:
When I manually create a release in GitHub this action will trigger, the name I will give the tag will be used for the version number for tha package.
The Release action will build the code from the tag and it will publish the packages to NuGet.
You can find details about the action here:
The cake script has three tasks defined; Build, Pack and Publish. The build action, only runs the build task. The Release actions is running all tasks.
My session from Xam Expert Day is published on YouTube: