Software Development is an Adventure

I released DFU Blaster Pro a few weeks ago, and many key features were not planned upfront but discovered along the way. Some uses were discovered after release, and one feature was accidentally discovered when testing the software. I love the discovery process when building something new. The road to DFU Blaster Pro followed a pattern I have used since I started writing software: 

1. Find something interesting.
2. Release something small and useful.
3. Listen to people using it.
4. Watch for unusual things.

The most compelling features in DFU Blaster Pro were not even known when it was first released. The story of its development shows this process in action. 

Find Something Interesting

I was frustrated by the lack of feedback when putting a Mac laptop into DFU mode (DFU mode lets you easily restore the OS). I even made a video about it. Unrelated, I was following the porting of Linux to Apple Silicon, and the main developer discovered the commands to put Apple Silicon Macs into DFU mode. He released a command line tool to show how it worked on GitHub and I tried it out. I was amazed when I ran the tool and the target Mac instantly went to DFU mode. No timing issues. No weird keyboard commands to remember. This was definitely interesting.

Release Something Small

I took the commands and wrote a free macOS app called DFU Blaster that lets you easily put a Mac into DFU mode with the click of a button. Without DFU Blaster, you have to hold specific keys for a specific period of time when the Mac is starting up, which is a very manual process. I stopped using the manual way to put a Mac into DFU mode and found myself always using DFU Blaster because it was so much better. I started hearing that others felt the same way.

Listen to People Using It

At the MacAdmins conference at Penn State, I had multiple people come up to me and thank me for writing DFU Blaster. I talked to them about why they liked it so much, and the consensus is that it is a reliable and predictable way to put a Mac into DFU mode. Many Mac admins want an easy way for techs to restore a Mac with a simple procedure. DFU Blaster made that possible.

Talking to folks using the software provides some amazing insights. I love to release software early and iterate for this very reason. Just last week, I met with someone using DFU Blaster to help deploy 1,000 Macs a day. I was excited to hear about how DFU Blaster helped, but he also mentioned that he was using it to deploy iPads. I had talked with folks about using DFU Blaster with the iPad, but heard that it does not work with iPads with lightning connectors. I also heard that putting an iPad into DFU mode is not that hard. However, the world has changed since I had those conversations. All iPads now have USB-C connectors, and putting them into DFU mode is difficult and has little visual feedback. So DFU Blaster is not just a time saver for Macs, but for the iPad as well. The same is true for the iPhone.

I then looked at our download site on BitBucket, and DFU Blaster had been downloaded over 25,000 times in the last 9 months. I realized that putting a Mac into DFU mode was becoming an important part of deploying a Mac and DFU Blaster was helping with that. I started to think that DFU Blaster could be a product. I decided to write DFU Blaster Pro.

Watch for Unusual Things

It was clear that folks deploying Macs were using DFU mode and that having DFU Blaster was helpful to them. The plan for DFU Blaster Pro was to build on the “put a single Mac into DFU mode” by making it easier to put lots of Macs into DFU mode and restore them right within DFU Blaster Pro. Unfortunately, only one USB-C port on a Mac can be used for putting a Mac into DFU mode. So I looked around and discovered that the Acroname Hub3c supported sending the type of commands to put a Mac into DFU mode. And not just one Mac, but 5 Macs. I reached out to the Acroname folks, and they are very helpful. I learned a ton about USB-C and how to send the commands from their hub to put Macs into DFU mode.

Unexpected Discovery 1: Serial Number

This led to the first unplanned feature: Getting the Mac serial number over the USB port. I was adding in support for the Macs plugged into the Acroname hub and wasn’t getting all the information I needed. To map the USB ports correctly to show in the app interface and restore them correctly, I had to dive into IOKit and get information about the device. I noticed that the attached Mac system had a value for the serial number in IOKit, but it was empty. I have been looking for a way to get the serial number from a Mac over USB for years and was not surprised when it was not in IOKit. However, when writing the code to parse IOKIt, I rebooted the Mac a bunch of times, and the Mac booted into the recovery partition. My breakpoint hit, and the IOKit object I had created showed the serial number of the Mac. I thought this was not possible. I rebooted the Mac and tried another Mac, and sure enough, when booted to recovery, the serial number of the Mac was exposed via the USB port via IOKit. I was not even looking for it and it showed up. 

Getting the serial number may not seem like a big deal, but for folks deploying Macs it is HUGE. The serial number is printed on the Mac, but there is no bar code. The serial number itself is small and on reflective metal, and the metal can have scratches on it. Also, the serial number has characters that are hard to scan, like the letter “O” and zero with no slash in it. Finding a deterministic way to get the serial number is really helpful for anyone deploying Macs and frustratingly difficult. So I added the ability to get serial number and display it as a bar code in DFU Blaster Pro. 

Unexpected Discovery 2: Recovery Partition

During my work on DFU Blaster, I noticed that occasionally my test machine would go into recovery mode instead of restarting into macOS. I had thought the only way to get an Apple Silicon Mac with a valid OS to boot to recovery was to hold the power button to get the boot selector, and then select Options to go into recovery mode. On Intel Macs, you can hold command-R (or use our Automaton to do it for you). Apple Silicon requires the power button to be held down and does not have a keystroke to use. Some Mac admins have actually created actuators that hold down the power button to get the Apple Silicon Macs into recovery mode. I was curious how a Mac could go into recovery when I had not held down the power button. I remembered that I had been restarting the Mac over the USB port using the same type of commands to put the target Mac into DFU mode. I suspected that there was some combination of the timing and the number of times a Mac was restarted to put it into recovery. I coded up a test and found that using a very specific number of reboots at a specific time interval will cause the Mac to go into recovery. This was exciting for a couple of reasons. First, our Automaton can take an Apple Silicon Mac booting into recovery and install software to pre-set up the Mac. Second, starting into recovery, the serial number is exposed to the USB port. I put a button into DFU Blaster Pro so booting into recovery is easy. As soon as the Mac enters recovery, DFU Blaster Pro shows the serial number. 

Unexpected Discovery 3: Serial Number at Setup Assistant

I found that if you put the Mac into DFU mode, and restore the OS, the target Mac will finish by booting into macOS and showing the Setup Assistant. When the Setup Assistant is running, the serial number is available via USB. I found this out by the serial number showing up in DFU Blaster Pro after restoring. I did not know it was even available. That was cool. Discovering that your own software does something you did not even know it could do is an amazing feeling.

With the ability to easily put a Mac into DFU mode, restore macOS and get the serial number right in DFU Blaster Pro, I recently added the ability to call out to external systems with the Mac ECID, serial number, the status of the restore operation, and the USB port it is plugged into. The serial number can be submitted via external systems like Apple’s GSX to see if the device is locked. And if so, one can know exactly which Mac it is and where it is plugged in. 

Software Development is an Adventure

Writing and releasing DFU Blaster Pro is a great example of why I love writing software. It solves problems and provides interesting solutions to folks’ problems, but it is also an adventure. When something strange happens, you lift your hands from the keyboard and think: “Wait, why did that happen, and how is that possible?”. The resulting investigation is a thrill. Seeing others using it and having a similar reaction is amazing as well.

If you deploy Macs, check out DFU Blaster Pro. I think it will be helpful. And let me know what you think. It was fun to write and I love to hear how people use it.