The 2018 Macbook Pro

I’ve been using a new 2018 MacBook Pro as my primary work machine for a few weeks now. I bought the top configration: 2.9 GHz six-core i9 CPU, 32 GB RAM, Radeon Pro 560X GPU.

My previous computer was a Late 2013 MacBook Pro with a 2.6 GHz quad-core i7 CPU, 16 GB RAM, and no discrete GPU. It served me very well for almost five years, except for a fried SSD after 46 months, which I replaced with a third-party OWC Aura SSD.

Detail of the Apple logo in the 2018 MacBook Pro’s lid
I’m glad the glowing Apple logo in the lid is gone. Getting rid of it in 2015 was long overdue. The reflective logo in the modern enclosures is still too much for me — I’m not going to be a walking advertisement for Apple. I’m still looking for a nice sticker to cover it.


This is my first MacBook since the 2016 redesign with USB-C and the touch bar, so many of my observations may be old news to you.


I really like the feel of the keyboard. Typing feels very precise. It may be my favorite keyboard — laptop or desktop — I’ve ever used for any significant amount of time. I also understand why some people don’t like the keyboard at all. With its low travel and “clicky” feel, it’s a contentious design.

Obviously, I can’t say anything about the keyboard’s long-term reliability. If Apple hasn’t fixed the problems of the previous generation keyboards, I’ll have to change my verdict. Reliability is much more important than a small improvement in comfort.

Touch bar

The touch bar and I haven’t become friends yet. I can see its usefulness for some tasks, and I don’t mind the tap-hold-pan gesture for changing the volume or display brightness as much as I expected. But any extra convenience is far outweighed for me by accidental (and sometimes destructive) touches. Some examples:

  • Closing a dialog or cancelling an action by unconsciously resting my finger on the Escape key before having made a decision whether or not I want to press the key.

  • Deleting a note in

  • Accidentally stopping or restarting a debugging session in Xcode while typing in the debugger console.

  • Unintentional back/forward navigation in Safari and Xcode.

Screenshot of the Customize Touch Bar dialog in Xcode 10
I keep hitting the Run or Stop button accidentally while writing code (where it’s not a big problem) or during debugging (where it quits the current debugging session). Xcode has a Customize Touch Bar feature, but it’s very limited: you can’t remove the four leftmost buttons.

Often, these accidental touches are so light that they don’t even register in my fingertip — I can only deduce what happened when I notice something unintendend happening on screen.

The unintentional touches will probably become less frequent as I get used to the touch bar. However, I still don’t think Apple should have shipped it in this state. The touch bar needs haptic feedback and some amount of force sensitivity in order to ignore light accidental touches. And Apple, while you’re at it, please add back a normal Escape key.

If you’re a Mac developer, consider carefully which controls to place on the touch bar. If you ask me, destructive actions have no place there as long as it’s so easy to invoke them accidentally.


I miss MagSafe and the LED charging indicator. Overall, I’m a fan of the new USB-C world, though. Being able to charge from both sides is very convenient, as is having a single USB-C cable for an external monitor and power.

I bought a relatively cheap (40 €) hub that provides USB-A ports, HDMI, Ethernet, and an SD card reader. It has excellent build quality (aluminum!) and has been working well thus far, although it gets quite warm in use.

Photo of the Inateck 9-port USB-C hub I bought
I bought this Inateck USB-C hub. It has 4× USB-A 3.0, 1× USB-C port (only for power delivery, no data), Gigabit Ethernet, HDMI (up to 4K at 30 Hz), and an SD and MicroSD reader.

Battery life

I expected worse from the battery, so I’m positively surprised. It doesn’t come close to the 10 hours advertised by Apple when working in Xcode, but I do get around 5–6 hours of real work use, which is way more than the 3–4 hours I got with my old machine (perhaps unsurprisingly, considering its battery is almost 5 years old, though still in good condition).

I started using Turbo Boost Switcher Pro to disable the CPU’s turbo boost feature on battery power after Marco Arment wrote about it, which stretches the battery for another hour or two.

I haven’t done any formal testing, but the battery drains extremely slowly under light use. I’d fully expect the battery to last more than 10 hours for very low CPU and GPU workloads.

Minimizing fan noise

Disabling turbo boost works really well for prolonging battery life, and it has another advantage: it can stop the fans from spinning up.

Screenshot of Turbo Boost Switcher Pro’s context menu
Turbo Boost Switcher Pro

Do you know the situation when Dropbox or Spotlight reindex something in the background and the fans spin up for minutes or even hours on end? They still do on the 2018 MacBook Pro, it’s quite annoying. In my experience thus far, the MacBook’s enclosure can dissipate enough heat to allow a single i9 CPU core to run at 100 % without spinning up the fans, but only when turbo boost is disabled (assuming the GPU is mostly idle). With turbo boost enabled, it has to increase fan speed to audible levels when a core goes to 100 %.

So now, I often disable turbo boost at times when the fan noise annoys me, even when the machine is plugged in. I’d still like a laptop that can drive the CPU without the fans spinning up audibly, but until then being able to choose between silence and maximum power seems to be the next best thing.

Performance benchmarks

I didn’t try very hard to create completely equal environments on both machines for these benchmarks, so don’t put too much faith into these numbers. They should be quite similar, though, because I set up the new computer as a copy of the old one. Generally, the 2018 MacBook had a few more processes running in the background during the benchmarks (such as Dropbox or iStat Menus), but those were mostly idle.

Compiling Swift from source

I built a release version of the Swift compiler, using build-script -x -R. The 33 % speedup exactly reflects the jump from four to six cores in this highly parallelized task:

2018 MBP 2013 MBP Δ
39 min 58 min 33 % faster

After the 2018 MacBook Pro thermal throttling issue and the subsequent fix Apple released, I was curious to see how the computer behaved under heavy CPU load for an extended period of time, so I monitored the Swift build with Intel’s Power Gadget software. I observed very consistent results:

Consistent 4+ GHz when a single core is maxed out

Build stages that aren’t parallelized tend to max out a single CPU core. During these times, the CPU frequency stays consistently above 4 GHz. The highest frequency I saw was about 4.4 GHz, which is still shy of the advertised “up to 4.8 GHz” turbo boost speed. The following screenshot shows the start of the build:

Intel Power Gadget screenshot showing CPU frequency and utilization during a build of the Swift compiler
Typical CPU utilization when a single core is maxed out. The CPU frequency hovers slighly above 4 GHz.

Observe how the Utilization curve is pegged at ~16 % (= one core at 100 %, the other five are idle). The Frequency curve hovers slightly above 4 GHz for the entire time. The CPU draws approximately 30 W (Power / IA) in this state, with peaks going up to 40 W. The temperature is stable at slightly below 100 °C.

Consistent 2.9 GHz when all cores are maxed out

Parallelized build stages (such as compiling) max out all six cores. CPU frequency drops to 2.9 GHz, exactly in line with expectations. The CPU draws 35–40 W in this state. CPU temperature remains unchanged. In the following screenshot, you can see the sudden jump in the Utilization curve from 16 % (one core) to 100 % and the corresponding drop in frequency from 4+ GHz to 2.9 GHz:

Intel Power Gadget screenshot showing CPU frequency and utilization during a build of the Swift compiler
Typical CPU utilization when all six cores are maxed out. The CPU frequency stays constant at 2.9 GHz.

No erratic thermal throttling

This pattern remained remarkably consistent throughout the full 39-minute run. As soon as the core utilization dropped the frequency shot up, and vice versa. There was no sign of erratic thermal throttling, although I suppose the fact that the maximum turbo boost frequency never reached the advertised 4.8 GHz is a sign that the MacBook Pro enclosure can’t dissipate enough heat to take full advantage of the i9.

Here are a few more screenshots taken at various stages during the build process. You can observe the pattern in all of them:

Intel Power Gadget screenshot showing CPU frequency and utilization during a build of the Swift compiler
Full six-core utilization for an extended period. The CPU frequency doesn’t drop below 2.9 GHz.
Intel Power Gadget screenshot showing CPU frequency and utilization during a build of the Swift compiler
As soon as utilization drops to a single core, the CPU frequency shoots up and the CPU draws less power. The CPU temperature remains more or less the same throughout.
Intel Power Gadget screenshot showing CPU frequency and utilization during a build of the Swift compiler
This screenshot shows that the turbo boost frequency went up to ~4.4 GHz. It’s at 4.33 GHz at the time the screenshot was taken.

Finally, note that the discrete GPU was essentially idle during this test. It was active because I had an external monitor connected, but it had nothing to do except drive the macOS UI.

Xcode build times

A clean build of one of my current projects (mixed Swift and Objective-C), run from the command line using xcodebuild (because the times are easier to record this way):

2018 MBP 2013 MBP Δ
115 s 137 s 16 % faster

Running the project’s test suite on the iOS simulator with xcodebuild test. This is a mix of unit tests and a few UI tests:

2018 MBP 2013 MBP Δ
127 s 135 s 6 % faster

Unzipping Xcode

Extracting Xcode-beta.xip using Archive Utility (tested with Xcode 10 beta 6):

2018 MBP 2013 MBP Δ
6:02 min 6:39 min 9 % faster

Static website build

A clean build of this site using Middleman.

2018 MBP 2013 MBP Δ
8.3 s 10.3 s 19 % faster


Performance-wise, I’m a little disappointed. With the jump from four to six cores and a significantly faster SSD, I expected a bigger jump from my old machine. Interestingly, the Swift build does show a very signficant speedup.

And I do notice fewer and shorter lags while working, which I partly ascribe to the SSD. For example, Xcode is faster at relaunching with tons of open windows/tabs after a crash, and you don’t have to wait as long for inline compiler diagnostics to appear. Working with my giant mind map of Swift notes is fast again. I don’t think this is all in my imagination.

Ignoring performance for a minute, I like the new MacBook Pro better than I expected. Not because of the touch bar, but because of USB-C and the great (in my opinion) keyboard (as long as it doesn’t break).