Five minutes of some trivial testing shows that this is just not true.

Noise is still affected by input gain

Here’s a composed recording of four 3-second clips recording the room tone in my office. They are (in order): Auto gain, 57dB, 35dB, 0dB:

As you can hear, auto and maximum input gain in this case have very similar noise levels (which is to say, perceptually none), but as you reduce the recorder’s input gain (and instead apply the gain in post) the noise increases substantially and becomes very noticeable.

Granted this is a very big gain application – 57dB – which you would hopefully never need to apply to a real recording, but nonetheless it demonstrates that Tascam’s claims are exaggerations at best; if you actually had the Portacapture X8’s input gain set to 0dB and recorded quiet sounds, you would in fact have problems with noise – problems that would be avoided with a correct input gain setting.

Clipping still happens if input gain is too high

The recorder clearly applies actual analog amplification and can still saturate its ADCs, as shown in this composite of three gain levels. They are (in order): Auto gain, 35dB, 57dB.

Warning: annoying, distorted sound.

It only went over by about 3dB (at 57dB input gain), but that was enough to destroy the input signal and make the recording unusable.

Auto Gain still affects the recording

In the above tests I included the Auto Gain setting, even though it doesn’t exhibit particularly high noise nor does it clip in these simple sound environments (basically constant sound levels). And it worked pretty well (not optimal input gain levels, but close enough for my taste).

But, I was curious if it had any effect at all – again, reading about 32-bit floating-point recording online, you’d be forgiven for thinking Auto Gain has no impact on the actual recorded data. Many people liken the format to camera raw files, and some explicitly state that Auto Gain has no impact on the bits that get written to disk.

This is completely false, at least in the case of this Tascam Portacapture X8. It’s trivial to see why:

Auto Gain still does exactly what it always does – it changes the gain in response to the input. That change is baked into the recorded audio track(s).

So in a nutshell, 32-bit floating-point recording might provide slightly more flexibility in some situations, but it does not mean you can ignore your input level settings, it does not mean you can use Auto Gain in every scenario, and it does not mean you cannot clip.

Addendum: Technical details

I tested post-production gain changes in Final Cut Pro, Logic Pro, & Audacity. All produced the exact same results (to my ears). I had read that Final Cut Pro sometimes ‘bakes in’ clipping with 32-bit float inputs, as if it’s pre-rendering them down to some smaller dynamic range, so I wanted to rule out some Final Cut Pro-specific stupidity. It’s possible that all these editors are doing that, but I’d be flabbergasted if that’s true.

The “industrial noise” sample I used was my dehumidifier, which is about 66dB according to DecibelX on my iPhone 14 Pro. My office room tone is about 42dB according to the same app.

I used Sennheiser K6 modules with an ME65 and ME66 attached, plugged into the Tascam Portacapture X8 via 3′ Cable Matters XLR cables.

I recorded at 96kHz because that’s what I’ll use most often. I like the aliasing headroom above 48kHz (even though of course my final outputs are almost always 44.1kHz or 48kHz), but don’t see evidence that 192kHz provides meaningful additional benefit (and it also hurts the frequency response significantly, compared with 48kHz and 96kHz, according to Tascam).

Spoiler: not much has changed. Kagi does a bit better, but Bing is still the best, Google still sucks, and ChatGPT (when considering Bing Copilot as well, that’s based on it¹) is sometimes good, when it’s in the right mood.

Broadly, these results are pretty close to my general experience and impression. LLMs continue to be mediocre at best at factual work (but can be very interesting for creative work). I find Kagi usually does at least as good a job as Bing in terms of content relevance and correctness (and wins handily on the tie-breaker of not being based on a dodgy business model nor burdened by an ugly GUI).

As a side- but important note: it’s incredibly brazen that LLMs, like Bing Copilot, claim they’re not just monumental copyright infringement machines, when they produce results that accidentally include the raw markup from whatever they’re plagiarising, which they clearly do not understand and did not originate themselves in any ethical sense. It’d be funny – for its absurd ineptitude – if it weren’t so despicable.

Kagi

I’ve been using Kagi for five months now (2,542 searches so far) and like it (mostly²). Kagi’s results aren’t always stellar, but it’s clean and pretty reliable and – like Rob – I like the simplicity of their revolutionary business model: they provide a service, that I pay for.

Because this query ends with a question mark, Kagi (as of earlier this year) adds its LLM-based “Quick Answer” section to the top of the results. Which isn’t all that helpful – it does technically give the answer, but only four paragraphs in. It does include citations, at least (although half of them are unhelpful, like most of its LLM-generated text).

The Wikipedia excerpt to the right provides the answer succinctly in its first sentence (and that same result is included organically in the third search result, but only barely makes it above the fold on my 27″ screen). Note that I’ve configured Kagi to prioritise results from Wikipedia (since in my experience those are, where available, greatly more likely to be useful than everything else – and I’m not the only one who thinks so).

The answer is at least on the first screen of search results, which is much better than Rob saw a year ago.

DuckDuckGo

Most of the results are unhelpful (and the StackExchange question highlighted on the right is basically gibberish because it’s showing the raw markup of a bunch of maths). Two thirds of the way down the screen, it finally links to the Saylor Academy PDF with an excerpt that answers the question (followed by a link to the relevant Wikipedia article, likewise with the key excerpt inline).

It wastes a whole bunch of space with links to YouTube videos, including thumbnails and GUI chrome.

So, mediocre at best. And from the sounds of it markedly worse than a year ago, when Rob tested it.

Google

By default, the first screen doesn’t answer the question at all. In fact, most of the screen is wasted with:

1. A “Questions & answers” section pulling from StackExchange and QuestionAI, with excerpts that are too short to actually convey their substance.
2. A “People also ask” section, that does nothing to answer the question.

There’s only two actual search results on the screen, neither of which answers the question.

So, a plain bad result. Same as a year ago.

When I switch to “Web” mode, the results improve to merely mediocre – the third and fourth results are relevant (it’s the Saylor Academy & Wikipedia again), but the rest are not.

Bing

By default – if you’re not signed in and haven’t clicked through the Bing Copilot EULA – the results are decent. The very first substantial thing is a highlighted result from the Saylor Academy, with a relevant excerpt. That’s great. But the rest of the screen is rubbish – the remaining results are irrelevant, and the screen is visually very noisy – in particular, the right-hand bar includes a whole bunch of GUI chrome and images, and adds absolutely no value here.

If you click through the Copilot EULA and try again, the results improve substantially. Now you get the most accurate answer of all the results in big, bold text right up front – “Not necessarily”. It then elaborates slightly by defining what the order actually is. It also includes three citations, all of which are relevant and helpful.

The rest of the screen is garbage, though. And still very visually noisy and distracting.

So what I’d tentatively call a good result – it’d be a great result if it did away with the irrelevant junk.

Bing Copilot

You can talk directly to Copilot if you wish, with a standard “chat” interface as popularised by ChatGPT.

The results are a bit varied.

Sometimes you get a decent, properly-cited response (ignoring minor errors such as about how group order is denoted symbolically). Though, the result reads pretty similar to Wikipedia’s article – to my eyes – yet Wikipedia isn’t cited at all (which is both borderline dishonest and also unhelpful, since the Wikipedia article is a much better source than StackExchange).

So, a decent result although not as good as what you get with simple Bing Search (with or without Copilot helping there).

But, sometimes you catch Copilot in an overly chatty mood, and the result – while still starting out good – tends to be verbose and tangent-heavy. Apparently Copilot thinks the tangent is “an interesting topic”, but I don’t because it’s not relevant to what was asked. Note also how it fails to render the mathematical notation, instead just displaying Latex markup which renders it into gibberish.

Oddly, at other times it does render mathematical notation correctly. Well, somewhat – the unnecessary line breaks are a dubious formatting choice.

In contrast to all this unpredictability, the Bing Search results were basically completely stable. And they’re better anyway. So a tolerable but uninspiring result from Copilot.

ChatGPT

A decent result in terms of answering the question, but there’s not a single citation. When I prompted it for citations it pointed me towards three algebra textbooks, all of which are actually real books and probably are technically relevant. But it doesn’t even cite a specific chapter, let-alone page. A clearly inferior result to Kagi & Bing Copilot.

Interestingly, the text of the answer is very similar to what Rob got a year ago (which was presumably with ChatGPT 3.5), at least in its first couple of sentences. I suppose I shouldn’t be surprised the answer is similar – since it’s merely remained correct and pretty helpful – but apparently I expected it to be much more unpredictable in its quality and content over time.

As far as I can tell – not knowing much about the mathematical notation in play here, or formal group theory in general – its answer is correct this time, without comically bogus examples like Rob saw. It’s nice that it [continues to] provide specific examples of where the LCM of the elements’ orders is and isn’t the group order.

Note that I’m using the free version of ChatGPT (version 4o, at time of writing).

1. At least, so says Wikipedia. Copilot itself categorically denies it’s based in any way on ChatGPT or OpenAI’s work, which seems pretty obviously a blatant lie. Unless it’s not just Wikipedia but CNet that’s lying, or, you know, Microsoft themselves. ↩︎
2. Admittedly I am getting rather tired of its bugginess on iOS, whereby it’ll randomly stop working; I’ll enter my search query into the Safari address bar, and be greeted with a login dialog for Kagi. Even if I log in, my search query is lost and I have to start over again (which is super infuriating for non-trivial queries given how tedious and error-prone iOS text entry is 😤).
   
   And it makes me do this for every search.
   
   This problem has come and gone over time, suggesting it’s some problem with the Kagi app or website. I wish they’d hurry up and just permanently fix it. ↩︎

I had intended to just buy an Apple Vision Pro on release day, but by the time I woke up and went to Apple’s online store – a couple of hours after pre-orders opened – they were showing a nearly two month shipping delay (and no in-store pick-ups at all). So I figured there was no point ordering then; like it or not I’d have plenty of time to see what others think first.

Of course, it turns out it was not in fact massively out of stock. I later found out that people had ordered theirs later that day, or even the next day, and were still included in the very first shipment. Nobody had to wait two months for theirs, even if they ordered weeks later. Apple’s online store was full of shit.

But I’m glad for it, because as soon as I was resigned to not ordering one, I was at ease with that decision. I felt oddly relieved. Having since read & listened to many people’s impressions & commentary, over the last month, my confidence in that decision only increased. And now that I’ve tried one for real, I am certain of it.

The Good

Ease of use

I found the interface to be pretty intuitive. Eye tracking worked very well, and gesture recognition was fairly reliable – neither were perfect, but then mouse tracking and “the key I meant to press” tracking isn’t perfect either. 😉

It’s hard to say with any confidence from such a short use of the Vision Pro, but my impression is that its eye & gesture tracking is at least as accurate as touch on iPhones, iPads, and Apple Watches. My Apple Watch & iPhone routinely reject my taps just to spite me (they animate the GUI to show that they know that I did tap, yet they refuse to accept it).

Which is to say, I suspect it would annoy me at times with its errors but I don’t think it’d be a barrier to long-term use.

Sound

One thing which I did not remotely anticipate is how good the sound isolation is – even more astounding given there’s nothing in or on your ear to provide a physical barrier. There were dozens of people in the Apple Store, including several pairs right around me going through their own Vision Pro demos or iPhone upgrades, and with the headset on I barely registered any of their conversations.

I find it hard to believe it’s due to traditional noise cancellation methods, just given the physical position and arrangement of the speakers, so this might be as much a psychological ‘trick’ as anything. In any case, it is effective.

I was also impressed by how well 3D audio worked (and how good the sound quality was in general). Better than AirPods (and Beats Pros) in my experience, although that’s a low bar.

I’m less sure how the Vision Pro’s speakers stack up against real headphones – even my aging Sony MDR-ZX780DCs – but it’s at least a reasonable comparison, which is impressive given the Vision Pro’s speaker’s form factor.

Real world view

When the Vision Pro was first announced I was a little disappointed that it uses cameras to ‘fake’ transparency, rather than using genuine optical transparency. Nonetheless, I was happy to see that the effect is mostly sufficient.

It wasn’t hard to find flaws if you looked – the cameras are not correctly placed to actually see what you see, for example, so any objects closer than about a metre have noticeable parallax errors. That’s very noticeable if you do something as simple as move your hands in front of you, even at arms length.

Yet, looking around the real world worked fine in practice. There is perceptible lag, but only barely – not enough to really cause any issues; you’re not going to accidentally walk into moving objects, for example, and you could probably even play [real] sports with the Vision Pro on (although you wouldn’t be doing yourself any favours).

I should note that it was in no way realistic because you’re clearly looking at a resolution-limited computer screen (more on that later). And I didn’t even test things like dynamic range or optical aberrations of the lenses, as I was in a very evenly lit and low-contrast Apple Store.

Immersive experiences

I didn’t get to do the butterfly & dinosaur one, which is a shame because by all accounts it’s particularly good, but I got the quick demo reel of spherical videos (along with a couple of “3D” photos & videos). It was a bit hit & miss (more on that in later sections), but there were a few moments where I was actually pretty pleased with the experience. I’ve visited Haleakalā a few times but never seen the crater – the weather has always conspired against me – so I actually got lost for a minute or so just enjoying that view. The subtle animation of the mist drifting up & down the crater walls was a sublime touch. Likewise the gentle rain on the lake near Mount Hood.

The 3D video of a kid blowing out the candles on their birthday cake worked relatively well. The feeling of depth was nice – aided by the cake being very close to the camera and the use of a wide angle lens. I suspect wide-angle photos are much more amenable to the “3D photo” effect (they’re often described as more immersive even in plain 2D – although I think that effect is exaggerated by many people).

Human intrusions

The way people very subtly appear when you look in their direction while in full VR mode was quite nice. I like that they are visible but remain faint apparitions. I had received the mistaken impression from second-hand accounts that intruders appeared largely opaquely; much more obtrusively. The implementation strikes a good balance in providing awareness – and facilitating communication – without interrupting more than necessary.

Physical comfort

It’s of course very hard to deduce the real-world comfort of the Vision Pro from a mere fifteen minute session, but for whatever it’s worth I didn’t have any issues regarding weight, size, or contact. The headset certainly wasn’t unnoticeable, but I had no issues forgetting about those aspects while using it.

Also, it wasn’t until I was mostly done writing this article that I even remembered that the Vision Pro has a cable sticking out of it. The battery pack stayed on the table in front of me, and the only time I noticed the cable – even in the slightest – was when putting the unit on (merely because I had to make sure the cable wasn’t tangled around my head). I was expecting to feel the cable tugging and pushing on the headset during use, but did not.

This is in stark contrast to the power cable on my MacBook Air which is constantly getting snagged and yanked by my apparently villainous couch. So I’m very curious how the Vision Pro would work in a more typical environment, rather than at the Apple Store with basically nothing but empty space around me as I sat on a stool.

Minimal internal lens flare & reflection

At least in the bright Apple Store, I didn’t find the lens flare & reflections to be distracting. They are present, but I really only noticed them on the very first screen, where you’re in a black void and thus of course any such optical imperfections are most visible.

This is pretty good, by my estimation, since I find sunglasses to be irritating due to seeing the reflection of my own eyeballs in them. The Vision Pro has the big benefit of the [mostly] enclosed mask, to largely eliminate external sources of light. So it should have far fewer issues with flare & reflections, as a matter of principle.

The main reflection I did notice – and had a slightly harder time ignoring – was the glow of the screen on the inside of the light shield. It’s a pity Apple used a grey, textured material for the interior, rather than something dark like Musou black fabric.

Still, unless you plan to work in a very dark or high-contrast VR environment – perhaps the moonscape that I tried briefly during the demo – you should be fine in this respect.

Real world geometry is no limit

Folks have unanimously stated that – surprising or not – there’s no visual incongruence with pushing AR elements “through” real-world ones. One of the first tests I did was to grab a window and shove it through the table in front of me. Despite clearly violating all logic, my eyes & brain apparently had no issue with it – it didn’t feel wrong, or weird, or uncomfortable.

So – while I didn’t test it – I can easily believe that you can indeed watch a movie on a [virtually] cinema-sized screen despite being stuck in cattle class on a plane. And I can imagine it would be a genuine emotional benefit to have that feeling of so much more personal space, even though it’s “fake”.

Honestly, if I were to get a Vision Pro its use as an aid to commercial air travel might actually be one of the most justifiable reasons.

The Bad

Buggy demo units

My time actually using the Vision Pro was significantly shortened by the demo unit refusing to reset properly. It took three attempts – and a consultation between Apple Store staff – before they finally got it to work properly.

On the first two usage attempts it went straight from the “hold down the crown button to shift the lenses” to the home screen, bypassing eye tracking calibration. It didn’t seem particularly unusable without proper calibration, but my Apple handler refused to start the demo without it.

Bad light seal

Perhaps it’s just me and my apparently tiny nose, but there was a big gap between the unit and my nose. I could easily look through and see the table in front of me, my own lap, etc. This surprised me given Apple themselves have put a lot of emphasis on the importance of a good fit and no light leaks in order to have the proper experience.

However, in use I didn’t find it much of an issue – I wasn’t distracted nor blinded by the light leaking in. I think as long as my focus was actually on the screens of the Vision Pro, and my attention on whatever I was looking at within them, it was okay. Although, just like the glare & reflections within the lenses, it may not be so easy to ignore in a dark VR environment.

Non-immersive experiences

Most of the 3D photos & videos I saw didn’t do much for me. I can clearly see the appeal in theory, but the implementation on the Vision Pro is frustrated by several factors.

For a start a lot of the 3D photos – and especially videos – were blurry outside of the centre¹. Really blurry, in the case of the Alicia Keys clip – she was reasonably in focus but almost everything else was way out of focus. I think in the original recording, although I guess I can’t be sure that it wasn’t buggy foveated rendering or somesuch.

Second, even when they weren’t blurry, they were often low resolution. Hard to say whether this is because of the Vision Pro itself (more on this later) or with the source materials.

I was hoping that the panoramas would be a big (pleasant) experience, as I’m quite a fan of taking panoramic photos (and photo spheres) even though you can’t really view them well on fixed displays. In a way I’ve been waiting and preparing for VR goggles for decades. Heck, I was super excited when Quicktime VR was released, even though it turned out to unfortunately be decades ahead of its time.

Yet, I was a bit disappointed with the panorama experience on the Vision Pro. I’m not entirely sure why, although I know one obvious reason was that you can see the edges. Any illusion of being there is rattled when the edge of the photo appears in view. Photo spheres are the better way to go.

Seeing the edges might sound trite – after all, we see the edges of photos and videos all the time on our existing displays; what’s the problem? It’s a good question – I don’t know if I can explain it, I just know what I felt. Perhaps it’s an uncanny valley sort of problem – because you are in a nominally immersive, VR environment, it matters so much more when the illusion is shattered. Perhaps it’s something you get used to?

In any case, even for photo spheres the feeling of immersion is compromised by the field of view being way too small…

Limited field of view

I had heard that the Vision Pro has a limited field of view – even compared to its contemporaries – but I was still surprised to see what that’s actually like. It’s even more limited than I expected. It’s like wearing bad goggles – blinkers, perhaps. A kind of tunnel vision. I’ve heard it said that you “just” need to keep your eyes centred and move only your head instead, but even looking dead ahead I clearly perceived the outline of the screens, and it took some effort to ignore that (mostly successfully).

As noted earlier, this kinda ruined any would-be feeling of immersion for me, in most cases. You’re not much more “there” than you are viewing a photo in a picture frame (or on a traditional screen), or watching a video on a TV placed too far away.

Everything’s too close & big by default

I was surprised that windows open way too close (in perceived depth) and too big (in field of view) by default. I was constantly manually resizing things and pushing them away from me, in order to actually be able to see them [fully] and comfortably.

I do not like having to move my head just to look around a single window, it turns out.

I also found it quite unintuitive that windows enlarge as you push them away, maintaining the same angle of view. It was not only annoying – since the whole point of pushing them away was to make them smaller and feel less claustrophobic – but it made it hard to actually judge if & to what degree they were moving. More than once I repeated a “get back” window movement because it seemed like the first try was silently ignored (and honestly, I can’t be sure it wasn’t – that’s the point).

3D movies

I watched the brief trailer for Super Mario Bros. I didn’t really get much of a 3D effect, but I did get the very limited field of view (see prior point) and poor visual quality (see below). I’m actually a bit bullish on 3D movies, but I think we’re still just not there technologically².

I do like to have a big screen – such that my vision is pretty filled by a movie – but apparently I really don’t like it when there’s a black mask over the outskirts of the movie. Even if it’s only visible in my peripheral vision.

Possibly I’d get used to this in time, but of course I don’t really want to – I should be able to see the whole movie. Otherwise, what’s the point? If the director wanted me to see only a subset of the view, they’d have filmed it that way.

I presumably could also have manually moved the window back – and I did for some of the other videos I watched – but it’s just not practical to have to do that for every video I ever watch.

Perhaps the problem is in taking existing movies – designed for a relatively tiny field of view (≤40° typically) – and naively shoving them in your face in the name of immersion. Maybe what we need is to add new content around the existing frame. Despite our huge angle of vision, our focus area is actually quite small. It’s uncomfortable and confusing to have to look around frequently and rapidly just to make sense of a movie.

The Ugly

Very blurry & low resolution

I was really surprised to see pixels. Immediately. Even though I was already aware – mainly from John’s stumbling over the topic on ATP – that the PPD (Pixels per Degree) is actually quite poor on the Vision Pro, at just 34³. A “Retina display” at typical viewing distances is around 100. Even an ancient non-Retina Apple display is about 50.

In fact, 34 is about the same as an original Macintosh from 1984. 😳

I found this handy calculator for determining PPD, in case you want to estimate for your own devices. If you have a 5k 27″ monitor, for example, but typically sit with your nose about 4cm from it, then you’re already used to the Vision Pro’s display resolution⁴.

Furthermore, unlike the original Macintosh’s screen – which at least had quite crisp pixels – the Vision Pro is blurry as well. That surprised me less – I figured there might be some calibration required, which was perhaps unintentionally skipped by the buggy demo unit. But my Apple Store handler didn’t seem to think so, yet seemed surprised by my comments (that the view was pixelated and blurry). He had no real answer to that. He implied (by omission) that my experience was normal. 😕

Jittery

The other thing I noticed within a literal second of using the unit is that the artificial visuals jitter – jump randomly about by a pixel or two. All the time. It’s less noticeable in full VR mode where you have no objective reference in the form of real world objects, but in AR mode everything displayed by the Vision Pro is shaking. I was able to mostly ignore it throughout the demo – but only with conscious effort. Any time I let my mind or vision wander in the slightest, the shaking immediately bothered me once more.

To be clear, this was while sitting perfectly still. I didn’t really test actual lateral movement of the headset, as I was asked to stay seated for the entire demo.

Since everything you see in the Vision Pro is technically artificial – it’s all from opaque LED screens, even the view of the real world that’s piped in view cameras – this jitteriness is baffling. I’m pretty sure it was the virtual objects that were moving, not the feed from the real world – just based on my own perception of what was and wasn’t moving – but I have no explanation for why that would be the case. While I could sense a tiny bit of a lag in the real world view, it seemed to remain correctly positioned (and stably positioned, more to the point) relative to objective reality.

It’s hard to say from just fifteen minutes of use, but I suspect this jittering would contribute significantly to eye strain.

Eye strain

When I took the Vision Pro off, my eyes were immediately assaulted by [comparatively] bright light and much sharper everything. It was both uncomfortable and a relief.

It took several minutes for my vision to de-blur. It’s a very similar experience to looking through the viewfinder on my Z9 for an extended period. And similarly it took a good couple of hours for my eyes to get fully back to normal, and to stop feeling strained.

Based on that parallel experience, it seems very clear that I cannot use a Vision Pro for any significant amount of time, without serious eye strain that causes lasting blurry vision and headaches. 😣

I’m assured by my optometrist that my vision is actually excellent – much better than average for my age, and I’m not that old yet anyway – and I’ve never needed glasses for anything⁵. So I don’t think the problem is me. I think the problem is quite apparent from the facts: the Vision Pro simply has a very low-resolution, unstable display that is uncomfortable to look at.

So now what?

Now I wait.

If I’d decided to develop apps for the Vision Pro, as a business choice, then it’d make sense to own one – it could be considered a dev kit; an early prototype. But for now I’m content not to. There doesn’t seem to be a rush – the app market is comparatively tiny.

For personal use it makes no sense to get a Vision Pro. Aside from its novelty factor and some very limited uses, it’s inferior to a Mac for almost all purposes (like productivity tasks, watching movies, reading books, video calls, etc).

Yet I’m hopeful that the AR and VR headsets’ times will come, eventually. Still at least several years from now, based on what I’m seeing with the Vision Pro. But one day.

I’ve been trying to discern if the Vision Pro is an iPhone moment or an iPad moment, since it was announced. I was bearish on the iPhone and bullish on the iPad, apparently at odds with the entire rest of the planet. And I’ve since conceded defeat entirely on the iPad – when I replaced my iPad Pro 13″ with a MacBook Air, it was such a relief – I finally had a device which I could use freely and broadly, rather than a glorified iPhone for web browsing and watching video. So I’m leery about getting too enthusiastic about a new class of device which clearly has some of the same existential challenges as the iPad.

One thing seems clear – it’s not a Mac moment. I don’t see anything with the Vision Pro that fundamentally changes the nature of computing, let-alone day-to-day life. But then, I don’t think it’s fair to expect it to – there’s only been one Mac moment so far.

1. This might be just flaws in the demo material, although it’s hard to imagine Apple letting that fly. I have to assume the Vision Pro itself is the limitation here.
   
   That said, in the “3D” video of the girl popping bubbles I saw what looked exactly like JPEG or MPEG compression artefacts (mainly blocking and over-smoothing). I can’t be certain whether that’s an issue in the video file or in its playback by the Vision Pro, but I would assume that graphical rendering glitches would appear somewhat differently…? ↩︎
2. Most immediately, we lack the display technology to show a 4K (or better) video in 3D, whether via a headset like the Vision Pro or traditional means like coloured or polarised glasses. But that’s merely the easy part – we also need real-time rendering of the movie itself, in order to do proper foveated depth rendering – i.e. so that if you look at something in the foreground or background you can actually bring it into focus, even if the director hadn’t planned on that. As best I can tell practically nobody is even working on that yet. 😕 ↩︎
3. Tangentially, it’s baffling how news media outlets like The Verge can shamelessly try to spin that as in any way good. Talk about drinking the Apple koolaid. 😠 ↩︎
4. And if you can actually focus at that distance, then I applaud & hate you, because I can only reminisce fondly about those days. Stupid aging. 😔 ↩︎
5. Although admittedly I can no longer focus on the end of my nose like I used to be able to do when I was a few years younger, so I know my descent into old-age far-sightedness has begun; I’m told I will need reading glasses at some point in my life (barring an unfortunate early exit). ↩︎

The built-in “code” block for WordPress (the CMS I use for this site) is virtually useless – it’s just a <pre> block, essentially.

The appearance may vary depending on WordPress theme, but will virtually always be bland.

In fact, it’s not even guaranteed to use a monospaced font – the example I’ve shown here is what you’ll probably get with any given WordPress theme, but it’s not actually the default for the theme I use (GeneratePress) due to a known bug in GeneratePress (which the theme authors outright refuse to fix!).

In any case, you have to use WordPress plug-ins to extend or replace it with something that actually looks in any way decent.

Unfortunately, Swift is a complicated language, even just at the “superficial” level of syntax highlighting. And most generally-popular syntax highlighting tools are both:

1. Focused on languages like JavaScript and HTML, not Swift.
2. Written in JavaScript or Ruby, with no access to standard tooling like the Swift Language Server Protocol.

Since I’m using WordPress for this site, Ruby’s not a good option (and I didn’t find any relevant WordPress plug-ins which rely on it, anyway). Hypothetically I could add a Ruby environment to my server and do static generation through it, but, ugh. It’s annoying enough dealing with JavaScript and PHP. If you’re going to go to that much trouble, you’d probably be better off actually using Swift (e.g. SwiftSyntax). And while I’d welcome a WordPress plug-in which does exactly that, alas no such plug-in exists today.

So, I spent way too much of my time trying out a bunch of the available WordPress plug-ins, and now I shall report the results so others don’t have to suffer [as much].

I’ve presented previews for both light and dark modes (but my apologies to dark-mode viewers that all the samples default to light mode – an unfortunate limitation of my CMS).

Baseline: Xcode

Syntax highlighting theming is a very subjective and somewhat personal preference. I really must stress this, as something to keep in mind as I critique these plug-ins based on my preference, which is pretty close to Xcode’s default theme.

I’ve tried to focus mostly on how well the plug-ins understand Swift syntax & grammar and what functionality they offer broadly, rather than which ones look prettier out of the box. Most have at least some degree of custom theming support, or at least permit unofficial theming through straightforward CSS overrides.

It is unsurprising that Xcode does by far the best job of understanding and correctly syntax-highlighting Swift code, of anything tested here. It has the advantage of being able to actually compile and analyse the code with full context – the example shown here has supporting type and function definitions “off-screen” – which WordPress plug-ins do not¹. While I set out on this exploration hoping to find something effectively as good as Xcode, I wasn’t really expecting to (and spoiler: I did not).

Allow me to call out a particular few things Xcode does right, that (as you’ll see) few if any of the WordPress plug-ins do:

• In short, it supports all Swift syntax. It correctly identifies all the keywords (and things that are not keywords but happen to be the same word, such as static properties called default as in the example code).
• It utilises not just colour but font and font weight. This permits it to effectively delineate things without having to use an excessive variety of hues.
  
  Some might finds its results comparatively bland with the default theme as shown here, in light mode especially, but it has other themes for those that want a more hue-centric approach, and supports a very good degree of theme customisation.
  
  The default theme doesn’t “demo” well (in light mode), in the same way that colour-accurate TVs look rather bland and unattractive in the showroom but are actually great in real-world use in your home.
• Even though it uses multiple font weights, it still preserves correct letter spacing.
• It understands DocC’s limited Markdown-like markup within documentation comments (and can even render them as properly styled text, although that’s not shown here).

I’ll also call out one thing which – in my opinion – it gets wrong, which is essentially not recognising custom type names. It renders them as plain text – no highlighting at all – yet gives special treatment to “built-in” types (from the Swift standard library) like String. It’s fine if it wants to distinguish between those two sets of type names, but it should use some kind of highlighting for both of them. Many of the WordPress plug-ins actually do a better job in this respect.

Common limitation: no Light/Dark mode support

One thing that none of these plug-ins do, that you would think they could and reasonably should, is explicitly support light / dark mode – even though most include both light and dark themes (some plug-ins even include light and dark variations of the same theme – so close!).

Instead, you have to pick just one theme. Furthermore, if you want proper light and dark mode support you have to pick a light theme specifically, to match WordPress’s default mode of light. This limits your control over the appearance in dark mode – and may make it difficult for you to find a theme which suits your aesthetic preferences in both modes.

WordPress itself doesn’t support light/dark mode – you have to² use 3rd-party plug-ins. Depending on which one you use, you might get viable automatic switching anyway. The several that I experimented with were all able to make my theme adapt actually quite well.

I initially used WP Dark Mode, but discovered it was buggy in that it would load pages in light mode first and only after the initial render would it switch them to dark, making browsing my site in dark mode very uncomfortable. It also didn’t work properly with SyntaxHighlighter Evolved. I consequently switched to Dracula Dark Mode which is a very similar plug-in but doesn’t have those bugs.

Note that most of the dark-mode screenshots shown here were taken while using WP Dark Mode. There may be slight differences in colours with Dracula Dark Mode (or some other dark mode plug-in), but in my brief experimentation the results are virtually indistinguishable.

The contestants

Code Block Pro

This advertises itself as using the syntax highlighting engine from Visual Studio Code, but that’s actually misleading – it uses Shiki, which is really its own engine albeit one that utilises the same TextMate-inspired grammar definitions and themes as does Visual Studio Code.

It’s open source and free for the most part – for a token $12 you can support the author and obtain a couple of dozen extra themes, adding to the two dozen or so that it includes by default.

Performance

If you’re familiar with Visual Studio Code for Swift development, then you basically already know how it performs, as the results are (in my testing) identical.

That’s only mostly a compliment, though. This plug-in, like Visual Studio Code, doesn’t really understand Swift, it merely does a relatively good job of faking it.

Unlike every other plug-in tested, where the grammar parsing is completely independent of the theming, the performance of this plug-in does vary between themes. Thus, some themes might have colours you hate yet be the only ones that actually identify Swift keywords correctly, while others are the reverse. This is demonstrated in the example shown here – the Light Plus theme – where the colours are the least ugly of the themes available but it doesn’t recognise some basic Swift syntax, like protocol conformances, which is recognised in other – albeit uglier – themes.

But, in general, it:

• Actually understands the difference between function parameter labels, parameter names, and parameter types.
• Tends not to recognise custom type names, only the Swift stdlib & Foundation ones (e.g. notice it doesn’t recognise Floor but does recognise String). This is somewhat common behaviour amongst the plug-ins tested (and Xcode itself).
• Doesn’t recognise some important keywords, such as async and some.
  
  As it happens, this is because the Swift grammar file it uses is quite a few years old and seems like it might be largely abandoned (other than sporadic community updates such as this which might or might not be incorporated by this plug-in). This is the same grammar file that Visual Studio Code uses, making it doubly-surprising, but I guess it says a lot about the level of interest the Visual Studio Code community has in Swift.
• Is not easily fooled by the use of ambiguous names, e.g. the default static property of HomeItem that’s often mistaken for the default keyword by other plug-ins.

Pros

• Includes the ability to highlight an arbitrary set of lines by blurring out all the others (but readers can mouse over the code block to unblur everything, if they want to see the full context of what you’re highlighting). This particular approach – blurring rather than just using a different background colour – is unique amongst all the plug-ins I found, and aesthetically far superior. Most of the other plug-ins don’t even have a way to highlight or hide certain lines.
• Uses server-side rendering with CSS inlined into the HTML, so code is highlighted right from page load without delays or visual glitches.
  
  Some other plug-ins tested here do server-side syntax analysis too, but to actually effect styling they use class tagging of HTML spans with CSS, which can mean rendering glitches if the CSS takes a while to load and the browser renders the code without it in the interim. Code Block Pro avoids that (and might also play better with other styling plug-ins or modifications, such as dark mode plug-ins).
• Has a live playground so you can easily test it out (although that playground is hard-coded to use the Fira Code font, which is only one of a number of open-source font options it provides).

Cons

• No global settings – if you decide to change any settings, such as the theme, at any point, you have to manually find and adjust every existing code snippet manually.
  
  This might be considered a positive by some users, where they want existing content to remain as-is. However, some plug-ins offer both a global setting and the ability to override that on a per-case basis, providing more flexibility.
• The provided themes – even with the paid expansion pack – are predominately intended only for dark mode, and most of the light mode ones are pastel. So if you want a clean light mode theme, as I do, you have only about three options with this plug-in.
  
  Furthermore, the performance varies between themes, as – unlike every other plug-in tested here – the themes are in essence tied into the parsing.
  
  None of the provided themes really do Swift justice compared to how well they work for other languages. Especially within the limited selection of light-mode themes, there’s precious few that don’t make obvious mistakes (like conflating the some keyword with operators, or being confounded by generics syntax).
• Theme customisation options are extremely limited, not just officially but even unofficially with custom CSS. Although, the author seems receptive to theme suggestions – to add to the paid expansion pack – if you find something you like in the Visual Studio Code Marketplace.
  • The only way it officially allows any custom theming is with an unusual mechanism documented only in a tangential GitHub discussion: you select the theme called “Use CSS Variables”, which is a ‘theme’ that merely specifies var(--xyz) values for the color CSS property. You’re then expected to specify values for those CSS variables in some suitable stylesheet (which the plug-in does not facilitate).
    
    This custom theming functionality is only available in the paid version.
  • It only officially supports adjusting the colours – you nominally don’t have the ability to adjust font families, sizes, weights, or styles.
    
    It is possible to match each type of element, but it’s pretty clumsy and fragile, because…
  • As mentioned under Pros, it inlines the style information directly into the HTML span tags, as simple color style attributes. While that’s good for avoiding rendering glitches, the downsides are that:
    • It produces more verbose HTML than if it just used a short class name on the spans (as all the other plug-ins do), which can hurt page load times.
    • It’s more difficult to customise the styling with CSS, since you have to match on the colours – using CSS attribute queries like span[style*=#xxyyzz] – which is not just awkward but can be impossible to do precisely for multiple distinct grammar elements depending on the base theme used.
    • It optimises the HTML by merging (server-side) span elements with the same style information. That’s great for reducing page size and load times, but if the base theme doesn’t already visually distinguish between two distinct grammar elements, it’s impossible to distinguish them through custom CSS.
• Custom themes don’t render in the post editor – you just get plain pre-formatted text. (built-in themes work fine in the editor)
• Uses a custom Gutenberg block type, rather than just extending the standard Code block. So you can’t just upgrade your whole existing site – you have to manually go through and find every existing Code block, and manually migrate each one.
  
  Inversely it’ll also be more difficult to migrate away from, if you choose to do that some day, as you’ll likely have to repeat that whole process no matter what replacement plug-in you choose.
• If you enable the ‘Copy’ button for the convenience of your readers, it includes a duplicate copy of the code in a hidden span (as do at least some of the other plug-ins tested, although I didn’t always call it out here).

So in a nutshell, if you’re completely happy with its built-in theme options, then this is one of your better options. But if you want theme customisation, it becomes worse than many of the other plug-ins, sadly.

CodeColorer

A very old – though nominally still maintained – plug-in uniquely based on GeSHi.

It’s open source and free (as is the GeSHi engine underneath it).

Neither the plug-in itself nor the GeSHi engine have seen a lot of activity in recent years (and confusingly the old GeSHi webpage is still up as is the early GeSHi page on SourceForge, creating an even worse first impression). Both predate the [public] existence of Swift entirely.

To be honest I’m including it here only for completeness. It basically doesn’t work – especially for Swift – and shouldn’t actually be considered. It seems intended solely for use via shortcodes – even though it does take over all existing <code> blocks – which I didn’t test as the use of shortcodes in WordPress is archaic, and poorly supported in the modern (Gutenberg) editor. They seem to still be officially supported, and not formally deprecated, but I think introducing any new reliance on them at this point is foolish.

Performance

So, yeah… no syntax highlighting at all. It’s not apparent to me if this is a failure specific to Swift or if the plug-in in general just doesn’t work. It does offer a [non-live] preview in its settings, which does work for its example snippet of JavaScript.

It also (by default) forces the code into a tiny box, although you can fix this through its settings.

There’s no per-use customisation since it just takes over any existing <code> blocks, and there’s very few global settings – including an absence of any setting for a default language.

I won’t bother trying to enumerate its specific pros and cons – it’s clearly not a viable contender.

Code Syntax Block

A simple plug-in based on Prism.js, with very limited customisation options.

It’s open source and free (as is the Prism.js engine underneath it).

Performance

Prism.js prides itself on being [relatively] small. Perhaps because of that goal of being “lightweight”, its performance is a bit mediocre.

The default theme makes it look even worse than it really is, because it bizarrely doesn’t provide any distinguishing styling for important things, like type names.

On the upside, it does get a few things right which other plug-ins often don’t – even others which also use Prism.js, curiously, like Highlighting Code Block. Things like it:

• Recognises @-attributes, such as macro and property wrapper invocations.
• Recognises relatively new Swift keywords such as async & await.
• Understands multi-line and raw strings.

On the downside it:

• Doesn’t recognise a lot of very basic Swift syntax – or, at least, doesn’t distinguish them with a span and therefore resigns them to the default, plain text styling of the overall code block – including but not limited to:
  • Variable names (neither their declaration nor references to them).
  • Function parameter labels & names.
  • Property names.
  • Tuple field labels.
• Doesn’t recognise method calls consistently (e.g. pack & reduce vs map in the example shown).

Although you can’t tell with its default theme, it actually recognises custom type names (although doesn’t distinguish them from Swift standard library types, like Xcode – though it’s debatable whether that’s a feature).

It uses font weight, not just colour, which would go a long way towards giving it higher fidelity without making it look garish if it didn’t use it really weirdly. Instead of bolding keywords, for example, it bolds function & method names – sometimes, when it recognises them correctly.

At least it defaults to Menlo, which is actually a respectable choice and makes it one of the few plug-ins tested that have a decent default for Apple platforms. In case you’re unfamiliar, Menlo was the default monospace font for Snow Leopard through Yosemite (before it was replaced by SF Mono). You’d most likely have encountered it in Terminal or Xcode, if you used a Mac in that timeframe (2009 – 2015). It’s still available on every Apple device (as of time of writing, December 2023).

Pros

• Extends the built-in, standard Code block. This makes it comparatively trivial to adopt if you’ve already got Code blocks on your website (although you may still need to go through and customise some things, such as the language in case auto-detection doesn’t work correctly).
  
  This also makes it easier to switch syntax-highlighting plug-ins, provided that the one you switch from or to also supports the standard Code block, which is sadly a minority of them.

Cons

• Hasn’t been updated in a year – possibly abandoned.
• Does everything client-side, so there’s a noticeable delay before syntax highlighting is actually applied (especially on first load, when the relevant JavaScript & CSS isn’t cached in the browser). It’s a bit visually jarring as the unstyled code is replaced with the styled.
• Adds its Prism CSS & JavaScript files to every page load, irrespective of whether the page actually needs them or not. This is the core Prism.js library only – the grammar file for each language is only loaded when actually needed.
  
  They are somewhat small files, at least – most of it is Prism.js at 30 KB alone, plus a few extra KBs for the chosen theme’s CSS. With Brotli compression they’re ~13 KB. Language grammar files tend to be only 3 KB or less.
• Very few built-in themes – only four – and using a custom theme is technically possible but awkward. The official instructions didn’t work for me, either – I had to use the WPCode plug-in to execute the relevant PHP:
  
  add_filter('mkaz_prism_css_url', function() {
    return '/wp-content/themes/prism-xcode.css';
});
• Theming is controlled globally with no ability to override it for specific uses.
  
  This is (IMO) better than not having any global controls at all, as with some plug-ins, but it can be problematic if you use more than one language in these code blocks across your website, as you might prefer different themes for different languages.
  
  You can technically work around this limitation using custom CSS, since the language is included as a class on the relevant pre and code HTML elements.
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.

Enlighter

The official WordPress plug-in for the EnlighterJS engine.

It’s open source and free (as is the EnlighterJS engine underneath it).

Performance

Generally it does a poor job, with Swift code, and it’s not really a mystery why – its grammar file for Swift is especially spartan and hasn’t been updated since it was created over five years ago! That’s the Swift 4.1 era at best.

It actually behaves very similarly to the SyntaxHighlighter Evolved plug-in, but with the significant difference that it leaves things it doesn’t understand as the plain text colour (e.g. black in Light mode), so it’s much more apparent even at a glance that it doesn’t really understand much.

For example, it:

• Doesn’t understand @-attributes, such as macro and property wrapper invocations.
• Has no idea about the difference between function parameter labels and parameter arguments.
• Doesn’t consistently recognise references to properties, such as when they’re part of KeyPaths.
• Doesn’t understand some important keywords, like async, await, Never, etc.
• Recognises only a limited selection of types – all from the Swift standard library – and has no idea about custom types.
• Doesn’t recognise method calls consistently (e.g. pack & reduce vs map in the example shown).

In a nutshell, it’s doing little more than picking out a pre-defined list of keywords, identifying string & numeric literals, and comments.

Though it does at least handle multi-line and raw strings correctly (albeit only in some themes – in a few it underlines strings and mistakes the indentation as part of the string, for multi-line strings).

The choice of Courier New as the default font is… brave. It’s not actually its preferred default – it favours Source Code Pro foremost, with Liberation Mono as a second choice. They’re both reasonable open-source monospace fonts, but neither are standard fonts on any Apple devices, and the plug-in doesn’t include them.

You can customise the font to a very limited degree – the plug-in provides only five options, none of which are standard Apple OS fonts so the choice is effectively pointless. Thankfully you can override its font choices, like pretty much all its styling, with custom CSS.

Pros

• Supports both a global theme setting as well as use-specific overrides.
• Supports both soft & hard wrapping (the latter meaning it uses a horizontal scroller if necessary, rather than fitting the text to the viewport – generally not what I recommend since it’s pretty hostile to small screens but it’s a notable feature to make this behaviour configurable).
• Includes a pretty extensive theme customiser, as an actual HTML forms-style interface in the plug-in settings pages. That GUI is ultimately just a bespoke configurator for the CSS – which helpfully it also provides, in case you want to save or serve that elsewhere.
  
  And if that proves insufficient – or you just prefer to do it manually – it uses a sensible system of spans with suitable classes, so it’s easy to write custom CSS for styling.
• Provides its own Gutenberg block, but can also optionally be applied to the built-in WordPress Code block, as well as potentially blocks from other plug-ins (Crayon Syntax Highlighter & CodeColorer are explicitly supported – unclear if it also supports Urvanov Syntax Highlighter, the ‘reincarnation’ of the otherwise abandoned Crayon Syntax Highlighter).

Cons

• Built-in themes are pretty limited and (IMO) pretty ugly, at least for the light-style ones (which is ten of the thirteen). The one demonstrated here is the default – just called “Enlighter” – which is about the best it has to offer. 😕
• Puts its settings item at the top level of the WordPress admin menu, rather than under Settings.
• Adds its CSS & JavaScript files to every page load, irrespective of whether the page actually uses the Enlighter block or not. Along with some inline JavaScript in every page header.
  
  And they’re not trivial files, either. The CSS is 80 KB uncompressed – ~10 KB with Brotli compression, larger with GZip or Zip (Deflate). That’s factoring in CSS minification, too. The JavaScript is 63 KB uncompressed (~19 KB with Brotli).
  
  It does offer an option to supposedly avoid this – “Dynamic Resource Invocation” – but it’s disabled by default, and still requires inclusion of a “small” 1 KB JavaScript file with every page load just to determine if the rest of the code & CSS should be loaded. So, kind of a hack to try to cover up a design flaw. Alternatively, you can disable automatic inclusion of the CSS & JavaScript files and handle that manually, but I can’t imagine anyone actually wants to have to deal with that.
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.

So, overall a pretty poor option, both in terms of how well it understands Swift – i.e. particularly badly – and how it looks out of the box. It does have a lot more options than most of the other plug-ins, and its GUI for theme editing might be a unique selling point for a – presumably rather limited – market of people that want to include Swift code on their website but aren’t comfortable writing CSS. Even that withstanding for argument’s sake, I think it falls solidly towards the bottom of the pile.

Highlighting Code Block

A relatively simple plug-in based on Prism.js, with limited customisation options.

It’s open source and free (as is the Prism.js engine underneath it).

Performance

Prism.js prides itself on being [relatively] small. Perhaps because of that goal of being “lightweight”, its performance is pretty poor – and pretty obviously so even at just a glance.

For example, it:

• Doesn’t understand @-attributes, such as macro and property wrapper invocations.
• Has no idea about the difference between function parameter labels and parameter arguments.
• Doesn’t consistently recognise references to properties, such as when they’re part of KeyPaths.
• Doesn’t understand some important keywords, like async & await.
• Doesn’t recognise method calls consistently (e.g. pack & reduce vs map in the example shown).
• Doesn’t understand multi-line nor raw strings.

On the positive side, it actually recognises custom type names (although doesn’t distinguish them from Swift standard library types, like Xcode – though it’s debatable whether that’s a feature).

It uses italics, not just colour, which goes a long way towards giving it higher fidelity without making it look garish. Unfortunately, its use of italics is weirdly inconsistent – e.g. it italicises some keywords but not all (e.g. final vs class), and italicises some type names but not others (e.g. VStack vs Image & Text).

It doesn’t take much effort to understand why – it’s using a very simplistic parser that knows virtually nothing about the language (other than a hard-coded list of keywords) and instead is just going off of capitalisation, mostly. Which is somewhat clever, and gets it a long way for such a simple method, but ultimately results in poor performance.

At least it defaults to Menlo, which is actually a respectable choice and makes it one of the few plug-ins tested that have a decent default for Apple platforms. In case you’re unfamiliar, Menlo was the default monospace font for Snow Leopard through Yosemite (before it was replaced by SF Mono). You’d most likely have encountered it in Terminal or Xcode, if you used a Mac in that timeframe (2009 – 2015). It’s still available on every Apple device (as of time of writing, December 2023).

It’s a bit weird that the performance is significantly different from some other Prism.js-based plug-ins, like Code Syntax Block. It’d be explicable if one plug-in were strictly superior to the other – suggesting simply use of a newer version of Prism.js by one than the other – but it’s actually a weird mix of improvements and regressions.

Pros

• Good bang-for-your-buck configuration options, which is to say that it has relatively few but it includes the essentials and with maximum flexibility (e.g. font customisation is by entering the actual font-family CSS string, rather than being limited to do a predefined short list of options as with most other plug-ins).

Cons

• Does everything client-side, so there’s a noticeable delay before syntax highlighting is actually applied (especially on first load, when the relevant JavaScript & CSS isn’t cached in the browser). It’s a bit visually jarring as the unstyled code is replaced with the styled.
• Adds its CSS & JavaScript files to every page load, plus some inline CSS & JavaScript, irrespective of whether the page actually needs it or not. This includes the entire Prism.js library with grammar parsers for every supported language, irrespective of which ones are actually used.
  
  And they’re not entirely trivial files, either – mainly because of Prism.js at 35 KB alone. Overall they’re 41 KB before compression (~18 KB with Brotli).
• Limited theming control – it has an unnamed built-in default, which you can override by specifying a server-side path to a custom CSS file (although functionally this isn’t much different from just putting your custom CSS in your website’s general custom CSS file, because of the aforementioned flaw whereby this plug-in inserts its CSS into every page load).
• Theming is controlled globally with no ability to override it for specific uses.
  
  This is (IMO) better than not having any global controls at all, as with some plug-ins, but it can be problematic if you use more than one language in these code blocks across your website, as you might prefer different themes for different languages.
  
  You can technically work around this limitation using custom CSS, since the language is included as a class on the relevant pre and code HTML elements.
• Includes support for a relatively small number of languages (by default), although that does include Swift and Objective-C, among many other popular languages. I list this as ‘con’ only in a relative sense – for most users its built-in shortlist is likely quite sufficient.
  
  You can provide a custom build of Prism.js if you need others, although it’s left as an exercise to the user to figure out how to do that (and to then maintain it).
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.
• Uses a custom Gutenberg block type, rather than just extending the standard Code block. So you can’t just upgrade your whole existing site – you have to manually go through and find every existing Code block, and manually migrate each one.
  
  Inversely it’ll also be more difficult to migrate away from, if you choose to do that some day, as you’ll likely have to repeat that whole process no matter what replacement plug-in you choose.

Prismatic

A uniquely versatile plug-in that supports both the Prism.js and highlight.js engines.

It’s open source and free (as are the Prism.js and highlight.js engines underneath it).

Unfortunately, it immediately disqualified itself by simply not working. After installing & activating it in WordPress, nothing happens. The built-in Code block doesn’t change, there is no new Gutenberg block (contrary to its documentation which claims it adds a “Prismatic” block), and nothing appears anywhere in the WordPress Admin menu, such as a global settings page.

I checked the PHP logs and found no mention of the plug-in nor any relevant log messages.

It’s unusual – in my experience – for a WordPress plug-in to just silently fail like this. While it might be possible to enable WordPress debug logging and ultimately figure out what’s going on, in my experience first impressions are indicative when it comes to WordPress plug-ins, so I’m not going to spend time trying to get a plug-in to work at all when it’s probable it’ll have numerous other problems anyway.

Syntax-highlighting Code Block (with Server-side Rendering)

Nominally a fork of Code Syntax Block that renders server-side instead of client-side, although it uses a different engine – Highlight.php instead of Prism.js.

highlight.php is a PHP port of Highlight.js. It’s unclear to me how closely or promptly that tracks changes to the original JavaScript library.

It’s open source and free (as is the highlight.php engine underneath it).

Performance

The default theme is particularly bland. It’s actually hard to judge its understanding of Swift purely from its appearance since so much of it looks the same.

It’s noteworthy as a particularly hostile plug-in (with its default theme) for colourblind viewers, due to its use of very similar shades for almost everything, and in particular its use of red vs grey in a way which makes them virtually indistinguishable to a significant portion of the population. It’s not the only plug-in to be thoughtless in this way, but it is the worst.

It does come with a lot of other themes – nearly ninety at time of writing – but you’d be forgiven for thinking it does not, as it puts the theme selection setting in a surprising location – the ‘Customize’ section of WordPress’s Appearance settings. While this actually makes tremendous sense, no other syntax-highlighting plug-ins put their settings there. It’s hard to hold that against this plug-in, for being the one plug-in which (arguably) does the right thing, but I almost overlooked this critical functionality – I only discovered it by chance because I happened upon its Advanced Usage documentation.

That all said, one thing the bland default does have going for it is that the visual sameness helps to slightly obscure how poorly the plug-in understands Swift.

For example, it:

• Doesn’t understand @-attributes, such as macro and property wrapper invocations.
• Has no idea about the difference between function parameter labels and parameter arguments.
• Doesn’t consistently recognise references to properties, such as when they’re part of KeyPaths.
• Doesn’t understand some important keywords, like async & await.
• Doesn’t recognise method calls consistently (e.g. pack vs reduce & map in the example shown).
• Doesn’t understand raw strings (though it does handle multi-line strings correctly).
• Is fooled by the use of keyword-looking names in places where they aren’t keywords, e.g. the default static property of HomeItem.

It’s pretty apparent, especially once you look at the HTML itself, that it’s doing only a rudimentary analysis mainly based on a hard-coded list of keywords and heuristics like whether words start with capital letters. That’s why it confuses literals (strings & numbers) with type names, function names with property names, and so forth. It’s not the only plug-in to try to fake it with such a simplistic algorithm, but it does the worst job of pulling it off.

It renders keywords in bold (like Xcode), which greatly aids readability.

Since it uses the built-in WordPress Code block as its basis, and doesn’t muck with the fonts, it defaults to whatever the active WordPress theme uses. As shown in this example, with GeneratePress, that’s not even necessarily a monospaced font! Worst, the plug-in has no built-in configuration option for font (although you can use custom CSS to override it).

Pros

• Extends the built-in, standard Code block. This makes it comparatively trivial to adopt if you’ve already got Code blocks on your website (although you may still need to go through and customise some things, such as the language in case auto-detection doesn’t work correctly).
  
  This also makes it easier to switch syntax-highlighting plug-ins, provided that the one you switch from or to also supports the standard Code block, which is sadly a minority of them.

Cons

• No official theming support.
  
  You can use custom CSS to re-theme it, thanks to its use of sensible class names for its spans, but other than fixing its bland default colours you can’t really improve it much, since a lot of the code is emitted as runs of plain text because of the plug-in’s very poor understanding of Swift.
• No global settings – if you decide to change any settings, at any point, you have to manually find and adjust every existing code snippet manually.
  
  This might be considered a positive by some users, where they want existing content to remain as-is. However, some plug-ins offer both a global setting and the ability to override that on a per-case basis, providing more flexibility.
• Very limited settings – just the language (if you don’t want to rely on auto-detection), which line(s) to highlight, whether to soft wrap, and whether to show line numbers.

SyntaxHighlighter Evolved

This is what I was using for years. It’s completely free and open source. It uses a proprietary syntax parsing system based on regular expressions.

Performance

It’s an interesting one, because it actually understands so little Swift syntax that most of it is bucketed together as ‘plain’ text. However, because it renders ‘plain’ text in a colour other than black, it gives the surprisingly convincing (at a glance) illusion that it understands much more than it really does.

Overall its rendering is close to Xcode’s, which is very surprising given its highly rudimentary grammar parser.

It is actually pretty good about identifying keywords – it actually gets async which many do not – but it doesn’t understand them with context, e.g. it mistakes the default static property of HomeItem with the default keyword.

It renders keywords in bold (like Xcode) which greatly aids readability, although note how (unlike Xcode) it messes up the letter spacing as a result (this is a result of the font used – Monaco – and thus can be fixed by overriding that with a better font, e.g. SF Mono).

While it covers up a lot of its ignorance with its clever colour choices, there’s still a few important things that it gets visibly wrong. For example, it:

• Doesn’t understand @-attributes, such as macro and property wrapper invocations.
• Has no idea about the difference between function parameter labels and parameter arguments.
• Doesn’t understand raw strings.

Its choice of Monaco as its font is… interesting, although modern versions of Monaco are thankfully a little smoother than their 1980s ancestor. That’s easy to override, however, via custom CSS in a suitable WordPress-generic stylesheet (the plug-in doesn’t provide any direct way to manipulate styling, beyond choosing from a short list of built-in themes).

Pros

• Most of its settings are global. So changing themes for a whole site is trivial.
• Uses sensible HTML structure and class names, so it’s easy to unofficially re-theme (although it has a very limited vocabulary of grammar, so you can’t greatly improve what you see here).
• Supports end-user editing of the code (with the syntax highlighting updating appropriately). This is purely superficial text editing – there’s no support for interpreting, compiling, or executing the code. So I’m not really sure what the point of this feature is, but I list it here since it is unique to this plug-in (amongst all those I tested).

Cons

• Doesn’t formally support light/dark mode (as do none of the plug-ins tested). Colours are fixed (to whatever theme you choose) irrespective of the end-user’s light/dark setting (again, same as all the other plug-ins). However, one difference versus all the other plug-ins is that this one doesn’t work properly with WP Dark Mode – it remains in light mode even while the rest of the page renders correctly in dark mode.
  
  I strongly suspect the fault lies in WP Dark Mode, not SyntaxHighlighter Evolved, but irrespective it is there and might be a deal-breaker if you’re particularly attached to WP Dark Mode.
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.
• Uses a custom Gutenberg block type, rather than just extending the standard Code block. So you can’t just upgrade your whole existing site – you have to manually go through and find every existing Code block, and manually migrate each one.
• Doesn’t get updated super often, although it has been around for years and has generally kept up with new WordPress versions, eventually.

Urvanov Syntax Highlighter

A fork of the abandoned Crayon Syntax Highlighter that uses its own syntax-highlighting engine.

It’s open source and free.

I almost didn’t include this because (a) it’s really very broken and (b) it doesn’t really support Swift at all. I strongly recommend against using it, for numerous reasons.

Performance

Pretty terrible, in a nutshell. I’m not going to go into full detail here because the plug-in is largely broken anyway (details shortly, in the Cons section).

Ironically it works better out of the box than if you actually configure it “correctly”; it doesn’t recognise this example as any specific language and falls back to some generic “Default” grammar parser. If you explicitly set it to Swift, the syntax highlighting actually gets markedly worse, and it’s no surprise why – its Swift grammar definition is nearly a decade old, dating back to Swift 1.0 in 2014!

One of its most egregious rendering problems is that it translates various special characters – [, <, >, etc – to their escaped HTML entities. This can be ‘corrected’ in its settings – it has a “Decode HTML entities in code” option – but that’s a hacky bandaid over the bug, that precludes you from actually using HTML entities in your code example (so you can’t use this plug-in for the HTML language itself).

Another rendering annoyance is that it makes the code block’s width 100%, irrespective of the actual width of the code. Most of the plug-ins do that, actually, but it’s much more apparent with this one because of its use of a visual border and alternating line background colours. You can configure a maximum width in its global settings, but (as with most of these plug-ins) there’s no (built-in) way to make it size to fit.

On syntax understanding itself, it basically has none. It simply recognises some fairly general syntax patterns, such as strings, literals, and parenthesis-indicated function calls. It doesn’t recognise most keywords, even.

Pros

• Very configurable – perhaps the most configurable plug-in tested. Beyond just theming options – including the ability to easily change the font from its default of Monaco – it includes options rarely covered by other plug-ins such as margin customisations.

Cons

• Nominally offers a Gutenberg block, but it doesn’t work – you cannot actually edit the textual contents, in the Gutenberg editor, and it doesn’t render at all on the actual published page. Thus you can only use the plug-in by having it take over existing <code> and/or <pre> blocks…
• Takes over all existing <code> and <pre> blocks by default, even those by other plug-ins, and those that don’t contain code at all (e.g. where you were simply presenting monospaced text such as Terminal output). You can configure this in the settings, including turning it off, but given the Gutenberg block doesn’t work, this is the only way to actually use the plug-in.
  
  
  
  I spent some time playing with different combinations of these settings, but many combinations are inexplicably unusable – they just result in broken rendering – and I couldn’t find anything that improved on the default behaviour.
  
  As such, this is an especially all-or-nothing syntax highlighter. It really doesn’t play well with others.
• Since it just takes over existing <code> and/or <pre> blocks, there’s no per-use customisation possible – everything is exclusively controlled through global settings, including the code language.
• By default adds its CSS & JavaScript files to every page load, plus some inline CSS & JavaScript, irrespective of whether the page actually needs it or not. This can nominally be corrected in the settings, via the “Attempt to load Crayon’s CSS and JavaScript only when needed” option, but I didn’t test it (and it’s not encouraging that it’s both disabled by default and uses the word attempt, both suggesting this feature doesn’t work reliably).
  
  And they’re not entirely trivial files, either, even though rendering is done server-side – its JavaScript is 65 KB alone! Its CSS is another 28 KB. With Brotli compression they’re ~18 KB. They compress well in part for the same reason they’re so egregiously large – the use of “urvanov-syntax-highlighter” / “urvanov_syntax_highlighter” prefixes on so many of the names. This bloats up the page source as well, with oversized HTML class names for every snippet of styled code.
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.

The winner

…is hard to pick unilaterally. Each plug-in has significant limitations or trade-offs. Which is best may depend on your personal preferences and specific needs.

Most of the plug-ins do a pretty atrocious job at actually understanding Swift, and at best for them it’s a question of how well they can fake it through clever heuristics and styling choices. SyntaxHighlighter Evolved warrants an honourable mention in this regard for doing a particularly impressive job despite its very limited brains. There’s a reason I used it for years with relatively few complaints, and if it hadn’t had issues with WP Dark Mode – before I realised WP Dark Mode was buggy anyway and had to be replaced – I probably wouldn’t have bothered doing all this competitive research, and wouldn’t be switching away from it.

The most common engines used by syntax-highlighting plug-ins are Prism.js and Highlight.js / Highlight.php, but frankly they’re bad at Swift – a situation that’s unlikely to change given Swift is such a niche language for them; they’re clearly focused on browser languages like JavaScript, HTML, and CSS. Even that aside, they tend to use client-side rendering which is slower and buggier.

It currently does a somewhat average job in understanding Swift and rendering it pleasingly – just like all the plug-ins tested – but it seems to have the most promising foundation, being based on the same grammar & theme files as are used by Visual Studio Code (and GitHub). So it has the possibility of significant improvements in future; at the very least it would make sense for the Swift community to focus on it since the benefits will be applicable not just to WordPress websites but also Visual Studio Code and GitHub.

Refinements to Code Block Pro

Every light-style theme available with Code Block Pro – including the paid expansion pack – has significant rendering errors for Swift, but after spending an egregious amount of time exploring the themes and experimenting with fixes for them, I’ve concluded that Light Plus is the least bad option. With some crude but simple CSS I’m able to adjust its appearance as shown here, which is loosely styled after Xcode’s default (light mode) theme.

I didn’t do much to accomodate Dark mode, limiting my modifications there to merely using SF Pro (“system-ui”) for comments. I don’t use Dark mode myself, so I might not have a good eye for what looks good there, but the default colours (from the simple inversion by the Dracula Dark Mode plug-in) seem alright to me. And pragmatically, I’d have to overwrite every colour used in the theme in order to ensure no rendering issues, and that’s a whole lot of CSS I don’t want to write nor bloat my page loads with.

I also turn on “Disable padding” in its “Extra Settings”, as by default it uses (a) hard-coded padding dimensions, in pixels and (b) padding, not margins. A strange choice, but at least it has the option to disable it.

div.wp-block-kevinbatdorf-code-block-pro {
	font-family: "SF Mono", SFMono-Regular, ui-monospace, monospace;
	width: fit-content;
	margin: 1em;
	
	& span[style*=\#0000FF], span[style*=\#AF00DB] { /* Keywords */
		font-weight: 675;
		color: #9B2393 !important;
	}
	
	& span[style*=\#008000], span[style*=\#81f179] { /* Comments */
		font-family: system-ui !important;
		font-style: italic;
	}
	
	& span[style*=\#008000] { /* Comments */
		color: #5D6C79 !important;
	}
	
	& span[style*=\#001080] { /* Properties */
		color: #3E8087 !important;
	}
	
	& span[style*=\#795E26] { /* Function names and argument labels */
		color: #804FB8 !important;
	}
	
	& span[style*=\#267F99] { /* Type names */
		color: #4B22B0 !important;
	}
	
	& span[style*=\#A31515] { /* String literals */
		font-weight: 500;
		color: #D12F1B !important;
	}
	
	& span[style*=\#098658] { /* Numeric literals */
		font-weight: 500;
		color: #272AD8 !important;
	}
}

What are other websites using?

I figured it might be helpful to look at what other Swift-code-rendering websites use, to see if there’s any I missed (there wasn’t) and which the community seems to believe is best.

• Swift by Sundell is using Publish and the Splash plug-in. Splash seems to do a pretty good job – clearly better than any JavaScript or PHP syntax highlighters.
• Hacking with Swift is using WordPress and ultimately Prism.js, although I’m not sure through which plug-in (possibly Code Syntax Block).
• Cocoa with Love might be using some Ruby-based platform or static generator, but it’s clear it’s using Rouge for syntax highlighting.
  
  Sidenote: Rouge seems to do a decent job of correctly identifying tokens and their types, although its underlying model looks pretty simplistic (it tends to default to the “n” class by default, meaning “name”, meaning it doesn’t really know if it’s a parameter label, parameter name, type name, etc).
• Donny Wals is using WordPress with the Syntax-highlighting Code Block plug-in, which uses Highlight.php (based on Highlight.js).
• Matteo Manferdini is using WordPress with the GeneratePress theme (same as this site, at time of writing) and ultimately Prism.js, likely through Code Syntax Block.
• NSHipster appears to be statically generated with a bespoke tool written in Ruby using a custom fork of Rouge.
• The old Swift Blog uses… I don’t know. Possibly a proprietary system, for both the platform and the syntax highlighting. I didn’t find any identification or indicators otherwise of any particular library.
• The newer Swift Blog uses… possibly the same mystery platform as the old one. But it does clearly use Rouge for syntax highlighting.
• Swift Evolution Monthly is hosted on Substack and doesn’t do any syntax highlighting at all!
• Swift with Vincent is hosted on Squarespace, which ultimately uses Prism.js.
• Swift with Majid is statically generated using Jekyll and uses Rouge.
• Swiftinit (by Dianna a.k.a. “taylorswift” / “tayloraswift“) uses a proprietary platform (written in Swift). The syntax highlighting is presumably also proprietary.
  
  Sidenote: there’s not a lot of syntax-highlighted code on Swiftinit (mostly it’s in some hidden blog posts from 2022), but what’s there looks pretty similar to what Rouge generates. It does a pretty good job of correctly interpreting the syntax, although there’s not a great deal of apparent fidelity – mostly it’s just dividing things into formal names (types, functions, etc), variables, keywords, and everything else.
• SwiftLee is using WordPress and the Code Syntax Block plug-in, which is Prism.js underneath.
• SwiftRocks is using Bootstrap and Prism.js.
• SwiftUI Lab is using WordPress and the Prismatic plug-in, which is configurable to either Prism.js or Highlight.js underneath; the site has elected to use Prism.js.
• TrozWare is using Hugo and Prism.js.
• Yet Another Swift Blog is statically generated using Jekyll and uses Rouge (though oddly I also see fragments of Prism.js and Highlight.js on the site, although I didn’t see any actual use of them to render code).

If you’re keeping score, that’s (syntax-highlighter-wise):

• Prism.js: 7
• Rouge: 5
• Unknown: 2
• Highlight.js: 1
• Splash: 1

And platform-wise:

• WordPress: 5
• Unknown: 3
• Jekyll: 2
• Proprietary: 2
• Bootstrap: 1
• Hugo: 1
• Substack: 1
• Squarespace: 1
• Publish: 1

It’s notable that not one is using Code Block Pro nor the underlying Shiki engine, even though (with the serious caveats mentioned earlier) they do the best job of actually understanding Swift.

1. Strictly-speaking not for any technical reason, as the plug-ins could run more advanced tooling on the server (as some bespoke CMS’s do), but I have not encountered any WordPress plug-in which does so. ↩︎
2. Technically you can do it with just custom CSS, by overriding your theme’s defaults inside a @media (prefers-color-scheme: dark) block, but this is likely impractical for all but the most simplistic and static WordPress installations – you have to be sure you catch every GUI element and colour. A good plug-in will dynamically rewrite the CSS client-side, ensuring everything is covered. ↩︎

★☆☆☆☆

I love the idea, but unsurprisingly – given it hasn’t been updated in over seven years – this no longer works. With my site, running WordPress 6.4.2, it broke it so badly that I couldn’t even login in recovery mode. I had to SFTP in and manually delete the plug-in to get my site back up.

It was immediately removed with the statement:

I have removed your review. Please do not use the review section for support.

Anonymous WordPress.org moderator

I think merely noting that an abandoned, seven-years-out-of-date plug-in is broken – and completely breaks WordPress if it’s installed & activated – is not unreasonable to note on the plug-in’s page. Putting that information in the Support forums is pointless since (a) nobody’s going to check those before installing the plug-in, and (b) it’s abandoned; there is no support.

Quite a disappointing move by the WordPress.org folks. 😕

Curiously, although the review itself was removed, it seems to still be counted in the stars histogram. Which is ironic since the 1-star rating is really not the important aspect of the review.

Addendum

Another review of mine was just removed by a different moderator for basically the same purported reason:

…you are 100% doing it wrong. Do not use a review to get support again.

Jan Dembowski

Seems a bit aggressive. I was, of course, not “getting support”, I was merely noting that another old, abandoned plug-in (LH Wayback Machine) only partially works now.

The first instance of this was disappointing but conceivably random, but this second removal suggests a systematic problem with WordPress.org’s review system.

The Apple Watch Ultra 2 changed essentially nothing about the underwater capabilities of the Apple Watch Ultra. It still does not support any kind of air integration – meaning, transmitter dongles attached to an HP port on your first-stage regulator that wirelessly report tank pressure to your dive computer(s). Air integration is super convenient and appealing as:

• It’s easier to read a bright, clear watch than most wired pressure gauges. Especially at a quick glance, which is important for encouraging you to check your air levels frequently.
• It can mean fewer hoses and dongles dangling about your person (although it’s not recommended to dive with a wireless gauge as your only air gauge, in case it fails during a dive even if only because the battery goes flat).
  
  At the least it means less fiddling with hoses, as you can tuck your old-fashioned backup gauge neatly away somewhere and typically never have to look at it during a dive.
• It allows your dive computer to issue alerts based on your air pressure. The most obvious of which is if your air pressure drops below a certain threshold (which you can typically configure based on your dive plan), but some dive computers have more advanced capabilities such as dynamically accounting for your current depth, air consumption rate, and decompression requirements.
• You can have multiple transmitters, representing multiple tanks (with potentially different mixes in them), all shown simultaneously together on a single screen.
  
  And they don’t even all have to be on your own tank. A popular configuration is for dive buddies to hook into each other’s transmitters so they can double-check each other’s air.
• It lets you log your air usage throughout a dive and for posterity. This can help you analyse your own dive fitness and behaviours, and optimise your air usage over time.

That the Apple Watch Ultra lacks this capability – tremendously appealing as it is to all serious divers – continues to be unsurprising, given the Apple Watch Ultra lacks many other features of advanced dive computers and is also a lot cheaper than most of them. Plus, the Apple Watch Ultra is designed for a much broader audience than just divers, and I suspect the vast, vast majority of Apple Watch Ultras never even go underwater outside of a bath.

I’d be very surprised if Apple add support for wireless pressure gauges at any point in the foreseeable future. And it’s almost certainly not a feature they could add retroactively to the first two generations, so if you have an Apple Watch Ultra (first or second gen) don’t hold your breath – if you want air integration, you need to get a different dive computer.

Alternatives

Most mid- to high-end dive computers support air integration, so if you have a favourite brand you can probably go with one of their offerings without too many issues. That said, there are two which seem most notable.

Shearwater Teric

These typically retail for around US$1,500 and are readily available online from Amazon, and practically every physical dive shop on the planet.

Shearwaters in general, and especially the Teric, are the dive computers I see most often amongst serious enthusiasts and professionals, and I don’t recall ever hearing a complaint about them (other than the same ‘complaint’ that I myself have, that I should have just bought the Teric to begin with rather than the Peregrine).

Shearwaters do work with 3rd party transmitters (and are often bundled with them), though it’s probably safest to use the official Shearwater Swift AI transmitter.

The downsides of the Shearwaters in general is that they omit some nice-to-have features, like heart-rate monitoring and GPS. But they’re not really intended to be used outside of the water anyway – they don’t have much functionality beyond a basic clock, otherwise – so you’ll typically pair them with a smart watch (like an Apple Watch).

Note that Shearwater recently released the Tern & Tern TX dive computers, which are (slightly) cheaper and lower-spec’d versions of the Teric that seem intended to fill out the price spectrum a little bit more, between the Peregrine and the Teric. Only the TX model supports air integration. I don’t see a compelling reason to go with the Tern TX over the Teric – and the Terns aren’t readily available from stores yet anyway.

Garmin Descent Mk2i

These typically retail for around US$2,000 and are also readily available online from Amazon. In my experience they’re not particularly common in physical dive shops (although you can likely have the shop order one in for you, in any case).

The main pitch of the Descent Mk2i over the Shearwater Teric is that it’s a more full-featured health & exercise watch, intended for full-time use in & out of the water, rather than as just a dive computer. As such, it incorporates all the features you’d otherwise expect from a Garmin smart watch, such as run tracking, heart-rate monitoring, GPS, etc.

I don’t recall ever actually seeing someone dive with one of these. Some lower-end Garmins, occasionally. Nonetheless the Descent line has been around for a long time and are well-reviewed. A big reason for their absence is that the Shearwater Teric has such a good reputation, strong market share, and is about $500 cheaper.

Beyond just price, however, the Garmin’s achilles heel – for iPhone users – is its more limited and less convenient integration to the Apple Health ecosystem, and Apple devices in general, compared to Apple’s own watches. To me it makes more sense to have an Apple Watch Ultra and a Shearwater Teric as you then have two dive computers, for extra safety. You can technically do a similar pairing with the Apple Watch Ultra and a Garmin, but it makes less sense since they’re more direct competitors, and it’s a substantially more expensive combination for little additional benefit.

Others

Budget option: Mares Smart Air

At the other end of the spectrum, there are surprisingly cheap options like the Mares Smart Air at as little as US$550. I have no personal experience with them, but Mares is a reasonable brand and the reviews are generally positive (but suggest that despite the air integration it’s still a pretty basic dive computer, with limited features and not the best user interface – which you could guess just by looking at the product photo since it clearly has an old-fashioned monochrome LCD display rather than the colourful OLED displays of higher-end options).

Mid-range option: Suunto Eon Core

Suunto make more mid-range options like the Eon Core at about US$1,200, and are a long-lived and pretty respected brand. I’ve never had a notable encounter with a Suuntu dive computer in the wild, but I’ve heard generally good things about them.

Highest specs: ScubaPro G3

ScubaPro also have high-end offerings, even more expensive than the Teric, such as the G3 at about US$1,650. I haven’t seen the G3 in particular in the wild, but ScubaPro are generally well-regarded for build quality and reliability (and the G3 pushes past all the other dive computers with a 300m depth rating, ensuring your dive computer will likely survive even though you did not).

Novel option: ScubaPro Galileo HUD

ScubaPro also make a dive computer that I find very interesting, although it might not be for everyone – the Galileo HUD at about US$1,550. I’ve actually seen these in use in the wild, and everyone I’ve encountered who has one swears by it. It’s easy to see the appeal – you have all your critical dive information available in your peripheral vision at all times, no matter what your hands are doing. That includes your compass bearing which can be super helpful for people with a poor sense of direction underwater (which, let’s face it, is most of us). There are some downsides: it’s a little more awkward to interact with than a wrist-mounted dive computer, some people might find the always-in-your-face display distracting, and it doesn’t fit all masks.

I wish I could unsee this.  Not because it’s a violent war movie – I appreciate movies that portray the gruesome realities of war, even if that makes them hard to watch – but because it’s so unclear what the morality is supposed to be.  “War is bad and everyone in it are monsters”, I guess – if I’m being charitable.

It’s basically about a monstrous group of Americans, with no redeeming qualities, that murder & rape their way across Germany.  It manages to make the Nazi’s look good in comparison.  Frankly I’m baffled.

Amazon rejected it, saying it contained:

• Profanity
• Harassment
• Hate speech
• Sexual content
• Illegal activity
• Private information

It of course contains none of that. The only one of those that’s even vaguely related is ‘Hate speech’, and only if they deliberately misinterpreted my review in the exact opposite way it was written. Or maybe they consider merely mentioning rape as ‘Sexual Content’? In any case, they certainly have no problem selling the actual movie, Fury, which does actually contain horrific, graphic portrayals of those.

Sigh.

Now, another of my reviews has been rejected, again for no valid reason, for a Lumisys dehumidifer (since delisted from Amazon). In this case I happen to have the review text saved:

It is in the process of dying – it’s freezing up, faster and faster each day, and making loud cracking noises from thermal expansion.  It is almost certainly leaking refrigerant.  The rate at which it’s removing water from the air has rapidly deteriorated (although as I write it hasn’t technically stopped working entirely – probably just another couple of days, though).

It has lasted about nine months of sporadic use.

Even when it was new and working fine, it wasn’t very effective.  I bought it specifically because it was the highest-rated portable unit available in the U.S. according to https://www.energystar.gov/, but it clearly was both less effective and less efficient than other dehumidifiers I’ve used.

Regarding the dying unit, I tried to contact Lumisys through Amazon and was told by Amazon that they are no longer in operation (despite the fact that Amazon continues to sell their products).

I tried contacting them through their website, for which there is nothing but a web form, and received no response.

By all appearances the company is other defunct or dodging warranty claims.  Either way, this is clearly not a company you should buy from.

This was rejected because, according to Amazon, it is / contains:

• Spam
• Promotions
• Reviews given in exchange for cash, discounts
• Links to other sites
• Attempts to manipulate helpful votes
• Plagiarism
• Infringement
• Impersonation

This is even more blatantly false and an overtly fabricated excuse than the previous case. At best you could point to “Links to other sites”, since I did reference the EPA’s EnergyStar website, but I find it hard to believe that’s considered unacceptable content.

It seems increasingly clear to me that Amazon is contriving to reject any reviews which are critical of the product under review.

I’ve long suspected that Amazon’s review system is biased towards positive reviews – they perpetually have a systemic problem with obviously fake reviews, for one thing – but this is even stronger evidence that they are not merely incompetent regarding review quality and authenticity, but malicious.

I was a bit hesitant to try this game at first, based on the screenshots & videos. I was basically looking for The Settlers, of which I have many fond memories (from II & VII mostly). The Colonists, in comparison, looked a bit dinky, but I ultimately decided to take a chance, and I’m glad I did.

Gameplay

It’s generally a slow-paced game. It’s designed to be. Much of the experience is simply watching the robots go about their tasks, and appreciating the efficiency of your well-designed and well-oiled machine (or suffering the congested roads resulting from poor planning and choices).

You can boost the game speed manyfold if you wish, and if you play maps that include competing AI colonies there can a degree of time-sensitivity – build too slowly or carelessly and the AI might out-develop you and conquer your territory. Even so, this is not a twitch game – it rewards careful planning and paced development.

Surprisingly I play it at regular speed much of the time, despite the option to go faster. In every other Settlers-like I’ve ever played, I’ve always run them at the maximum possible speed. I think that speaks to how pleasant it is just watching all the little robots go about their business – no need to rush.

Each individual game can last anywhere from tens of minutes to tens of hours, depending on your preference. You can play aggressive competitive maps where you rapidly expand to conquer your enemies, always with that single clear objective in mind. Or you can play against the clock, trying to achieve a certain milestone(s) as fast a possible – e.g. accumulating a certain amount of gold, or completing construction of a monument. Or, you can just play with whatever agenda & pace you want, treating the game as your sandbox.

There’s also a variety of map sizes available, with which to further adjust your desired game length. Though the larger maps can be significantly more taxing on your computer, so although I typically like to play the largest maps, I found the experience better with smaller ones.

The “day to day” gameplay is very much in the style of The Settlers. Build first-level resource gatherers, then first-level manufacturers to turn those resources into more advanced resources, and repeat several times over in order to obtain the most advanced resources. There are several dozen different resource types, which can seem overwhelming at first but the progressive gameplay – centred on a tech tree divided into multiple levels that have to be slowly researched & unlocked – makes it much more approachable than you might expect, even for a complete beginner. After a few games the vast number of resource types, and their complex relationship graph, isn’t nearly as intimidating.

There’s significant fan-in as you go up the resource tree – producing the more advanced resources typically requires a vast network of dependent manufacturers & gatherers. And that’s where the core of the gameplay challenge emerges – logistics.

If you have a sleepy starter colony, with merely some basic resource gatherers and homes, then pretty much anything works so far as road & building placement. But as you build up, you run into the limitations of a two-dimensional space – you might need ten different fundamental resources feeding in, via successive layers of manufacturing, to one advanced building. Your roads – though upgradable – have finite throughput. Plan poorly and your distribution network will grind to a halt as bottlenecks form and poor overloaded roadbots fall hopelessly behind in their duties.

The game provides deep details of & controls over distribution – you can micro-manage which resources may travel where and by what routes. I generally found this less enjoyable than other aspects of the game, even though it’s nominally the heart of it – and certainly some folks may be as happy as a pig in the mud with the dizzying range of controls available. But at the end of the day, there’s only so much these micro-management controls can do to compensate for a poorly designed network, so you can’t avoid the need for thoughtful, large-scale design. I tended to utilise them only as a plan B, when the map truly required it or to compensate for poor choices on my part.

Missions & Maps

The game has a campaign that seems short on first impression, at not much more than a dozen missions (maps), but that actually represents many dozens of hours of game play. The missions are pretty varied and each endeavours to introduce something new. And once you complete them, you can move on to the map of the month or a plethora of player-created maps.

Pleasingly, after the first few tutorial missions it gives you the freedom to bounce around the missions partially out of order, and you can choose to ignore the combat ones entirely, or play the combat ones exclusively, or any mix of both. I enjoy both styles for their respective merits, but I like that it accommodates a range of player preferences.

AI

The AI is not particularly challenging, although it can surprise you sometimes – I haven’t won every game I’ve played.

Unfortunately the AI is one part of the game that tends to be quite buggy. It’s improved a bit over the years as the game has been patched and evolved, but it’s never really been fixed. It’s all too common for the AI to just peter out mid-game, mysteriously halting its development and entering a state of stagnation. It’s then quite trivial to roll all over the AI – often it won’t even make a serious effort to defend itself or repair damage you cause.

Even when the AI is nominally working, it’s sometimes too easy to cripple it – conquer just the right part of its territory, disrupting its manufacturing network in a serious way, and it’s often incapable of working around the issue. Not because of fundamental constraints of the map, but because it simply makes poor choices in placement, and typically won’t delete buildings & roads in order to unblock itself.

On the – sadly somewhat rare – occasions when the AI does work properly, it’s quite fun to play against. Getting to a stage where you can actually exchange cannonballs with the AI can lead to some fun and challenging gameplay.

Technically you don’t have to play against competing AI colonies at all if you don’t want. However, I found it to be my preference – racing against the clock for arbitrary achievements, or playing in an open-ended sandbox, didn’t appeal so much to me. So these AI bugs might be a major detraction for you, or might be irrelevant, depending on your gameplay preference.

Visuals & Performance

The game looks much better in person – and in motion – than the videos & screenshots suggest. The art style is deliberately simplistic, but once you build a colony of any non-trivial size there’s plenty to see & enjoy. The animations are lovingly crafted, with each of the numerous bot types having its own moves and flair.

Don’t mistake the art style with being amateur. It’s well-refined. It’s also functional – the simplistic geometry produces distinctive building and bot appearances which make them easy to identify at a glance, and the colour scheme likewise serves double-duty as aesthetically pleasing and functional.

The music and sound-effects have a matching aesthetic, and the net effect can be very zen-like.

At first, when you have just your colony ship, the game appears very empty. But as you build up your colony, detail fills in – inevitably what looked like a spartan blank canvas of a map turns into a bustling town, full of activity.

On a 10-core iMac Pro with Vega64 GPU, The Colonists sort of runs at native (5k) resolution. It tends to bog down a bit – frame rates dropping into the teens – with large maps or large colonies. This is largely independent of other graphical settings. I typically played it at quarter resolution (2880×1440) to avoid this (and to enable me to turn all other graphics settings to their maximums without having to worry). That gave me 20+ FPS most of the time. That might not sound like much, but you don’t need high frame rates – this is not an action game.

Bugs

In earlier versions of the game, on older versions of macOS, I experienced significant bugs relating to the GPU – major rendering errors, and complete, hard lock-ups of my computer.

The game uses Metal by default, Apple’s proprietary 3D library. Metal has long been buggy – this is not The Colonists fault. I often experience hard locks-up with many programs that utilise Metal (or similarly OpenCL).

The game’s author very graciously spent a lot of time working with me to debug these issues. Unfortunately there’s nothing he or I can do about Apple’s buggy GPU drivers, so for a long time the only workaround we could come up with was to switch the game to using OpenGL. That addressed all the rendering issues, eliminated the crashes, and boosted the game’s frame rate substantially.

Unfortunately, I don’t know that there’s an OpenGL option anymore – and it was never officially supported by the author, it’s merely a checkbox option that Unity provided which the author was able to utilise trivially but without “warranty”.

The author

The Colonists is literally a one man production. Richard Wallis created the whole thing. It’s been a work of many years. It’s an impressive accomplishment.

I want to reiterate how impressed I’ve been with Richard, as he worked very patiently with me to narrow down the rendering & freezing issues, and to generally address bug reports. His customer support has been fantastic.

Should you buy it?

Yes.

For so many reasons. It’s a relatively rare, almost unique game style (especially on the Mac since Ubisoft retroactively pulled modern The Settlers games from the platform). It’s produced by essentially one person as a labour-of-love indie game. It’s beautiful and soothing and satisfying.

It has some bugs – and suffers significantly from Apple’s bugs in Metal and macOS more generally – but if you can just stomach those a little bit, you can probably look past them and enjoy what this game offers.

It’s available on a wide array of platforms – macOS, Linux, Windows, PS4 & PS5, Xbox, and Nintendo Switch. (the website also suggests there’s an Android version, but I can’t find it in the Google Play Store) For Mac, you can grab it through Steam or GOG, for $25 USD.

Notably there’s also a Discord server for the game, which is moderately active with players and frequented by the game’s author. Provided you can put up with the dumpster fire that is the Discord app.

A major reason I purchased an Apple Watch Ultra was for its loudly advertised ability to function as a dive computer, much like some Garmins.

It’s been a rough and disappointing road.

Right out of the gate, it didn’t work. It requires a 3rd-party application, Oceanic+, which didn’t exist at Apple Watch Ultra release time. It was over two months before Oceanic+ was finally released, on November 28th.

As it happens, my dive trip plans were delayed a bit anyway, resulting in my first dive [since purchasing the Apple Watch Ultra] being on that exact day. Hallelujah, I thought. I was able to hastily install the app in the morning, before leaving for a remote, internet-less island for a week.

But then there was the surprise that it basically requires an expensive subscription ($80/year, or even more if you commit to less than a whole year). Without it you don’t get tissue load and NDL tracking – critical functions of a dive computer. I was not aware before purchase, from any of the Apple Watch Ultra advertising or product pages on Apple’s website, that this subscription would be required. It feels surprisingly shifty and dishonest from a company like Apple.

Arguably the above frustrations (and costs) could be overlooked if it actually worked well. Unfortunately, it does not.

I discovered serious flaws with Oceanic+ right from the first dive. Flaws that any qualified diver would immediately recognise, which begs the question of why Apple & Oceanic+ somehow haven’t.

There are two major design flaws in its most basic function, the recording of dives:

1. It doesn’t start recording automatically.
   
   You have to hit the “Action” button to acknowledge a lawyer-smelling disclaimer that you’re “fit to dive”. If you forget, it doesn’t record.
   
   I’m not aware of any other dive computer that does this. e.g. my Shearwater Peregrine autodetects submersion below one metre even if it’s not on. It turns itself on and starts recording automatically.
2. If you ascend above one metre, even just for a split second, it immediately ends recording.
   
   This makes shore entries, in particular, likely to go unrecorded (unless you’re able to swim out to deep water and descend rapidly, which isn’t always an option or the best dive plan). Descents in significant swell, currents, or surge could also fall victim to this design flaw.
   
   So on my first dive I got five “dives” recorded, representing the four times where the swell floated me up to just above one metre (I never actually broke the surface). Even just reaching up momentarily with your watch hand, such as to grab a line or brush away a fin, could trigger it to fail.
   
   Furthermore, there’s no way to merge these together in Oceanic+ – you can either keep them, messing up your dive counts and stats, or delete them, throwing away [parts of] actual dive records.
   
   And on later dives I didn’t always notice it had failed and stopped recording, so it basically didn’t record the dive at all. This will be less of an issue if you’re using it as your only computer, since you’ll be looking at it periodically throughout your dive (I was using a separate dive computer as my primary, since I wisely didn’t trust the Apple Watch Ultra untested).
   
   Again, I’m not aware of any other dive computer that has this flaw. e.g. my Peregrine allows a sixty second grace period before ending the dive (configurable for up to ten minutes).

These two combine to make it unsafe for diving. It might be better than nothing, or acceptable as a backup computer (as long as you’re religious about ensuring it’s recording all the time), but it’s arguably worse than no dive computer at all in that it provides a false sense of security – you might plan many dives in one day, relying on the Apple Watch Ultra to precisely track your tissue loading, but have it fail midway and leave you with a dangerous decision to make.

What makes this all the more frustrating is that there’s a lot of things to like about it otherwise:

• The Apple Watch Ultra screen is so much better than what you find on most dive watches – clear and readable, with relatively low glare, even in harsh daylight. Not to mention that it’s a touch screen, so [when dry, on the surface] it’s faster to change your settings, review your dive log, etc.
• The Apple Watch Ultra is a lot smaller than most dive computers. Even those that are nominally intended to dual-purpose as watches.
• The information display during diving is well-designed and user-friendly (certainly not as powerful as what you can get on other dive computers, but quite sufficient for basic recreational diving).

• The iPhone integration is smoother and easier than with other dive computers – dives appear on your phone automatically (albeit sometimes after a short delay).
• It records the geographic location of the dive, which many dive computers do not.
• Its configurable alerts – e.g. for depth, dive duration, etc – are nice and clear when they trigger underwater, with a clear and prominent visual display and strong vibration. I find that its alert vibration is much more likely to actually get my attention than that of my Peregrine.

It feels like it’s actually close to being a pretty good dive computer & companion app, if not for a handful of bizarrely obvious, serious flaws.

It feels, in fact, like it was very rushed – from the obviously daft design flaws noted above, to even just simple things like bad grammar, poor alignment, and broken layout in the GUI (it smells like they’re using SwiftUI and haven’t figure out how to work around all its layout problems). It seems they put more time into their slick website than their actual product.

And of course there’s the other hint that maybe real-world testing was skipped – the fact that the iOS Oceanic+ app crashes on launch if you don’t have a good internet connection. On a boat, far from land? Or a remote island? Or in Airplane mode? Or just in an area with poor internet connectivity? No app for you. Crash on launch, every time. Forget about entering your dive details into the log while you actually remember them.

This remains the case even after six app updates over a month. Apparently Oceanic+ either don’t care that their app usually crashes on launch, or are incapable of fixing it.

Maybe there’s hope that in time they’ll be able to straighten all this out. But until then, I cannot in good conscience recommend the Apple Watch Ultra for diving. (it remains a fantastic watch for health-tracking and hiking, though)

For completeness, a list of other miscellaneous flaws and limitations:

• Any time you ascend past six metres, it throws up an alert about a safety stop. Which keeps buzzing at you forever, until you hit the action button. It’s hard to overstate how annoying this is when doing shallow dives. It is super distracting and may put you in harms way (e.g. if you’re constantly having to fiddle with the Apple Watch Ultra instead of paying attention to the reef around you).
  
  I simply can’t fathom why they feel the need to alert for this at all. An alert would be warranted for skipping your safety stop, yet it doesn’t do that.
• It vibrates the Apple Watch Ultra frequently without any indication why (nothing changes on the display). Observationally, I suspect it’s something to do with ascending “too fast”, but if so then it’s way too sensitive to small depth changes – it vibrates at me when simply ascending less than a metre (even when tens of metres deep, where a metre makes very little difference in pressure).
  
  Overall, the Apple Watch Ultra is too chatty. It’s a classic boy-who-cried wolf problem waiting to happen.
• It doesn’t show CNS, current PPO₂, [surface] GF, etc. Especially when using enriched air (Nitrox), nearing no-decompression limits, or deep diving, these are important for safety. They are purely software features so it’s especially odd that they’re not included.
  
  Surface GF is arguably the most important of these – it basically tells you how dangerous it is to surface immediately. When everything goes smoothly – and assuming you’re planning safe, conservative dives – you don’t need to worry much about it. But when things go awry it can be critical in helping you make the right decision under pressure.
• There’s no Oceanic+ Mac app, or even a web version, which strongly discourages actually using Oceanic+ as your full dive log. Entering all the details of your dive – gear, notes, etc – is very tedious on an iPhone.
  
  Some other dive computer manufacturers do have Mac apps (e.g. Shearwater, albeit one that’s clearly made in some janky cross-platform framework and looks like something you’d find in X11 in the 90s), and there are a few viable 3rd party options (e.g. MacDive, Subsurface).
• The map it shows, of your entry & exit points, is useless most of the time, because it just shows as flat blue (for water) with no identifying geography. There’s no way to switch it to anything useful, like a satellite view that would actually reveal the reefs, sand bars, atolls, etc.
  
  This is exacerbated by Apple Maps’ limitations. Google Maps, for example, often does show atolls & islands at least, and other surface features. Apple Maps simply lacks actual maps for most of the world’s oceans.

• The iOS Oceanic+ app lets you record what gear you were using, but bizarrely requires you to pick from a pre-defined list and that list is missing gear from major brands (e.g. Aqua Lung, Cressi). Another reason why it won’t be your real dive log.
• There’s no way to import or export dive data. This is both a lock-in concern – your dive data will be deleted if you end your subscription – and also a roadblock to using the Oceanic+ app as your real dive log, unless you have never and will never dive without an Apple Watch Ultra.
• You can’t change the activity type – dive vs snorkelling – underwater, nor after the fact. So if you forget to change it before going for a snorkel, you’ll forever have a bogus “dive” in your log (or you can delete the record entirely, but then you lose record of any free diving you do).
• There’s five entries in the main menu in the Oceanic+ watch app, which are arranged as a scrolling carousel… which is just weird and annoying since they’d fit all on one screen as simple buttons, which would make navigation much faster and easier.
• A lot of actions on the Oceanic+ watch app require more steps than seem necessary. e.g. changing numeric values requires not just selecting a different value but also tapping back to the previous screen (which also feels unnatural, like I’m backing out of the change without applying it). There are menus trees five or more levels deep, whereas it seems like they could be flattened into just two or three levels.

• Relatedly, you can’t edit any of your settings on your iPhone, only the watch. You can view the settings on the iPhone, which just makes it even more baffling why you can’t edit them there. Editing them on the watch is great in a pinch – you might not have your phone with you – but it’s a pain compared to on an iPhone.
• The Oceanic+ iPhone app “Home” screen – what’s displayed when you launch the app – just shows a handful of stats of dubious merit. Minimum temperature over the last four weeks? Who cares. Cumulative total max depth? That clearly has no purpose. It seems like they knew they needed to show the most basic numbers – total dive count and duration – and felt compelled to stuff in a bunch more numbers for some reason. It’s also unclear why they think these are more important than your actual dive logs, or the dive planner.

• There’s supposedly seven watch complications available once you have Oceanic+ installed, but on my watch only two are available (“Max altitude” and “Oceanic Launcher”). This might be because I use a digital time display (the “Modular” face), something Apple seems to hate.
• The battery life is surprisingly short – about five hours of dive time. Given that the Apple Watch Ultra can record workarounds that are 16 hours long (at least – longer if you use energy-saving features), it’s a bit of a mystery to me why it chews through the battery so fast while diving. It’s not even monitoring your heart rate or other health metrics – just water pressure – and the screen brightness tends to be low since you’re underwater in low light.

Here’s a few things which are more just wishlist items (or: things you can get from some other dive computers, though you usually pay a lot more for those than you do an Apple Watch Ultra):

• Gas usage recording. Upmarket dive computers support wireless communication with a dongle that attaches to your first stage regulator. This means you can forgo a whole separate hose and dangly, annoying air gauge, and have a unified view of your dive status. It also means you get more accurate tracking of tissue loading, and more advanced functionality like gas consumption rates (great for extra safety – know if you’re going to run out of air too early – and for optimising your gas consumption over time).
  
  Radio protocols like Bluetooth don’t work underwater – lower frequencies are required. So the Apple Watch Ultra would require an additional built-in antenna. It’s arguably reasonable to omit this in a watch that’s not intended solely for diving, given the cost or other trade-offs it might require.
  
  That said, some air-integrated dive computers use sound instead of electromagnetism, and I suspect it’s not hard to support the necessary, inaudible frequencies in the Apple Watch Ultra’s microphone(s). Maybe this support is already present in hardware, and a transmitter dongle will be released later?
• Multi-gas support. Most dive computers support this, even those that are much cheaper than an Apple Watch Ultra. This is arguably a more “serious” or “technical” feature, that most recreational divers won’t ever need, but it’s also easy to do – it’s purely a software feature.
• The ability to enter key dive details on the Apple Watch Ultra (as opposed to an iPhone), such as gas start & end pressures. It’s all too easy to forget these in-between the dive itself and when you get back to land and your iPhone.
• The dive planner functionality is pretty rudimentary. e.g. you can’t do anything like actually enter a dive depth profile (whether as a squiggle with your finger, to give the rough idea, or importing it from a previous dive at the same site). The GUI is also a bit obtuse, especially in the Oceanic+ iOS app, as rather than showing a simple table or chart of depth vs no-deco times it makes you pick a single depth and gives you a single no-deco time. For planning you often want to consider multiple depth options and pick the right trade-off against dive (or at least bottom) duration.
• It might actually be nice to have some “social” functionality. Not for bragging and other vanity purposes – I’m not talking about inane integrations with Facebook or whatever – but for sharing amongst dive buddies and the like. I suspect there’s some neat, innovative possibilities here (e.g. automatically detect physically- & temporally-nearby dive friends, and be able to automagically see their photos & notes on what they saw on what’s presumably the same dive with you – maybe even add your own notes on theirs like “don’t forget about that Whale Shark eating that Orca!”).

And lastly just some miscellanea:

• Apple / Oceanic say that it won’t record below forty metres, but it does. Thankfully – the last thing you want if you do a deep dive, intentionally or especially unintentionally, is for your dive computer to not record your dive profile correctly.

I don’t regret getting my Apple Watch Ultra – it’s proven a worthwhile upgrade even just for its other features like battery life and a relatively large screen – but I am sad that I can’t actually rely on it for diving. And that I had to spend a lot of extra money to get a dive computer – the Peregrine – that I can rely on.

For reference, I’ve completed about fifty dives with the Apple Watch Ultra.

Addendum (May 2023)

I’ve now had the Apple Watch Ultra accompany me on about 150 dives. Sadly, despite it being a long six months later, little has changed. The Oceanic+ app is still awkward and very rudimentary, with the same data and platform lock-in problems. The Apple Watch component is almost unchanged – same limitations and GUI frustrations.

Two things which did improve at some point:

• Recording now happens when submerged even if you haven’t clicked through the lawyer screen. This is a significant safety improvement.
  
  However, if you go the entire dive and return to the surface without clicking through the lawyer screen, the recording is discarded. So there’s still danger here. You just get (a lot) more time to realise the watch is being obstinate (and you really should be looking at your Apple Watch Ultra at least once during the whole dive anyway, even if it’s just your backup, to ensure it’s working and to check its data against your primary).
• The Oceanic+ app seems to have fixed many of the glaring GUI bugs – e.g. the charts that rendered in the wrong places on the screen (or not at all), inconsistent font sizes and baselines, etc.

I haven’t systematically re-reviewed the Oceanic+ app, so perhaps there’s been additional fixes or improvements too. I’ve barely used it since my initial review, since I can only rely on my primary dive computer (Shearwater Peregrine) anyway. For what it’s worth, I use MacDive on my iPhone & Mac and am reasonably happy with it.

I wish I’d just bought the Shearwater Teric, though – the Peregrine was me hedging my bets and hoping that the Apple Watch Ultra would prove sufficient alone. The Peregrine is good but the Teric is much nicer (and for clear reason by far the most popular dive computer on the six boats I’ve dived from).

This’ll probably be my last post in this series of ‘impressions’. I’m simply running out of new things to say.

I’m quite happy with the Z9. It’s not perfect, for sure, but it’s the best camera I’ve ever used. I am curious to temporarily acquire a Sony a1 and see how they compare, but that seems pretty academic – unlike with the Z7, most of the time it’s me (or my uncooperative wildlife subjects) that’s the limiting factor with the Z9. The only other time I felt remotely like that was with the D500.

Autofocus

• Animal subject detection is sometimes surprisingly good – although often it’s academically impressive, in ways that aren’t very practical. e.g. it can detect squirrels at great distances, and track them with absolute certainty as the camera wobbles & shakes around.
  
  Tracking distant subjects is great and all, but if it has to be a trade-off, I wish Nikon had put more energy into having it track close subjects better – subject distances that are actually typical in real use and good photos.

• Subject identification and tracking is impressively robust against foreground obstructions. I’m now comfortable saying this is the best performing Nikon camera ever made, in this regard – and my opinion is still on an upward trajectory as I use it more and more. (I don’t have experience with current flagship Sony or Canon cameras, thus the Nikon-specific qualifier)
  
  It can still struggle to find the subject if it’s out of focus or the scene is very busy, and in that case you have to give it a hand by getting it closer to correct focus first (and/or using 3D tracking to point at the target, rather than auto-area mode).
  
  I wish there were an AF option to control whether it would exclusively focus on detectable subjects in the area AF modes, rather than falling back to picking some arbitrary focus point. The current behaviour is sensible in a lot of situations and definitely shouldn’t be discarded, but if & when I know there’s a bird hidden amongst the foliage I’d actually like it to focus hunt for it rather than throw up its hands and just focus on leaves.

• Sometimes the Z9 really impresses me with how it recognises a subject that’s wildly out of focus.
  
  I hadn’t really thought about it much before, but the subject recognition task for these camera AF systems is actually way more challenging than you might think. Recognising a human face in an already in-focus photo is one thing, but recognising that this vague light brown blob is actually a face – just out of focus – is another.
  
  The Z9’s certainly not perfect here – you definitely still have to help it a lot of the time, by manually getting focus closer to the target first. Still, while of course I wish it recognised out of focus subjects more consistently, I won’t complain that it only sometimes achieves apparent miracles.

Image quality

• For a while when I was first reviewing my photos in Lightroom, I was a bit confused and put off by their appearance – very crunchy, for some reason. Since I generally wasn’t comparing side-by-side with another camera’s photos, I tried to convince myself I was just being weird. But eventually I realised that Lightroom is applying heavy-handed, ugly edits to every photo by default – e.g. +40 texture and +20 clarity.
  
  There’s no clean way to fix that, apparently – you can only work around it by creating a “preset” that does nothing but set things to their normal, neutral defaults, and then apply that preset on import.
• I’m not thrilled with the noise levels I’m seeing. However, I’ve heard vague mention that Lightroom’s support for Z9 raw files is preliminary and still not great, and along with more obvious problems (like the busted default settings noted above) this seems plausible. So, while this will hopefully be fixed soon, beware if you use Lightroom.
  
  Without any actual measurements or side-by-side comparison, just subjectively, it feels like DX levels of noise, not FX. Still, many of my favourite photos of all time were taken with DX cameras – and much older ones, with even worse noise performance – so I’m surprisingly not all that bothered about it. I certainly hope it’s just Lightroom being Lightroom, but even if it’s not, I wouldn’t give up the overall package that is the Z9.
  
  Plus, Lightroom’s raw rendering is about the worst you can get – really, if you actually care that much about image quality that you’re bothered by DX vs FX or Z7 vs Z9 or whatever, then you definitely shouldn’t be using Lightroom to begin with. For what it’s worth, Capture One was far better – the best – last time I checked (five years ago – Lightroom definitely hasn’t gotten better in that time, I know that much).

• The Z9 under-exposes things a lot – I often have to lift by two whole stops just to get a normal exposure. This is in matrix metering mode (it’d be more explicable in highlight-weighted mode, but as I commented in my second impressions I immediately noticed even worse under-exposure so I switched to matrix).
  
  I think this might be contributing to the perception that the noise performance is poor – I keep looking at a photo and thinking “what?!? ISO 360 and it’s this noisy?!” then I remember I’ve actually bumped it by at least two stops, so it’s more like ISO 1,600.
  
  Note also that Lightroom by default applies +1 EV to Z9 photos, which I found odd. I wonder if that’s a hacky workaround for a bug in Lightroom’s rendering of Z9 raws? However, even if we presume that’s the case, that Lightroom is rendering 1 EV darker than it’s supposed to due to some bug, then there’s still at least another stop of under-exposure to account for.
• I’ve not side-by-side compared the dynamic range vs e.g. the Z7, but I have had a few scenes & photos were I at least feel that the dynamic range is noticeably less. Sometimes highlights just don’t recover like they would with the Z7. But, given the exposure problems I noted in the previous point, it’s hard to say if there’s a distinct problem here or just the same one regarding metering – or just Lightroom’s current Z9 raw support being flawed.
• I still see evidence of rolling shutter in some photos of still subjects, but it’s of course dramatically less-so than with e.g. the Z7.
  
  Specifically where I notice it is in bursts with slow shutter speeds (e.g. ¼ second) – when moving between images in Lightroom there’s visible changes in scene geometry between frames; that tell-tale “jelly” effect. It’s very small, to be clear – nothing you’d ever actually care about in the finished images. Still, it’s technically perceptible.
  
  Odd that it’s not something I ever recall seeing with DSLRs like the D500 – one would expect almost identical behaviour since the nominal shutter speed of ~1/270 is about the same as most DSLRs. It might be related to the image stabilisation systems too (or instead). I’m not sure how I might distinguish that via test.

Ergonomics

• The FTZ adapter – the first version, with the tripod mount – isn’t actually a significant problem for portrait use. Yes, it does make it slightly trickier to get your fingers on and off the grip, but at least for me my fingers do fit well enough between the adapter and the camera body, and there’s no discomfort.
  
  I presumed I was going to eventually get the FTZ II adapter, but now I see no need to.
  
  I like that the FTZ I adapter has a tripod socket – when the lens itself doesn’t have a tripod mount, I prefer to attach my camera harness to the adapter rather than the camera body. That way there’s less stress on each of the mounts – and it tends to be better balanced that way, too. However, there isn’t enough room to actually connect anything much to it when the FTZ is on the Z9. So there’s definitely no point getting the FTZ I instead of the FTZ II, unless you expect to also use it with non-portrait-grip-equipped cameras.
• As large as the camera is, it turns out my palm rests on the portrait mode controls when I’m using it in landscape mode. So it’s a good thing there’s a locking mechanism for those, to reject spurious input. Though I sometimes forget to lock it after use, and end up taking photos accidentally. And conversely having to unlock it every time is not yet an ingrained habit, so sometimes I miss photos.
  
  I’m not sure what Nikon could realistically do about this; I think it’s just something I’m going to have to adjust to. I developed the habit of instinctively flipping the power on when going for the shutter on the Z7, so I assume I’ll eventually do the same on the Z9’s portrait controls.
• Possibly also related to the portrait grip controls – since I never saw this on any other cameras, none of which had portrait grips built in – I get a lot of random shutter actuations. Typically when the camera is hanging from a harness on my hip. One or other of the shutter buttons is apparently really easy to hit, and since the camera is completely silent you don’t know about it until you get home and have to delete fifty photos of the ground, or your arse.
• The top panel display flickers. I find that it’s not noticeable most of the time – mainly just on certain angles in bright light. It doesn’t impact its usability, though it doesn’t look great.
• As expected, I’m now (a month or so later) completely used to the weight and it’s a non-issue. I still pick up my Z7 occasionally, and even side-by-side at this point I don’t perceive any meaningful difference. I can tell they’re different weights, it just doesn’t matter in practice.
• I’m mostly used to the overall size. It’s mostly size- or shape-related side-effects that I’m still coming to grips with, like the Z9’s propensity for rolling / falling over quite easily, or how it suits some carriers less…
• It doesn’t work great with a Cotton Carrier, because the addition of the portrait grip forces the camera and lens out away from the carrier. With an e.g. Z7 the camera and lens basically rest neatly against the carrier, which helps secure them and prevents any significant movement perpendicular to your torso. The Z9 sticks out and is wobblier and more awkward.
  
  The only exception is if you have a lens with a suitable tripod foot that you can use as the mount point instead – but most tripod feet stick out a lot anyway, so it’s usually a similar problem.

I’ve only used it on the Z9 so far, but I’m thinking it could be a great option on a Z7 as well for backpacking and other such activities that benefit from travelling light.

In no particular order:

• Autofocus is solid. It seems pretty accurate – much more so than F-mount lenses, as is the emerging norm for Z-mount lenses. I really like that if it can focus, and the focus point is in the right place, then you can be very confident it’s nailed it.
  
  It struggles in low light, much like the 24-70/4 or indeed most lenses on the Z9. “low light” is a vague term, I realise. Perhaps the best way to put it is that it simply performs about how I’d expect based on other f/4 lenses. It’s not a great option in low light, but it’s certainly no worse than you’d expect for an f/4.
• Minimum focus distance is nice and short. I’ve been repeatedly surprised by how closely I can focus – I don’t know why, but I guess just based on all the other comparable Nikon lenses I’ve used (over the course of a decade), this focuses noticeably closer. About the only lenses that beat it are actual 1:1 macro lenses. The only other non-macro lens that matches it [that I’ve used] is the 100-400 Z (though the 24-70/4 isn’t far off, at least on paper – but the extra telephoto reach really increases the perception of in-your-face closeness).
• It suits the Z9, ergonomically. The 24-70/4 is a good size for an e.g. Z7, but a little diminutive on the Z9. It’s noticeably bigger than the 24-70/4 in ‘stowed’ position, but in use they’re actually almost identical in size – the 24-120/4 is longer by about the depth of the lens cap (within the 24-70 range – obviously past 70 it gets longer still).
• I really like that the camera works immediately when you turn the camera on, unlike with the 24-70/4 – no need for that irritating modal error message about the lens not being extended.
• There’s no meaningful difference in weight vs the 24-70/4.
• Image stabilisation seems to be very good. Similar to the 24-70/4, which is one of the most impressive lenses I’ve ever used for image stabilisation. I haven’t really pushed it much yet, but e.g. hand-held down to 1/4 second – even at 120mm – yields decent results the majority of the time (your mileage may vary, of course – for me this is an above-average result).
• It has a function button, but like pretty much all the other Z lenses with such buttons, I still can’t figure out any real use for them. Likewise the control ring (I tried it as the aperture control, but it’s more awkward to use than the camera body dials and it gets bumped by accident all the time).
  
  I guess I’m a lens ‘millennial’ in the sense that I got into real cameras only a decade ago, after physical aperture controls on lenses had largely faded away. So I never ‘grew up’ with that. I’ve owned a few lenses over the years that have aperture rings, but they’ve never grown on me.
• It doesn’t have an OLED display – or any equivalent for focus distance display etc. But I don’t care much – other than for novelty value, I never use the OLED displays (having to push a button to turn them on is apparently enough of an annoyance to discourage their use). And on my older F-mount lenses that have a focus distance scale, to be honest I basically only use it to remind myself which way the focus ring turns (sigh… Sigma vs Nikon). With Sigma not making lenses for Z-mount, and Nikon making (generally) excellent Z lenses, it might be that I eventually eliminate all the Sigmas and no longer have that oblique issue.

All in all, a good result so far. No complaints (other than the long delay in actually getting one). But I haven’t really scrutinised the photos from the 24-120 yet. My impression from quick review is that they’re good, like most Z lenses. But I haven’t yet compared against the 24-70/4, side-by-side.

Sidenote: I ordered the 100-400, 24-120, and Z9 in the same order, about twenty minutes after they were launched way back in November. The 100-400 shipped in December, the Z9 in January, and the 24-120 in late February. It strikes me as interesting that the Z9 is apparently easier to get than the 24-120. Perhaps there’s huge pent up demand for a longer 24-70/4. Sad that the 100-400 is apparently not popular, but then given the price and its disappointing acuity, perhaps that makes sense.

Values shown are the average over all trials with worst & best individual results shown in parenthesis.

Commentary

Surprisingly little performance difference

None of the cards tested are among the “known fastest” CFExpress cards, like the Delkin Blacks or ProGrade Cobalts. Nonetheless, I’m surprised at how minor the performance difference is between all of them, especially given there’s an XQD card in the mix.

CFExpress cards are not necessarily fast.

Angelbird AV PROs do not meet their promised performance

The Angelbird card claims a 1,000 MB/s minimum, sustained write speed. The XQD format is incapable of speeds above 500 MB/s. Yet the Angelbird is at best just 40% faster than the XQD Lexar. This suggests either the camera is the limiting factor – unlikely given that others have demonstrated much deeper bursts with other, apparently faster cards – or that the Angelbird doesn’t live up to its claims.

Blackmagic Disk Speed Test with a Pergear USB-C reader indicates the Angelbird almost hits 1,000 MB/s at the start of a sequential read or write, but within a second or two falls down to a sustained speed of only about 700 MB/s. And there’s that 40% difference again, vs XQD.

Average performance correlates with consistent performance

e.g. the Pergear 512 GiB is nominally about the same performance on average as the ProGrade 256 GiB, but the Pergear was much more consistent. The Angelbird was a tad faster & more consistent again.

This also highlights why many trials are important, in order to determine the variance. I’d rather have an on-average slower card that’s very consistent than a “bursty” card that might crap out in a critical moment and cause me to miss the moment completely.

30 & 120 FPS modes are camera limited

There was practically no difference in performance between the cards in 30 FPS & 120 FPS modes.

The bandwidth demonstrated is well below the demonstrated capabilities of all these cards, at just a few hundred MB/s.

All this seems quite conclusive that in these extra-fast burst modes the Z9 is the bottleneck, not the memory card.

Sidenote: The ProGrade card showed occasional glitches (three in total across twenty trials) – where the Z9 would suddenly stop shooting mid-burst, where a split second prior it had still shown a significant amount left in the “buffer” (the rXXX counter). I’m not sure what to make of that – perhaps the Z9 relies on some basic level of performance and the ProGrade can’t consistently meet it, or perhaps something is glitching between the Z9 & the ProGrade card that causes the Z9 to error out and stop working.

Methodology

1/250, 24-70/4 @ f4, ISO 5000.

Z9 firmware 1.11.

I enabled the shutter sound at maximum volume, and held down the shutter until I heard a stutter.

For 20 FPS mode:

• I counted any extra frames after the stutter and subtracted those from the numbers.
• I also tested 1/2500 and saw no meaningful difference in results, and ISO 64 & 25,600 which improved and decreased (respectively) buffer depth by about 10% each (very likely corresponding to the file size differences, though I didn’t check).
• Five trials, each testing each format in turn: lossless, HE*, HE.

For 30 & 120 FPS modes:

• I never heard an extra frame after the first stutter – I don’t know if that means the camera ground to a complete halt or merely that it doesn’t reliably play the fake shutter sound in these modes. The consistency of the results in those modes leads me to believe it’s the former.
• Ten trials, sequentially.

Cards were formatted in camera and empty at the start of each class of testing (20, 30, 120). Images were not erased between trials (empty cards are not representative of real-world conditions).

Autofocus was not engaged during shooting. I haven’t tested it comprehensively, but so far I’ve seen no impact on burst performance from using autofocus (including subject recognition).

As before, I’m using camera firmware 1.11.

As before, I’m trying to focus on things that aren’t already very well known / discussed about the Z9. And a lot of that is around finding the edge cases where things stop working properly. Please don’t misconstrue that as an overall negative judgement of the Z9 – I like the Z9. (I say this because an earlier revision of this post was reposted on Nikon Rumours, which was very flattering but led to quite some angst in the comments there due largely to this missing context)

All example photos are from High Efficiency* raws as rendered by Lightroom Classic without any edits, other than cropping where appropriate.

Ergonomics

• You cannot use the camera at all – can’t even bring up the menus – if you have a “stowed” lens attached, like the 24-70/4 in compact form. This is not a big deal, of course, but it’s annoying that you can’t do anything with the camera and it doesn’t give any indication why – unlike the Z7, the Z9 doesn’t turn on the LCD in this situation, only the EVF, so it’s very easy to miss the dialog it’s trying to show that’s complaining about the lens.
• It took a little experimentation to figure out how to manipulate the LCD screen easily. If you just grab the side and try to pivot it up or down, for example, it’s almost impossible to do so without fear of breaking something. This seems to be a consequence of its complicated multi-levered design. Fortunately Nikon have included little grabbers on the top & bottom as well, and if you use those appropriately the screen is easy enough to position.
• With the Sigma 150-600 Contemporary attached, I’m finding the Z9 isn’t significantly different in weight from the Z7 (or D500). I also don’t see any meaningful difference in “balance” or any such thing that apparently lots of other people do.
• One thing I hadn’t really considered is that the Z9 is a rounded square, whereas the Z7 was a less rounded rectangle. Consequently the Z9 likes to roll about, such as in a car going around corners, which is annoying – on a recent windy-road drive I had to hold the Z9 the entire time, in my lap, to prevent it attempting to commit suicide against the doors and dashboard.
• Some camera harnesses are problematic with the Z9, unless you have a tripod foot on the lens that you can attach to instead.
  
  e.g. my preferred camera harness is a Cotton Carrier, but the Z9’s big butt forces the camera and lens to stick out way more, which puts a lot more torque on the harness – I worry it’ll eventually snap from the stress (I’ve had one harness break in this way before) – and is just less comfortable all round.

Performance

Autofocus

• It hasn’t completely kicked the Nikon Z habit of obsessive-compulsive behaviour regarding backgrounds. Sometimes with a clear subject front-and-centre, right there in the middle of the frame, it’ll buck all artistic conventions and seek novel compositions in the background.
  
  This is rare, to be clear. The Z7 did this [figuratively] all the time. I think the Z9’s only really done it once, maybe twice so far. So I wouldn’t call this a big deal, even though it’s such an obvious fail when it happens. Still, it’s a bit sad that Nikon still can’t seem to figure this out.

• As others have occasionally commented in reviews, eye autofocus is easily foiled if the eye is obstructed at all, e.g. by hairs, feathers, or similar. In most cases (that I’ve seen so far) it will vacillate randomly between the eye and the obstruction.
  
  As such, it is possible to still get the eye in focus, but you need to take a lot of pictures and hope for the best.
  
  This is not unique to subject-detecting AF modes – the problem occurs in single-point AF as well, for example.
  
  This behaviour in single-point mode is justifiable – in abstract there’s no way for the camera to tell which of the possibilities you actually want – but I would think that when it explicitly detects an eye it would understand how to avoid common obstructions like hairs & feathers, and similarly nearby elements like eyelashes. e.g. focus specifically on circular or oval features, or simply always prefer the furthest detected feature. Alas it does not.

• Eye detection is sometimes wrong about what is an eye – e.g. nostrils on birds. I don’t have much data on this yet, but I get the initial impression that it’s basically just looking for a roundish feature that is darker than its surroundings, and nostrils are often darker than eyes (since eyes often have reflections and/or colour irises), or the eyes might be partially obscured. The behaviour is dependent on the bird – e.g. for California Condors it was a real bugger sometimes in trying to get it to recognise the actual eye, but for many other bird species it had no issues.

• For some animals – e.g. this California Condor which is apparently the Z9 AF system’s nemesis – it doesn’t recognise the actual face at all, but frequently thinks it sees a face elsewhere on the animal. In poses like the one above it mistook the nostril for an eye and prioritised that, but in the photo below it didn’t detect any eyes and instead thought it saw a face in the middle of those neck feathers.

• Similarly in some cases it doesn’t recognise an obvious animal at all, but thinks it sees something interesting in inanimate objects. This is compounded severely by the design flaw where 3D tracking mode will always focus on any detected subject no matter where you tell it to focus, and disabling subject detection (to work around this flaw) requires menu-diving.

• I’ve seen a small number of cases where the camera simply front-focuses for no apparent reason, in single-point AF. Sometimes it’s so severe that nothing in frame is in focus. This is with the 24-70/4 at least. When this happens it consistently misses focus across all photos in a burst (with AF-C active).
  
  To be clear, usually the camera focuses consistently on at least something in the scene – especially with single-point AF it’s generally very reliable. Just not always.
• I haven’t tested it properly yet, but I get the impression the Z9 suffers from the same flaw as the Z7 regarding autofocus performance vs exposure preview. i.e. if your subject is dim in the viewfinder – because you have accurate exposure preview enabled and you’re under-exposing (e.g. it’s an inherently dark subject, or you’re protecting highlights, etc) – the autofocus system performs worse. Simply raise the ISO, for example, and autofocus works much better (but now your actual exposure is wrong, and your photo might be unusable).
  
  This is probably why Nikon have the “View mode (photo Lv)” setting (Custom Settings > Shooting/display > d9), so that you can choose which of these trade-offs you wish to prioritise. But with accurate preview turned off it’s all too easy to screw up the exposure, especially in non-trivial lighting situations where the rudimentary exposure meters just can’t convey what’s going on.
  
  DSLRs didn’t have this issue per se because they had no exposure preview mode – and because the AF system was separate from the image sensor, the AF system could always operate with whatever settings it found optimal.
  
  The crux of my frustration is that it feels like a false dichotomy. I don’t understand why it can’t use whatever ISO is best for AF, but simply adjust the image in the viewfinder to compensate. e.g. if it needs a few extra stops of gain for good AF, then just reduce the EVF / LCD preview by the same amount. Sure, it might clip highlights in the EVF preview, but I think I’d prefer that – the highlights would still be fine in the actual photos taken, and in any case if the subject isn’t in focus blown highlights are irrelevant.

Image stabilisation

• I’m seeing particularly poor image stabilisation performance with the Sigma 150-600 Contemporary. This lens has always had poor image stabilisation, on the Z7 and the D500. But I feel like it’s worse on the Z9.
  
  If I want the majority of hand-held images to be usably sharp at 600mm, it seems like I have to use a shutter speed of at least 1/500. I haven’t really established a baseline by turning image stabilisation off, but I can’t see how 1/500 equates to more than a stop or two of effective stabilisation, at best.
  
  Most of my favourite wildlife photos are taken in the range of 1/10 to 1/100, so this is a big problem for me.
  
  I’m also seeing more (vs the D500, Z7, etc) of the behaviour where the vast majority of photos are unusably blurry and then just occasionally one is actually sharp. There’s not a lot of middle ground. I mention this because with e.g. Nikon’s own 80-400 or the 100-400 you tend to get a much smoother continuum of blurry to not blurry.
  
  It’s the only non-Nikon lens I use with its own image stabilisation, so I can’t draw any conclusions as to whether this is first- vs third-party lens compatibility or anything like that.

Metering

• Ever since it was introduced (D500 era, I think?) I’ve used highlight-weighted metering almost exclusively in stills photography, because noisy midtones can be mitigated but blown highlights can be ruinous. But with the Z9 I found very quickly that it would massively under-expose sometimes in highlight-weighted mode. I switched to matrix metering and have almost exclusively used that so far. It works well most of the time, but of course it does sometimes blow the highlights.
• If “Starlight view (photo Lv)” is enabled (Custom Settings > Shooting/display > d9), the EVF / LCD do not show exposure accurately, irrespective of the setting of “View mode (photo Lv)”. This is extremely surprising and caused me to massively over-expose a bunch of images.
  
  It makes me suspect that “Starlight” mode – which is nominally about autofocus working better in low-light – is nothing more than forcing the sensor into ISO settings that are most amenable to the autofocus system rather than representative of the intended exposure (see earlier point about AF effectiveness vs exposure preview).
  
  Addendum: why use “Starlight” mode in broad daylight? In this case, because I’d had it on the night before and forgot to turn it off. Though in any case I’m still curious as to exactly when it’s supposed to help – e.g. does it only work in extremely low light, or does it boost AF performance in any situation? Nikon’s product material, and 3rd party reviews, say very little in this regard.

Battery life

• The battery lasts about six hours in my use. That’s with the camera on the whole time, GPS enabled (with standby turned off), and sporadic use in 20 FPS mode.
  
  Battery life seems to be mostly affected by how long the camera is switched on and especially how long the EVF or LCD are active. How many photos you take doesn’t seem to be a significant factor. Though video might (I haven’t done a lot of video yet).
  
  I assume the GPS is a significant power suck. Previously, on my Z7, I used a Solmeta GMAX hotshoe GPS because (a) it has a big internal battery that avoids draining the camera’s battery, (b) it was far more reliable than any other GPS unit I ever tried, and (c) having its own battery meant it could keep active irrespective of what the camera was doing or whether the camera was even on. I could use that on the Z9 too, but the combination would be too big for my tastes. If you’re not going to use the built-in GPS you’ll probably see a significant increase in battery life.
  
  I could also turn the camera off between use, which might save a significant amount too – but I’m afraid to do that because I’m not convinced the GPS will work as reliably (the Z9’s manual claims the GPS will continue tracking even if the camera’s off, but frankly I’m sceptical based on past experience with earlier cameras & GPS units).
  
  On the Z7 I’d usually get at best four hours per battery, and that’s even though I’d turn the camera completely off when not actively using it. So it’s clear the Z9 gets significantly better battery life – as you’d expect given it has 157% more capacity.
  
  For a long day of use, or if recording significantly amounts of video, you’d definitely need at least two batteries for the Z9 (or rely heavily on USB tethering).
• Battery charging in-camera officially takes 3h 40m from 0% to 100%, and I haven’t tried to precisely measure that but it seems about right for what I see in practice.
  
  Using a USB battery brick to charge the camera seems to add about 2% every five minutes or so. If you’re out for the day and take a half hour lunch break, for example, you can only add ~12% more juice to the battery. Not all that useful. I find having a USB cable sticking out the side of the camera to be dangerous to the camera’s health (cable yanks, water ingress, etc) so power / charging while it’s in use doesn’t seem practical to me.
  
  I haven’t tested it yet, but in theory you can use any old USB power source to charge a second battery, which will be super helpful (compared to having to use mains power as with previous Nikon battery chargers).
  
  I’d really like to see future Nikon cameras & batteries support faster charging, like most portable electronics do. e.g. USB-PD 60W should be enough to goose the battery from 20% to 80% in just twenty minutes. That’d make it real easy to have a single battery and just top it up every time you take a bathroom break or whatever.

Reliability

Crashes

• It locks up occasionally in playback mode, when reviewing images. It’ll suddenly just stop responding to all controls, and after fifteen seconds it reboots itself. It forgets everything it was doing when it reboots (e.g. the playback image position resets to the most recently recorded image).
  
  [Addendum: some folks suggested it might be the memory card causing this. While it’s hard to definitively rule that out, this happens with at least two different cards from different manufacturers (Pergear & Angelbird).]

GPS

The GPS seems to work quite well so far, though I’ve basically just been moving to a location, preparing, then taking photos, then moving on – a more challenging test will be if I’m moving while taking photos, such as on a boat, or taken photos suddenly after moving. Those are situations in which a lot of GPS units / Nikon cameras will make mistakes, like recording wildly stale location data.

I’ve taken a bit over a thousand photos so far, with GPS enabled.

• Once it’s acquired its position it seems to update it every second, as you’d expect.
• It does actually work indoors (all the time so far for me, but I haven’t been indoors much). This is a pleasant surprise. Some prior GPS units I’ve used have basically not worked at all indoors.
• It seems to be much more capable of actually acquiring an accurate position – when faced with obstructions etc – than most prior GPS hotshoe units I’ve tried, though I’d be [very pleasantly] surprised if it matches the Solmeta GMAX in that regard.
• It’s never failed to record the location so far.
• It’s never gotten the location completely wrong, so far.
  
  It’s not super accurate, though – I see longitude and latitude inaccuracies of up to ~ten metres in some cases. It’s good to just a couple of metres most of the time, though. The Solmeta GMAX is more consistently accurate, but for my purposes ~ten metres of error – occasionally – isn’t a big deal.
  
  Altitude isn’t accurate – its regularly off by tens of metres. e.g. at the beach yesterday it consistently thought I was 12 to 19 metres below sea level.
• Even with all the standby stuff disabled and the camera left on at all times, it does lose its position if you’re not actively using the camera (according to the position read-out in the menus). That concerns me, as this mimics the behaviour of most prior [hotshoe] GPS units with Nikon cameras, and my experience with them is that they fail to correctly tag photos a lot. But, as noted above, so far it’s actually worked well despite this.
  
  I have not yet tried enabling GPS logging – presumably that forces the camera to maintain an accurate GPS location at all times. So that might be a workaround, if there are any issues.
• It doesn’t record heading like the Solmeta GMAX, but then to be honest magnetic compasses tend to be uselessly inaccurate anyway so I’m not really missing that (though if it had it, and it worked reliably, that would be nice).
• There’s no way to tell at a glance if the camera actually has a GPS location fix. There’s a satellite icon that shows up in various places in the GUI, but all it seems to mean is that GPS is enabled, not that it actually has a location lock.
  
  You can dig into the menus to find out, but that’s a bit slow.
  
  Nominally it tells you when it doesn’t yet know its location, by blinking the satellite icon. Indeed I do see that happening when the camera is first turned on and acquiring its location initially. But, even when it stops flashing the camera doesn’t always know its position (according to its read-out in the menus).
  
  I miss the built-in LCD of the Solmeta GMAX where I could see at a glance if it had an accurate position fix (and gauge roughly how accurate via the number of satellites acquired). Maybe Nikon could issue a firmware update that adds a little satellite count badge to the satellite icon, like most GPS units display.

Software support

• Just a minor oddity, but Lightroom’s Import dialog seems to have problems with High Efficiency NEF files – it won’t reliably show thumbnails for them. You can “jostle” it by mousing over the blank spaces to get it to load the thumbnails, most of the time, but this isn’t something that’s required for Nikon NEF files from earlier cameras.

My Z9 has firmware version 1.11.

Note also that I’ve read & watched practically everything out there so far on the Z9, and have no desire to repeat what’s already been covered to death. I’m only noting here things that surprised me or otherwise weren’t well-covered elsewhere. That tends to mean oddities or negative things – but to be clear, my overall impression is very positive; there’s a lot to like about this camera, it’s just that most of that’s been heavily documented already.

Ergonomics

• It’s heavy. Dense. I thought I’d be fine with the weight and was actually only worried about the volume, but in practice it’s the opposite.
  
  The size is fine – not great; smaller would be nice of course, but the Z7 plus a reliable GPS unit in the hotshoe has basically the same bounding box as the Z9, so the Z9 is effectively no larger for my purposes.
  
  The difference is of course most pronounced with baby lenses like the 24-70/4. With the Sigma 105/1.4 on it, it’s not that different to with the Z7. Similarly if you stick a telephoto on it, e.g. a 150-600, the perceived difference vs the Z7 is pretty minor. Still, for casual ‘walkabout’ use, with a small lens like a 24-70 or 24-120, I’m a bit concerned.
  
  I’d assumed it was the bigger battery that contributed a lot of that extra weight, but actually the battery is pretty light. Also much smaller than I’d assumed.

• The grips are a bit big. I’m a guy with fairly large hands, too. It’s similar to the large DSLRs (e.g D500). I know when I went from those to the Z7 I thought the Z7 grip was too small at first, but I very quickly got used to it. I do think the Z7 grip is a tad smaller than ideal – and certainly too short vertically, as my pinky finger inevitably ends up below the Z7 rather than holding it – but overall it’s closer to ideal than the Z9.
  
  Holding the Z7 feels like you’re holding something precise, albeit a bit diminutive, whereas holding the Z9 is like holding a literal brick.
  
  That said, I’m expecting I’ll get used to it.
• The dpad feels kinda stiff. It’s a tad difficult to actually press (and yet feels quite mushy). Not great.
• The control wheels are much nicer than the Z7 ones. The Z7 ones feel nice, at first, but they’re metal and relatively sharp and I know from uncomfortable experience that they can cause blisters on your fingers. The Z9 brings back the rubberised DSLR-style control wheels, which don’t feel as fancy but are much better for heavy use.

• I’d read some complaints that the memory card door is difficult to open, especially one-handed, but it’s completely trivial – push the slider down, then push it left, then just let go and the spring-loaded door opens itself. It takes literally just one finger. Can you finger-paint an L? Then you can open the memory card door.
  
  It’s much easier to open & close than a GoPro case, for example. Possibly too easy, if the goal is to prevent accidental openings.

• I’ve almost always used pure electronic shutter mode on the Z7, for the peace & quiet, but even so it’s still noticeably harder to tell that you’re taking photos with the Z9. I assume because of the complete lack of blackout [most of the time]. Even with the flashing indicators enabled.
  
  [Follow-up: case in point, I went to the zoo a few days ago and unintentionally took 8,000 photos! That’s about 10x what I would have taken with e.g. the Z7, or even the D500. It’s so easy to suddenly have thousands of photos without really noticing. Granted I only kept ~1,500 after culling blurry & duplicate ones, but the culling process alone took a few hours. The Z9 needs to come with little minions to help manage the output. 😜]
• The camera gets warm when recording video (8k/30 and 4k/30 at least) or bursting at 20+ FPS, in a cold room. Not hot, but it does make me a little concerned about over-heating in hot environments. We’ll have to see.
• The EVF is visibly low resolution, just like the Z7 – by which I mean you can see the individual pixels. But honestly I’ve never really felt this was a practical problem – how sharp the EVF is has no bearing on how sharp & correctly focused the actual photo is.
  
  A sharper EVF (and LCD) would certainly be nice, no mistake – I certainly prefer “Retina” displays over their pixellated forebearers – but it’s not a big deal despite what so many others claim.
  
  The EVF still looks better than the cheap, shitty LCD displays most of the world use on their computers.
  
  One purported problem with the low resolution of the EVF is in judging focus accuracy. I think the impact is small if not completely insignificant. There are much better ways to check focus accuracy – e.g. digitally magnifying the view (I assign one of the function buttons to jump to 200%). These are much more effective and indeed necessary if you actually care – with 45 MP no human eye can check critical focus without zooming in a lot.

Performance

This section is particularly preliminary since it’s based on just a couple of hours of use, and this aspect is inherently hard to judge.

Burst shooting

• As others have recently noted, if you use shutter speeds below 1/250 you don’t actually get 20 FPS. It drops first to 15 FPS and then about 10 FPS at 1/30, etc. That’s disappointing – most of the time I’m using less than 1/250, so it appears I’m rarely going to see the claimed 20 FPS.
  
  It’s also weird that in 30 FPS JPEG mode it’s not limited until 1/50 or below.
• The buffer depth is better than I expected based on other people’s tests, possibly because most tests to date were done with 1.00 firmware – Matt Granger’s results show a huge improvement with 1.11 and his numbers match mine for the one card we have in common, the ProGrade 256GB. Or maybe folks were using the HDMI output simultaneously, which Matt Granger also documented as having a significant negative effect on buffer depth.
  
  I get at least 50 HE* photos at 20 FPS before any slowdown, even with a Pergear 512GB CFExpress card which is probably one of the slowest available (it’s optimised for $/GB, not performance).
  
  I was anticipating “having to” buy a performance CFExpress card, but after these initial tests I’m not sure it’s necessary at all. It looks like I can easily take 900+ photos a minute if I want, which is already way more than I should be encouraged to, given I have to sort through them later.

• The buffer depth increases to 80-110 when dropping to 15 FPS. At 10 FPS it is effectively infinite, even with my slowest cards. That’s nice – it essentially matches the D500 in this respect, at least – and the D500 could only achieve an infinite buffer with (for its time) high-end CFExpress cards.

Autofocus

• Autofocus in low light is definitely better than with the Z7, but it still has plenty of room for improvement (which is not to say any other camera is better – I’m pretty sure no camera has what I’d consider truly good low-light AF, yet).
  
  e.g. it still basically can’t focus at all in my TV room [with the 24-70/4], which is a somewhat dim room but not dark by any means – I could sit there and read a printed book just fine, for example. Most of the time it just hunts endlessly. Subject recognition doesn’t work at all.
  
  The Z7 fails even harder – it often doesn’t even try hunting, it just outright refuses to engage the focus motor.
  
  The D500 can focus in similar light in the same room – the D500 is impressive in low-light AF ability, though it tends to over-estimate itself even so; it’ll show a green “got it!” focus indicator but the actual photos will quite often show that it missed. Still, it would at least get some in-focus photos, where the Z9 cannot.
  
  It’s worth noting that my iPhone 11 can autofocus decently in these same conditions – faster & more reliably than any of these “real” cameras. Admittedly it has a wider field of view with much deeper depth of field, so it doesn’t have to be as accurate. But still.
  
  In brighter (but still interior) lighting, the Z9 suddenly starts working and works really quite well, at least for stationary or slow-moving subjects. The transition from basically not working to working well is surprisingly sharp.
• I haven’t really tested it yet, but AF accuracy with a subject moving at non-trivial speed – i.e. my cat trotting towards the camera – isn’t great at first blush. The majority of photos have focus completely missing the head, let-alone the eyes. Oddly focus bounces in & out between every frame, like it’s hunting. The D500 would tend to hit or miss in longer batches. The Z9 is clearly superior here, since having every other photo in focus is way better for capturing a decent moment than missing ten in a row.
  
  The 24-70/4 might be a factor in this, of course. Though it seems to have pretty snappy AF, in my experience.
  
  The Z7 wouldn’t have managed any photos in focus, except maybe by dumb coincident luck, so it’s a very clear improvement over that at least.
• Subject recognition doesn’t work for close subjects, e.g. when the face fills the frame. At least for cats. It stops recognising that it’s even a face, let-alone picking out the eyes. It then tends to focus on merely whatever’s nearest, e.g. the tip of the nose.

• Eye AF consistently front-focuses, because it favours the eyelashes or eyebrows (particularly for animals) over the iris. When depth of field isn’t able to cover this up – e.g. close distances or wide apertures – it’s really obvious, because the Z9 is so consistent with focusing on the wrong thing. A more “manual” focus mode has to be used instead, like single-point AF.

• The AF system continues to not be able to distinguish stuffed toys from real animals. It was a bit stubborn about focusing on a stuffed lion’s face rather than my actual cat, for example. Not a real-world concern for me, of course, but kind of amusing.
• Auto-area AF looks much more promising, at this early stage, than the Z7 (or any DSLRs). So far it’s been pretty reliable about finding the subject (usually my cat, thus far). Not perfect, for sure, but good enough that I’m not frustrated.
  
  For years I almost exclusively used single-point AF on the Z7 because frankly it was the only AF area mode that was usable (with 1.00 firmware). Recently I tried experimenting again, and was quite pleasantly surprised that its other AF modes have been made actually somewhat usable by its firmware updates. I’ve even been dabbling with auto-area AF, in certain easy situations. But it’s immediately obvious that the Z9 is much better.
• Subject detection sometimes finds “subjects” in bizarre places, like random patches of couch fabric or shadows on a bean bag chair.
  
  This would be insignificant if it weren’t for the fact that 3D tracking will always try to track the nearest detected subject – anywhere in the frame, irrespective of where you place the tracking box. So if it detects a non-existent subject – or in any case if you just want to have it track something specific – you have to dive into the menus to disable subject detection entirely. Slow and annoying.
  
  If I place the tracking box over a detected subject and press AF-ON, sure, it should use its subject tracking smarts. Otherwise, it should just do what it’s told and stop trying to be “helpful”.
• So far, 3D tracking doesn’t seem dramatically better than the D500, but I haven’t tested it much in real-world conditions. It’s nice to have it back, and I will be testing it further in various conditions, but I’ve already seen the hallmark flakiness in some cases – e.g. where it just immediately loses the subject and focuses randomly on something else.
  
  I think Nikon’s subject tracking, as on e.g. the D500, has always been rather over-rated. But it does work well sometimes and is super nice when it works.
• I’ve noticed that the Z9 tries very hard to be “sticky”, even with “Blocked Shot AF Response” set to 1 (Quick). But if you release AF-ON and press it again, it instantly refocuses on whatever’s under the AF box. This makes some sense, I guess, but I’m going to have to train myself to feather the AF-ON button. I wish when you set it to ‘Quick’ it would just always focus on whatever is under the AF box.
  
  In auto-area AF and similar modes (as opposed to single-point) it consequently still exhibits some of that annoying behaviour where it loses the subject, focuses on the background, and is then too slow to refocus on the subject.
  
  Still, that you can re-press the AF-ON button and have it do what you want is a big improvement from the Z7, which would often stubbornly refuse to refocus on the subject until you manually adjusted focus to be on the right subject (and even then it would sometimes obstinately refocus immediately on the background again).

Image stabilisation

• Image stabilisation doesn’t seem any different from the Z7 – which is to say it’s good, but could be better. e.g. ¼s exposures hand-held at 70mm still have a low success rate. I might be seeing more interesting (positive) results with the 105/2.8, that supports the enhanced “Synchro VR”, but it’s a bit early to tell.

Responsiveness

• There’s a noticeable delay – half a second or so – for the Z9 to turn on and be ready to use. It’s faster than the Z7, but far from the instantaneous that many reviewers have been claiming.
  
  That’s with all the ‘slowdowns’ disabled, like the sensor shield and restoring AF position. Enabling those doesn’t actually make much difference, as far as I could tell.
• It’s occasionally a little slow when doing certain things in video mode, e.g. immediately after you stop recording it can take a moment or two to start responding to the controls again.
  
  The Z7 is similar. The DSLRs might have been better – I don’t remember, but in any case it’s largely irrelevant given how bad they were at video (e.g. unusable AF, no viewfinder support, etc).
  
  One thing the Z7 was infuriating about was taking up to ten seconds after burst shooting before it’d let you switch into video mode, seemingly because it refuses to switch modes until its buffer is empty. I don’t yet know if the Z9 suffers from this too, but because the Z9 buffer clears quite quickly, it’ll hopefully prove far less annoying even if it does.
• The GUI feels snappier than the Z7, but I haven’t compared them side-by-side yet. I mainly feel like image review is significantly swifter – zooming in on a photo is instantaneous, whereas the Z7 usually takes a moment. Skipping rapidly back and forth between photos is also instantaneous, whereas the Z7 had just a bit of delay. Overall it’s subtle but the effect is to make the Z9 feel significantly more powerful.
• It’s subtle if present, but it feels like the scene view (on LCD and EVF) has less latency than the Z7. The AF indicators do lag the subject / camera movement, but it’s only significant if you have very fast movement, and I don’t yet know if it actually impacts focus accuracy.
  
  It’s subtle enough that if I didn’t already know Nikon are claiming improvements in EVF latency, I wonder if I’d have noticed anything at all.
• The EVF & LCD lag significantly in some situations, involving slow shutter speeds (e.g. 1/10) and/or low light. Similar to the Z7 (and my iPhone, for that matter). To be clear, this is when not taking any photos, just looking at the screens. I think most cameras do this – I guess they figure it’s better to lower the refresh rate than have [more] noise in the image preview.
• The 60 Hz “limit” of the EVF & LCD doesn’t seem problematic to me. I have various devices with 120 Hz displays (e.g. my iPad) but frankly I’ve never seen any meaningful difference. But I haven’t used an EVF with a refresh rate higher than 120 Hz, so I guess I can’t be sure.

Video quality

• The oversampled 4k (30 FPS or lower in FX mode) is very nice, at least in H.265 10-bit HLG (I haven’t played as much with other video formats).
  
  There’s no mistaking that it has been processed – it’s definitely a little crunchy if you look closely, and especially if you compare vs the 8k down-sampled in playback. The 8k does contain more genuine detail – though not 4x as much, by any stretch – and looks much more natural with no evidence of artificial sharpening.
  
  It reminds me a bit of the results from recent iPhones in their “Deep Fusion” mode, though not as strong (thankfully).
  
  The processing settings – including several aspects of sharpening – are configurable in strength, but I haven’t played with that yet. I’m pretty comfortable with the defaults (I intend to use the over-sampled 4k mode, as opposed to 8k mode, when I want quick results that don’t require post-processing).

Reliability

• As hoped, the Z9 has yet to fail to take a photo when told to (other than in contrived, pathological cases like after filling the buffer with an 800-photo burst). It’s clearly better than the Z7. Which is a low bar, of course. The Z7 is a very unreliable camera for actually taking photos, thanks to its anaemic buffer and slow image processing. I’m hoping that continues to hold true in more demanding testing – I’ve missed the D500, which was the first and (’til now) only camera I ever used where you could trust that it would work when you pressed the shutter button.

Connectivity

• Pairing with Snapbridge on my iPhone went fine. The process is a bit inelegant, but no different than with any other Nikon cameras, and worked first time.
• Snapbridge is very snappy for camera remote control. I’m not sure how it compares with the Z7 as honestly I’ve virtually never used the Snapbridge app, but I was impressed with how low-latency it is (and laughed that you can use it to control the camera’s LCD in playback mode – I’m not sure what the point of that is but it’s amusing).
• Image download over wifi to an iPhone is pretty slow. About ten to fifteen seconds per ~50MB image. I don’t recall if that’s different from the Z7 – but I remember when image download was only supported over Bluetooth, and that was excruciating… something like up to a minute per 2MB image. So progress, I guess, though still inexplicably slow.
• It refuses to charge at all over USB from some chargers – including chargers that work just fine with the Z7. I’m guessing it requires some minimum wattage that exceeds what basic USB power bricks can provide. Not a big deal, but a tad disappointing (I’d be fine with it charging slowly, as long as it still charged).

Factory settings

• GPS is off by default and the UI is surprisingly unintuitive about it – it took me an hour and several attempts before I finally confirmed that it was off and figured out how to enable it.
  
  I guess I can understand why it might be off by default, given its potential for significant battery drain, but then standby power saving mode is disabled by default, and that has a much bigger negative impact.
• Standby power saving mode is disabled by default. This makes the camera consume a noticeable amount of power when switched on but not being used.
  
  This makes some sense as a default, I suppose – standby mode presumably incurs some delay when you snap the camera out of it, which the nominal audience for this camera might hate. But I was surprised to see 10% of the battery disappear just because I left the camera sitting on a desk for an hour without formally switching it off. This was never a problem on the Z7 or any of the DSLRs – though admittedly the Z7 has a noticeable, annoying delay to wake up from standby.
• The video format settings are just stupid by default – 4k/30 H.265 8-bit (SDR), if I remember correctly. They should be 8k/30 H.265 10-bit with HLG or N-log enabled (or ProRes – not my preference but I could at least respect that choice).
• With HLG in use the video display is flat by default. And the preference for fixing that is really obtusely named – “View Assist” – and buried in Custom Settings > Video > g8. For someone that wants to use HDR simply to get better dynamic range, I see no point in making the live preview ugly as a side-effect.
• AF is set to single point by default. Not a big deal, but kinda weird for this camera in particular – a major point of the Z9 was its new “handle anything” auto-area AF, so I’d expect that to be selected by default.
• Video AF is set to AF-F by default… I do actually use that occasionally, but I’d be surprised if so-called video professionals use it much at all – unless you’re a Youtuber you know that shifting focus during a scene is to be done carefully and rarely. AF-C makes much more sense to me.

In this post, I’m going to compare performance in the image centre between these three telephoto lenses at 400mm:

• Nikkor Z 100-400 (e.g. from Amazon).
• AF-S Nikkor 80-400G (e.g. from Amazon).
• Sigma 150-600 Contemporary (e.g. from Amazon).

Unlike in the first post, where the focus was solely on the 100-400, I won’t provide exhaustive sample images of all apertures for all lenses – that would just be overwhelming. Instead, I’ll just provide the noteworthy cases.

30ft @ 400

The 150-600 is basically the same from wide open (f/6) through to f/8. It might be a tiny bit sharper at f/6 than narrower apertures.

The perceived sharpness of the 80-400 increases slightly when stopping down from wide open, and starts to soften again at f/7.1 and narrower. Its optimal aperture is f/6.3, vs f/5.6 for the 100-400.

Note that in practice I’ve tended to favour f/7.1 on the 80-400, including on 24 MP DX cameras which have higher pixel densities than the Z7 (and therefore should be more sensitive to diffraction, not less). That’s based on a large amount of real-world experience. There’s several possible explanations for the discrepancy, but my guess is that the increased depth of field, of f/7.1 over f/6.3, helps in practice because it:

• Increases the depth of field (sometimes important at close distances or with deep subjects).
• Provides a little more tolerance for focus errors.

Prev 1of3 Next

The 150-600 is clearly the sharpest, followed by the 80-400. The 100-400 is much softer than even the 80-400. The 80-400 is sharper at any aperture than the 100-400 is at any aperture (and the 150-600 exceeds both, similarly).

This was such a surprise that I went back and took many more photos with the 100-400, in a variety of modes (various autofocus modes, manual focus, VR on & off, silent shutter on & off), but the results were consistent – the 100-400 is much softer at 400 than its eight year old predecessor, let-alone the 150-600.

Note: the difference in sharpness is partially obscured by the JPEG compression used for the images in this post, even though I used the maximum possible JPEG quality. All my written statements throughout these tests are based on comparing the NEFs in Lightroom.

12ft @ 400

The 150-600 behaves the same as at 30ft – basically the same from f/6 (wide open) through f/8. Maybe a tiny bit sharper wide open.

The 80-400 gives its best performance at f/6.3 again. As at 30ft, the difference with f/5.6 (wide open) or f/7.1 is slight. f/8 is very slightly softer again, as diffraction more clearly kicks in.

Prev 1of3 Next

Unfortunately the comparison between the three is complicated by the fact that the 80-400 back-focused slightly while the 100-400 looks like it again front-focused a tad. After accounting for that it’s clear that the 80-400 is sharper than the 100-400. But the 150-600 is much sharper than either of them.

6ft @ 400

The 150-600 is out for this particular subject distance because it can’t focus this close.

The 80-400 is slightly sharper at f/7.1 than other apertures. Similar to the 100-400 (which still saw tiny improvement up to f/8, over f/7.1).

Prev 1of2 Next

At this point the comparison is getting tricky, because:

• The 80-400 back-focused again.
• The 100-400 is maintaining its nominal focal length much better than the 80-400. This change in focal length over different focus distances is typical behaviour for lenses – the stated focal length is usually only achieved at infinity; as you focus closer, their effective focal length drops.

It’s pretty close, between the two. There seems to be similar resolution on the image sensor, so the difference in subject detail is solely because of the difference in effective focal length. If you allow for that, then there’s a notable advantage to the 100-400.

MFD @ 400

Note here that the 100-400 can get down to about 3ft, while the 80-400 is not much shorter than the 6ft looked at above, and the 150-600 is way out at 10ft or so.

So unsurprisingly the 80-400 behaves the same as at 6ft – sharpest at f/7.1. Just like the 100-400. And the 150-600 is very similar from wide open (f/6) to f/8, with maybe a very slight improvement from stopping down just a tad, to f/6.3.

Note that I’ve also included the 150-600 at 600, in case you’re interested in comparing the maximum possible magnification across the three lenses.

Note: I don’t know why there’s such significant discrepancies in exposure, particularly with the 80-400. This was reproducible. The same exposure settings were used for all lenses. Possibly the differing fields of view impacted the camera’s metering?

Prev 1of4 Next

Here there’s no contest – the 100-400 is sharpest on the sensor (albeit by only a small margin over the 80-400), but also offers much higher magnification – almost twice what either of the other lenses are capable of. This matches the spec sheets – a maximum reproduction ratio of 0.38x for the 100-400 vs 0.2 for the 80-400 & 150-600.

The 150-600 is the worst by far, for sharpness on the sensor as well as magnification – not only do you have to zoom in to “600” to get similar magnification as the 80-400 does at “400”, but both are basically at something more like 200 if not less.

In fact to my eyes it appears that there’s nothing but empty magnification in going from 400 to 600 on the 150-600.

Conclusion

😧A surprise upset! I had assumed the 100-400 would be at least as sharp as the 80-400, and of course hoped it’d be even sharper. The 80-400 has always had good sharpness at 400 in my experience, so there wasn’t a lot of room for it to be surpassed. Still, that the 100-400 is much softer (at all but the very closest subject distances) is very disappointing.

The only thing the 100-400 has going for it (so far) is with very close subjects – there, the 100-400 is vastly superior, in large part because it can simply focus much closer while simultaneously retaining more of its nominal 400mm focal length. If you expect your subjects to always be less than ~10ft away, the 100-400 is clearly the better lens.

The 150-600 results surprised me, and may be tending unrepresentative, as they don’t match my real-world experience. I do think the 150-600 is a good lens – and excellent value at a quarter the price of either of the other two – but I’ve found it just doesn’t deliver results quite as good – nor as reliably – as the 80-400, except when you utilise its 50% extra reach. I strongly suspect this is mostly due to differences in image stabilisation – the 80-400 has the best image stabilisation of any lens I’ve ever used, while the 150-600’s image stabilisation is average at best.

Granted, this is only in the centre of the frame. Maybe the 100-400 has redeeming image qualities elsewhere in the frame? A subject for a subsequent post, perhaps.

Of course, it’d be nice to see how those two lenses actually compare – I suppose I could keep using the 80-400 and return the 100-400, if the older lens turns out to be better.

Unfortunately California has decided this “weather” thing it’s never had before is the new hotness, and it’s basically rained non-stop for weeks now. So I haven’t been able to use of the 100-400 for real yet. Luckily, I was able to conscript a wild Stitch to help me do some rudimentary tests, in the interim. That’ll be the subject of this and a couple of subsequent posts.

The most important thing I want to know about any new lens is how it performs in the centre across various apertures and subject distances. That way I know what it’s capable of in the best case (the centre) and which aperture(s) to favour. So that’s what this first post is about.

Equipment

• Nikkor Z 100-400 (e.g. from Amazon).
• Nikon Z 7 (e.g. from Amazon).
• Neewer 660-LED constant light panels (e.g. from Amazon).
• Induro AT-313 (discontinued).
• Movo GH800 gimbal tripod head (e.g. from Amazon).
• Stitch (from outer space, via Hawaii).

Methodology

I tested five different subject distances:

• MFD (minimum focus distance) at 100
• MFD at 400
• 6ft at 400
• 12ft at 400
• 30ft at 400

I didn’t measure the actual MFD – all distances above are only approximate anyway, give or take a few inches – but it was something in the vicinity of 3ft, like the specs say. MFD is a bit closer at 100 than 400.

400 is basically the focal length that counts – that’s where this lens will spend the vast majority of its time – thus the inclusion of only one subject distance for 100, nor any intermediary focal lengths.

Stitch was lit (as shown in the photo above) by two Neewer 660-LED panels, set to maximum brightness & running off mains power. Diffusers were not used.

I chose to focus on Stitch’s nose because it has a nice fine-detailed fabric texture, that looked better as a test subject than the low-contrast threading of e.g. his eyes. I also deliberately focused only about a third down on his nose – not in the very centre – so that the centre of the nose, being the closest part to the camera, would be slightly out of focus. That way I could visually confirm that the plane of focus was where I expected and not short of the subject (in the cases where depth of field was so narrow as to matter).

I focused wide open using AF-C single-point (centred). I used a five second delayed shutter release, with pure electronic shutter (“Silent” mode). I did have to touch the camera between exposures, in order to adjust the aperture and press the shutter button, and this is why in some cases images are misaligned by a few pixels.

I used a fixed ISO of 64 in aperture-priority mode, letting the camera maintain constant exposure by varying the shutter speed (which ranged from 1/25 – 1/100). I did not normalise exposure in post – any variation you see in the images could be due to:

• Differences in metering based on differing fields of view.
• Error / inaccuracy in exposure by the camera.

Image stabilisation was disabled.

All the images you see embedded in this post are JPEGs with the quality set to 100%, as rendered from the raws by Lightroom Classic.

The crops are all from the exact centre, and are 1024 square.

All images were recorded as 14-bit lossless NEFs, and imported into Lightroom Classic with no modifications other than:

• Reducing the exposure by 0.75 stops. I exposed-to-the-right to maximise image quality.
• Setting the white balance to 4,500 with no tint. I left the camera on auto white-balance; I could have specified it as some fixed value in-camera, but I knew I could standardise it in post.

This also means that any built-in lens corrections, whether by the camera or Lightroom Classic, were performed. I left all those at factory settings, and I see no purpose in mucking with them since I – like most people – don’t muck with them in real-world use.

Lightroom Classic nominally applied some sharpening & noise reduction, per its defaults, but the settings were the same for all images (40/1.0/25/0 sharpening, 0/-/-/25/50/50 noise reduction).

Finally, I’ve provided the images for every aperture in a carousel, but also an A | B comparison of wide open vs what I feel is the most interesting juxtaposition (usually the sharpest aperture, though not always).

30ft @ 400

Prev 1of4 Next

Almost no change across the apertures. This is either an excellent result or a terrible result, depending on whether it means it’s sharp from wide open or never gets sharp. That’s best judged by comparing it to other lenses – a task for a subsequent post.

There’s a very slight softening starting at f/7.1 (vs f/6.3 or wider), that’s slightly more pronounced – but still very minor – at f/8. This is most likely diffraction softening and as such is expected. On the 46 MP Z7 diffraction becomes the limiting factor in acuity beyond about f/6.3 (in theory).

12ft @ 400

Prev 1of4 Next

It’s very slightly softer wide open, at f/5.6, than at f/6.3 or narrower. It’s less clear if diffraction has kicked in (as the limiting factor) by f/8 – to my eyes there’s very little difference between f/6.3, f/7.1, and f/8.

6ft @ 400

Prev 1of4 Next

Perceived sharpness increases significantly from f/5.6 to f/6.3, and then only very slightly more up to f/8.

However, I don’t see any change in actual resolution – it’s entirely just about contrast. Careful post-processing re. micro-contrast might significantly reduce if not eliminate the difference in perceived sharpness.

MFD @ 400

Prev 1of4 Next

Perceived sharpness improves significantly, steadily, all the way up to f/8 (which is as far as I tested).

As at 6ft, I don’t see any change in actual resolution – it’s entirely just about contrast.

MFD @ 100

Prev 1of6 Next

Perceived sharpness increases significantly between f/4.5 (wide open) and about f/6.3. After that there’s no meaningful change.

Interestingly, unlike at 400 some portion of the perceived sharpness difference appears to be due to actual resolution differences, not just contrast. So this is the only case in any of the tests I’ve done here where stopping down might be strictly necessary for maximum possible sharpness.

Conclusion

I can’t really compare across focal lengths, because the subject changed size (in the frame). It seems to me that the achievable acuity is pretty good, and pretty similar, at all focal lengths.

There was a clear trend w.r.t. subject distance and wide-open performance, i.e. as the distance gets shorter, wide open becomes softer in comparison to narrower apertures. Thus the optimal aperture is (in my opinion):

• MFD:
  • 100: f/6.3 (-1 stop)
  • 400: f/7.1 (-⅔ stop)
• 6ft: f/6.3 (-⅓ stop)
• 12ft: f/5.6 (wide open)
• 30ft: f/5.6 (wide open)

In some cases you do technically get slight improvements in perceived sharpness by stopping down further, but if you have to do so by raising ISO then it is definitely not worth it – the additional noise will outweigh the benefits.

Keep in mind, also, that at 400mm even when there was a difference in perceived sharpness, it was basically only due to changes in contrast. As such, in theory it can be fully compensated for in post-processing with e.g. micro-contrast adjustments. So I definitely wouldn’t stress if I forgot to stop down when my subject came super close.

It’d be great if wide open wasn’t slightly softer-looking at close distances, but as just noted the difference is largely correctable in post. More importantly, at most distances wide open is basically as sharp as any narrower aperture.

In a nutshell, this is an excellent result overall. At most subject distances, at 400, the only reason to stop down is if you actually want increased depth of field.

That all said, the real test is how the 100-400 compares against some of its competitors…

Sorry, we are unable to accept reviews for this product. This product has limitations on submitting reviews. There can be a number of reasons for this, including unusual reviewing activity.

Hmmm… curious.  I tried revising my star rating from 2 to 5 to see if it were so blatantly influenced by that, but it did not make a difference.

Anyway, FWIW here’s my review:

First up, the Blink XT cameras do not work with normal batteries – you have to buy quite expensive Lithium batteries.  Use of any other types of AAs will result in the camera not triggering reliably, failing to record full videos (or at all), etc.  So factor in about $20 extra per camera for a pair of such batteries.  Also, the two year quoted battery life appears to be a joke – I had to replace the first set of batteries after only a month or so.

Second, the video quality is not great.  They’re ostensibly 1080p but it looks both upscaled (probably from 720p) and it appears the video is recorded on the sync dongle, not the camera itself, so it’s subject to any radio interference issues that might exist, which will result in noticeably degraded video quality – or recording corrupting or cutting out entirely.  Overall the video quality, even in the best case, is like that of a very cheap smartphone (as of 2018), or say a 2010 iPhone.

Third, the only way to remotely control the cameras, and view recorded videos, is via mobile apps.  No desktop apps, no website, nothing.  So it’s very tedious to view the recordings, manage them, etc.

Fourth, the mobile app for iOS is not great.  It’s very slow – Cloud-saved videos are never loaded in advance, only on demand, and can take up to a minute to start playing.  It’s also a bit buggy.  e.g. a lot of the time it’ll fail to do whatever you asked, responding instead with a long delay ended with an error message along the lines of “the camera is busy”.

Fifth, wireless range is limited – I have one camera only about ten metres from both my wireless router & the sync module, through one exterior wall, and the video quality is noticeably degraded sometimes.  I tried placing one camera with line of sight about 30 metres away, and it worked (barely) for an hour or two and then never again, until I moved it much closer.

Sixth, motion triggering is inconsistent and lacks important configuration options (like zoning to denote areas to ignore or conversely to focus on).  e.g. for one video looking out the front of my place, it unavoidably has the street in view, which means that even on minimal sensitivity, we get a video & notification every single time a car goes by on the street.  Yet it still won’t reliably trigger when a human walks up to the front door, until they’re right in front of the camera.  Yet it’s nonetheless sometimes triggered by squirrels up to 10 metres away.

So, solidly not recommended.  Not the worst thing ever – the system does function in a very minimal sense, and I’ve managed to get some utility out of it, but it’s definitely disappointing – and many of these errors could surely be easily fixed by better software, firmware, or hardware design (e.g. support for normal batteries).

It’s interesting to me even now because the aesthetics of iOS have been stuck in iOS 7 ever since.  I still don’t like the look, the design language, how many things operate – the interface is ugly, unintuitive, lacks personality, and – as the hosts of ATP might say – is absent the whimsy that defined Apple for decades.

It felt like a betrayal, too – now iOS, as of version 7, looked like a cheap Android rip-off.  Apple had wilfully and pointlessly thrown away their most important positive differentiators.  Insult was further added to injury by the mere existence of Windows Phone Metro, which – while still ugly to me too – at least demonstrated originality and a kind of bravery – it at least had a style, even if it wasn’t the one for me.

And it was dog slow.  It basically killed my love of the iPad, because it made my iPad 3 frustrating to use.  Even when I later got an iPad Air 2 (as a hand-me-down), my iPad love never really rekindled.

Nonetheless, I had been wondering for a few years: were I to go back now to iOS 6, would I be revolted & repulsed by it, and suddenly realise that iOS 7 and its ilk are in fact the current pinnacle of user interface & visual design?

A few months ago I got out my original iPad and turned it on.  It was running iOS 5, the last version of iOS support on it.  I hadn’t intended to go back in time – I’d forgotten entirely that it was pre-iOS 7.  I didn’t realise straight away, either.  My first thought, upon booting to the home screen, was “wow, this looks amazing”.  It genuinely took me a while to figure out why this non-Retina, decade-old, square & heavy iPad felt fantastic.

Then I realised – because it looks good and is easy to use.

Without further ado, my until-now unpublished iOS 7 first impressions:

• It’s buggy. The task switcher has a terrible time dealing with landscape orientation.
• It’s slow. Both in general – perhaps just lacking some optimisations – and by apparent design flaws. e.g. many new animations are unnecessary to begin with, and unnecessarily slow to boot, and you can’t interact with things until the animation is done. It’s quickly frustrating.
• The new slide-up gesture (for the little control sheet) steals scrolls periodically, which is exceedingly annoying. Perhaps in time I’ll recalibrate where I need to touch things in order to avoid that, but it’s annoying in the meantime.
• Actually installing it was a pain and took multiple attempts, as per usual for any system restore. Le sigh.
• Spelling correction is more aggressive now, and will even re-incorrect things after you explicitly fix them. Fucker.
• To delete emails you now have to swipe the opposite direction – from right to left. No obvious reason, and certainly no indication on how to do that.
• The new icons and dock design look like UI mocks. By someone who’s either not very good at them or just needs a really basic placeholder. They’re probably the most disappointing thing about iOS 7 so far.
• The new lock screen is obtuse, as others have noted. The whole slide to unlock debacle is ridiculous and Apple has no excuse for it. But furthermore, it displays your chosen lock screen image arbitrarily cropped, and jitters it about randomly in what must be intended to be this infamous parallax effect, but in reality has no apparent relationship to the orientation of the iPad, and so just looks broken and stupid. Big cock-up all round there.

I love (meaning am tremendously sad) how certain aspects of those first impressions have lasted – some becoming huge memes of their own (e.g. damnyouautocorrect.com).  And how some parts of the iOS upgrade experience – like having to do the install repeatedly to get it to work – persist to this day.

Autofocus

Photo mode

Autofocus is a problem.

It is very clear that the Z7’s AF system is not in the same league as the Advanced Multi-CAM 20K system in the D500, D5, & D850.  I’m increasingly concerned that it doesn’t even match up to the much older 51-AF-point systems used in much older DSLRs going way back to the 11-year-old D300.

As I immediately noticed from the moment I turned the camera on, it has big problems in anything approaching low light, especially with the slow (f/4) kit lens.  Not just night photography low light, but indoor lighting low light.  e.g. under 250W-equivalent LED ceiling lights, in a small room, shooting at ISO ~800, it struggles to focus accurately even on high-contrast, stationary subjects.

In fact for a while during my testing it back-focused to infinity, vs my subject 2 metres in front of me, and consistently kept focus there for a dozen photos, despite having AF-C engaged continuously, in single-point AF mode, with that point on my subject.

[Edit:  DPReview also saw the exact same behaviour, in all respects.]

In bright light – e.g. direct sun – it seems to do fine, but then so does any camera from the last fifty years.

Another very concerning and frankly infuriating behaviour is that it simply won’t even try to focus if the subject is significantly out of focus to begin with.  Every other camera I’ve ever used in my life would at least resort to racking the focus plane back and forth, but the Z7 simply will not do anything.  You have to use manual focus override to bring the subject closer to being in focus, before the Z7’s autofocus system will even bother engaging.  This is mind-bogglingly stupid – and a real problem if you remapped the ‘function ring’ on your lens to a function other than focus (e.g. aperture control).

Thus far in my initial experiments using the FTZ mount adapter and the Sigma 50/1.4 Art – where you’d think the huge increase in maximum aperture might alleviate some of the AF sensitivity problems – I’ve been disappointed.  The much wider aperture seems to help a little bit, but not enough to make the AF system feel up to the Nikon name – nor the price tag for the Z7.  (and yes, this is photographing wide-open – I’m well aware that the Z7 will stop the lens down to the shooting aperture during autofocus (down to a limit of f/5.6), unlike Nikon’s DSLR)

Next to consider are the AF modes, and AF tracking.  For background, frankly I never found 3D Tracking in Nikon’s DSLRs to be very good – it’s very easily confused and will usually fail to track even the most clearly distinguished subjects.  I have & do use it occasionally, but about the only scenario where I’ve found it consistently usable is birds in flight against a flat sky – at which point it doesn’t actually perform any better than Auto mode, really, since it’s merely focusing on the only thing in the frame that it can.

Put simply, the Z7 has some dumb – baffling – user interface flaws around its AF modes, the most egregious being that:

• You cannot configure different physical buttons to engage different AF modes.  My D500, for example, has the AF joystick configured so that pressing it engages single-point AF, while the dedicated AF-ON button engages a different mode (e.g. 3D Tracking, one of the dXX modes, or Group mode).  You cannot do anything like this on the Z7, which is a bizarre regression and a serious problem not just for its own sake, but also because it compounds many of the Z7’s other flaws, below.
• Face detection only works in Auto mode, and Auto mode continues (as with all prior Nikon cameras, and digital cameras in general) to be useless in most situations because it is utterly incompetent about determining your intended subject.  It’s also incredibly sticky once it’s focused on something – face or otherwise.  You actually have to move whatever it’s stuck on out of the frame entirely, re-engage AF, and hope it picks something better.  I really wanted to use face detection, but repeatedly I find myself rushing to switch to single-point AF mode in order to get the shot that Auto mode is blocking. So while face detection itself is useful, and I’d like to use it more, the problem is that it’s rarely the only AF mode I need in any given situation, and Auto is basically never a useful AF mode.  Given the inexplicable inability to configure different buttons to engage different AF modes, you’re stuck with this awkward choice of being able to conveniently focus on faces – but only faces, and only when it works, which is only sometimes – or do it all ‘manually’ with single-point AF mode.  Or try to frantically switch back and forth between the two modes constantly, which I found to be impractically slow (and dangerously reminiscent of entry-level consumer DSLRs where basic functionality is buried in menus).
• Face detection struggles in the presence of multiple faces.  It makes strange choices about which face to default to, and switching between faces is basically a losing game of whack-a-mole – first you have to wait for it to recognise the face you want at all, then select it before it loses it again, all the while doing your best to guess which ‘direction’ the face you want is from the current one – you can only use the left & right buttons of the d-pad, even if the faces are arranged vertically, and the movement direction isn’t even consistent.  e.g. several times I hit left and it jumped to a face to the right of the previously selected one.
• The ‘tracking’ AF mode is a sub-mode of Auto mode, and frankly I find it a bit confusing to use as a result since you have to remember which of three states you’re in (normal Auto, tracking point placement, or tracking active) and use a variety of buttons to move between these states.  It’s not quite as slow to engage as I feared from reading early reviews, and thus far it seems markedly superior to 3D Tracking in terms of actually tracking the subject, but the bad user interface really discourages its use.

The baffling thing in all this is why Nikon just didn’t do the incredibly obvious thing that they’ve basically already established with their pro DSLRs, i.e. have a dedicated AF mode – ideally the default – where you place the AF point wherever you like, position it over your subject, and hit AF-ON to start tracking, and continue tracking until you release AF-ON.  Nothing could be simpler, and Nikon’s DSLRs have done this for over a decade.  The lack of a sensible AF interface is an inscrutable, unforced error, which makes me genuinely question who designed the Z7, and whether they’d ever used a camera before.

Video mode

One of the main attractions to me of the Z7 over all Nikon’s DSLRs is the expected improvement in video capability.  By all rights the Z7 should be dramatically superior to any DSLR, for video, even if only because it can finally do phase-detection autofocus in video mode.

Instead it’s a mixed bag.

The ability to do full-sensor-width UHD, rather than the severely cropped UHD of the D500, is very nice, and while I haven’t yet had occasion to do very wide angle video, I know when I do I’ll be very happy to actually be able to do it (even a 10mm lens on the D500 doesn’t give you an ultra-wide UHD video frame, because of the severe cropping).

Being able to use the viewfinder while recording video is a big improvement for general usability, and also stability – having that third point of contact, and your arms in closer to your body’s centre, make for a much more stable camera hold.  It’s also correspondingly easier to record for long periods, since it’s an overall much more comfortable position.

Unfortunately, all of that is really undermined by the AF problems.  Just as with photo mode, of course, AF in video mode struggles in anything even vaguely reminiscent of low light.  And in video recording you just can’t have certain behaviours, like racking focus back & forth searching for correct focus.  Alas, the Z7 does that constantly.  Its video AF performance seems very similar to the purely contrast-detection based implementations in Nikon’s DSLRs.  It’s basically unusable, in my experience so far… maybe in bright daylight it’ll prove more reliable – I have not yet had the opportunity to test it in such circumstances.

So for now video mode remains predominately manual focus, which is a huge disappointment.

Manual focus

Thankfully the manual focus story is much better than the auto one.  The ability to digitally ‘zoom’ in the viewfinder, at the press of a button (configurable, of course), is extremely helpful for manual focusing (and verifying accurate autofocus).  It’s the single most important focus feature in the camera, by far.

Focus peaking should be very helpful, but in practice I’ve found it to be inexplicably difficult to engage to begin with, and even then it doesn’t work well in many situations – e.g. it doesn’t work at all at high ISOs.  While I did ultimately discover that if you switch the lens into manual focus mode, focus peaking enables persistently, it’s frustrating to basically be coerced out of AF entirely – given that when you’re not in complete manual-focus mode, getting focus peaking to show up requires holding down AF-ON (or similar), and moving the focus ring far enough to trigger peaking.  It doesn’t sound like much, and maybe it’ll become more natural with practice, but right now it’s an awkward combination of actions.  It’s baffling to me that focus peaking, when enabled, isn’t simply enabled – it shouldn’t require holding down extra buttons and jumping through hoops.

The 24-70/4 ‘function ring’ is definitely different for manual focus.  It’s noticeably sloppy compared with the auto-clutched AF rings typical of Nikon’s DSLR lenses – meaning, primarily, that you have to turn it a noticeable amount before it engages at all (though this pick-up ‘slop’ has always varied between lenses, and the 24-70/4 isn’t necessarily worse than all prior ones).  I’m also finding it difficult, so far, to get it to move the focus plane consistent amounts – presumably attributable to the ‘acceleration’ behaviour it has, whereby the speed at which you move the ring apparently affects the magnitude of focus plane movement.  I do expect that I’ll get used to that in time, just as I did when acceleration was introduced to computer mice many years ago.  For now though it makes manual focus adjustment a tad more difficult than I’m used to.  It also remains to be seen how consistent the implementation is – if you’ve ever used a cheap computer mouse vs a high quality one, you’ll know the subtle difference in accuracy & precision.

Ergonomics

Size, weight, & balance

With a small lens (e.g. the 24-70/4 kit lens) it’s overall not too bad, though the small size – particularly of the grip – makes it noticeably less comfortable to use than a D500, D850, or D5.  With a larger lens – e.g. a 70-200/2.8, it’s actually less of a problem, since the whole setup is much more front-heavy, putting the majority of the weight on your lens hand, so the smaller, dainty grip is less of a concern.  Nonetheless the controls – shutter, ISO button, exposure compensation, etc – do feel very cramped, though this is odd as they don’t appear, visually, to be packed any more densely than on the D500.

Control placement

The placement of the exposure compensation button is different to Nikon’s DSLRs, and is in a pretty awkward spot – it’s now much too close to the right edge of the camera.  I frequently hit the ISO button by mistake as my pointer finger searches in vain for the exposure compensation button, starting with where it used to be on all prior Nikon DSLRs.  Presumably I’ll get used to this in time, but it’s a strange and seemingly unnecessary change that simply makes the exposure compensation button harder to reach.

Similarly the placement of the d-pad on the back of the camera is very awkward – it’s basically impossible to use comfortably or quickly with a normal hand-hold, requiring you to move your hand off of the grip somewhat in order to be able to reach the d-pad with your thumb, and move your face away (if you use your left eye to the viewfinder) to make room.  This is a bit of a hinderance to an otherwise exciting new possibility, given the EVF, of being able to adjust lots of settings quickly without taking your eye from the viewfinder.  In practice I find it quicker and safer (for the camera’s sake) to just use the rear LCD as before, as that gets my face out of the way and allows me to move my hand more freely.

Speed

One surprising thing I’ve noticed is that some of the camera’s controls are noticeably laggy.  Rotating the control dial, for example, to change aperture, has a very noticeable delay before the aperture actually changes, and the display(s) update.  Only a fraction of a second, to be clear.  Nonetheless, on Nikon’s DSLRs going back as far as I can remember, there has always been zero perceptible delay for such basic actions as changing the aperture.  While it’s not strictly speaking a significant problem, it is a constant reminder in use that the Z7 is sluggish.

In fact, one very noticeable manifestation of that “but I am le tired” feeling the camera conveys is when you put your eye to the viewfinder – if the camera has been idle for long enough (tens of seconds, I think), it takes a couple of seconds for the viewfinder to turn on.  I’ve already had several awkward moments where I’ve had people posed in front of me, brought the camera up to my eye, and then had to pause for an uncomfortably long time while I wait for the viewfinder to turn on.  It’s not just me that notices this – my subjects notice the delay too, and find it a bit unsettling – like I’m staring at them motionless for an uncomfortable amount of time.  I’m presuming this is some overly-aggressive power saving feature, which I wish I could just turn off.  (FYI I have the camera configured to viewfinder priority mode, since that’s the only one that makes any sense to me, but I haven’t explored if other modes alleviate this problem).

Info & Display buttons

I basically never used these two buttons any other Nikon DSLR – maybe occasionally in video mode to toggle the display of various things, but otherwise I just had no apparent need, or had better ways to get at the same functionality.

The Display button doesn’t really change from Nikon’s DSLRs – as before it toggles through various display ‘HUD’ modes.  As always, I wish I could more precisely configure what’s shown – certain information is only shown in certain modes that otherwise contain heaps of crap I couldn’t care less about, so being able to cherry-pick the exact ‘widgets’ I want to show would be ideal, and eliminate the need for a mode-switching button entirely.

The Info button and associated functionality is something I find myself naturally using on the Z7.  It’s unfortunately awkward to use via the touchscreen, as inexplicably you must double-tap everything to get settings to actually apply, which I consistently forget because it’s so unintuitive.  Using the d-pad & ok button is much safer, and so I do that, which is fine most of the time.

Being able to configure the contents of the Info panel is of course what makes it much more useful than before.  And though the number of items you can place there simultaneously is fixed, and seemingly not many – twelve – I actually find myself searching for useful things to fill the last couple of spots.  So thus far I’m pretty happy with it – I don’t mind using it as opposed to dedicated physical buttons, for the most part, though for now I did still find myself occasionally reaching for the AF mode and bracketing physical buttons, that no longer exist.

I also am having a surprisingly hard time remembering that there’s still a release mode physical button, albeit in an awkward location now – I keep going through the Info panel instead, which isn’t really a problem but makes me feel a little silly sometimes.

Image stabilisation

It’s still early for me on image quality – I have a lot of photos taken with the Z7 I haven’t even gone through yet – so I’m not certain how good or bad the in-body image stabilisation is.  My impression from chimping is that it’s not all that great, based on significant numbers of camera-motion-blurred photos, but I’m also quite self-aware that I’m coming from (primarily) a 21 MP D500, to this 46 MP Z7, so it’s an intrinsically much more demanding sensor re. motion blur.  And the lightness of the Z7 probably isn’t doing it any favours here, either.

Certainly I think it’s fair to say it helps with previously unstabilised lenses, like the Sigma 50/1.4 Art.  More testing is needed, though, especially to estimate the degree to which it helps.

One of my pet peeves about the D500 is that it has huge mirror shock.  Certain shutter speed ranges – typically ~1/50 to 1/160 – with some lenses are utterly unusable on the D500.  I’m optimistic that the Z7 will not suffer from such issues, given its ability to utilise a purely electronic (i.e. no moving parts) mode.  I’ve not yet put it through its paces in those specific scenarios, though (e.g. macro photography with the Sigma 105/2.8 is the worst such case with the D500, that I’ve encountered).  I know from past experience with mirrorless cameras (e.g. a7r II, GH4) that these shutter speeds don’t have to be verboten.

Image stabilisation in video mode does seem noticeably better than on the D500 (with a VR lens).  I haven’t explored it much yet, though.

Image review

One thing I noticed very quickly upon picking up the Z7 is that it has an ugly flickering problem when panning photos in review mode.  It’s at its worst when using the d-pad for panning, but also shows up a little bit when using the touch screen to pan too.  It’s very distracting, and I don’t understand why it would be doing that, nor how this is considered acceptable by Nikon.  I’m hoping it’s some very stupid but fixable bug that can be addressed in a firmware update.  No other Nikon camera I’ve ever used had this issue, or anything like it.

Otherwise though it’s just as on any prior Nikon DSLR – scrolling between images is plenty fast, zooming is instantaneous, the touch screen works nicely including pinch-to-zoom & double-tap-to-zoom, etc.  It’s a genuine compliment to say that image review continues to work – flickering notwithstanding – as on Nikon’s prior cameras.

Silent mode

I’m a big fan of silent mode.  It unfortunately doesn’t always work – under some artificial lights – certainly fluorescents – it’s useless as it results in pronounced, ugly banding.  But under better lighting (e.g. LED), or natural light, it has no such issues.  The ability to take photos silently is really handy in a lot of situations, and I use silent mode by default even when silence isn’t strictly necessary (in part also motivated by a desire to eliminate sources of motion blur).

I do wish that the camera’s flicker detection feature could be enhanced to provide a warning to you when you’re in silent mode and it suspects banding will occur – a few times I started taking photos only to find out some time later, when I finally checked them on the LCD, that they were ruined by banding.  Since it’s not always obvious when it will occur – nor does it necessarily occur consistently – it’s currently something you have to be careful about, currently.

Wifi

The Z7 claims to have a new ability to stream photos as they’re taken to a computer.  That would be really handy sometimes.  Unfortunately, the Wireless Transmitter Utility software that you need on your Mac, in order to do this, doesn’t work.  The installer doesn’t work, more specifically.  After clicking through the first few screens, it abruptly says it’s installed, but it isn’t – nothing has been installed.

My guess is that it’s incompatible with the current version of macOS, Mojave.  Officially they don’t claim WTU is Mojave-compatible.  Mojave has been out in various forms, including public let-alone developer betas – for most of this year already, so there’s zero excuse for Nikon’s software being incompatible at this point – if indeed that is the issue.

Memory card

I do like the XQD format in general – the cards are fast, robust, & reliable.  Unfortunately right now they’re also the most expensive they’ve basically ever been, despite greater market demand than ever, more manufacturers than ever, the lowest commodity NAND prices in years, and broadening adoption across multiple camera brands.  And since Nikon didn’t see fit to include an XQD card with U.S. orders – unlike their actions everywhere else on the planet – I find myself with just one XQD card for now, purchased way back when they weren’t so insanely expensive.  And that’s a problem for a camera that can operation at 8 FPS with ~60 MB files.  For the first time in pretty much ever, for me, this week I found myself abruptly unable to take any photos because I had no space left on any available memory card (nor any way to get the photos off wirelessly, thanks to SnapBridge’s refusal to transfer raws, and WTU’s inoperability as commented on above).

So that’s unpleasant.  It appears for the foreseeable future I’m going to have to live with this problem, and do my best to mitigate it – at least until XQD card prices come down dramatically, to something more sensible.  While I don’t really care about the lack of a second slot, the lack of an SD slot is a big problem given where the XQD market is right now.

Also, for the Sony fans that think the a7r III is superior specifically because it has two memory card slots – no, it doesn’t.  Only one of those slots supports UHS-II.  The other slot is basically useless, given how slow UHS-I is.  I have absolutely no use cases where I could reasonably make use of a UHS-I slot, in a 46 MP camera.  The Z7’s XQD slot is capable of much higher speeds than UHS-II.  Alas only for a king’s ransom, currently.

24-70/4

Nikon (and many reviewers) made kind of a big deal about how small they believe this lens is.  It’s a fairly small lens I suppose, though not remotely as tiny as the 18-55s you get with Nikon’s DX DSLRs, despite having a similar focal length & aperture range.  It’s not that much smaller, volume-wise, than the 16-80/2.8-4, despite the latter’s much wider focal length range and wider aperture (albeit without full-frame coverage, of course).  Maybe that’s an unfair comparison – certainly I’m more familiar with DX lenses in this focal range, than FX ones.  I don’t know how it compares with 24-105/4 or 24-120/4 kit lenses of yesteryear.

Regardless, I’m not impressed by its size at all.  Not that I think it’s too big – I’d actually much prefer it be bigger and have a better focal length range (e.g. 24-120), or a bigger aperture (e.g. f/2.8).  I’m interested to see the Z-mount 24-70/2.8 next year.

I can’t comment on its optical quality yet – I haven’t reviewed enough photos.  Certainly it’s a big net win over my D500 with pretty much any lens, in terms of sharpness, though the massive sensor resolution difference is presumably the biggest factor in that.

Its weather sealing seems pretty poor – I seem to recall Nikon asserting that it has pretty good weather sealing, yet within seconds of its first use, cat hair was getting inside it through the telescoping barrel.  I definitely would not use this lens in a wet, dusty, or hairy environment if I could avoid it.

One small but odd note – the lens hood is surprisingly difficult to attach, whether in use or in inverted stowage mode.  The last bit of rotation – to get it to ‘click’ on securely – requires a surprising amount of force, so much so that I’m really worried I’m going to wrench the lens in half.  I’ve had a few lenses in the past where this operation required a bit more force than I’d like, but none nearly so bad as this one.  It makes me wonder if I’ve got a dud copy of the lens hood, or somesuch.

(it also made me, upon first attempt, spin the hood around about five times look for the latch release button that it must surely have had, given the resistance – kind of like rotating a USB type A plug six times to permute it through the four-dimensional space it exists in, in order to get it to plug in successfully in our three-dimensional space)

Overall opinion so far

I’m not returning the Z7 yet.  I actually don’t expect that I will – despite its many shortcomings, I think it’ll still work well for some of my intended uses.  I’m definitely not selling my D500 any time soon, though.

I guess the simplest expression of my feelings is to say that:  I’m not angry with you Nikon – I’m just disappointed.

The Z7 should have been a tour de force entrance into mirrorless for Nikon, leveraging their class-leading DSLRs to launch an unbeatable mirrorless camera.  They seemed to have all the advantages & resources they needed.  That they’ve fallen short of that, and produced merely a decent mirrorless camera, is hugely disappointing.

I didn’t even cover some the features that are missing entirely – e.g. sensor shift image stacking.

I’d like to hold onto hope that Nikon will fix a lot of these issues, and add the more glaring missing features, in a future firmware update.  They technically could, at least in some cases.  However, that would be a dramatic departure from their modus operandi to date.  A hugely positive one, for sure – but just as they seem to have not quite known what they were doing in designing the Z7, I fear they also don’t really know what they’re doing with their firmware strategy.

FWIW, here’s my bug fix / feature enhancement list, roughly in descending order of importance:

1. Fix the AF system so it actually works.
2. Fix the AF interface to not be so hard to use.
3. Fix video focus so that it works well, and doesn’t imitate a mediocre contrast-based system.
4. Fix the unusually long delay in the viewfinder turning on.
5. Fix focus peaking so that it’s actually enabled when it’s enabled.
6. Support clipping warnings (zebra stripes) in photo mode.
7. Fix the flickering in picture review during panning.
8. Warn about banding in silent mode shooting under flickering lights.
9. Reconsider control placement, and the general size of the grip re. its current diminutive stature.
10. Fix the control lag.
11. Fix SnapBridge to support NEFs.
12. Make the Wireless Transmitter Utility actually work.
13. Customisable Display modes.

These are of course just limited to basically fixing the obvious shortcomings & bugs the Z7 currently has – it’s a much longer list if we incorporate ‘wishlist’ items like leading-edge video capabilities (8-bit H.264 video, in 2018?  Come on…).

• No XQD card included in the U.S.A.  This is disappointing, since it appears that every other country on the planet is getting XQD cards included in theirs, to a value of ~$150USD, so it feels a little mean that the U.S.A. is getting screwed.  Especially since by all accounts U.S. shipments of the Z7 were delayed by nearly a week compared to most of the rest of the world.  It also seems like simply a bad idea on Nikon’s behalf – very few people will have an XQD card already (luckily I have one and only one, from my D500), so Nikon’s running a real risk that a lot of people will open their new shiny only to realise that there’s no memory card they can use in it, and acquiring one is going to be hard (local retailers don’t seem to stock them consistently) and very expensive (XQD cards are currently selling at all-time high prices, despite there being more brands selling them than ever, and more demand than ever, and commodity NAND flash being at its lowest price in a long time… grrr).
• Autofocus really struggles in “low light” (e.g. a well-lit restaurant at night), where the D500 would have no problems at all, using the kit 24-70/4 lens.  In fact at first I thought the camera was faulty, because I could not for the life of me get it to take a photo, of anything.  Eventually I realised it was defaulting, out of the factory, to Focus-priority, and once I switched to Release-priority it started working.  But focus was missed most of the time, usually significantly (e.g. headshots had no part of the head in focus most of the time; at best the ears).  This was true irrespective of focus mode.  In fairness, the D500 is over-confident in its autofocusing abilities – in similar conditions it would also miss focus in many shots, despite claiming it had quickly acquired focus.  Note also that “Low Light AF” makes no apparent difference, neither in autofocus speed, ability, nor accuracy.
• It’s a very small camera.  It has some density to it, so it doesn’t necessarily feel cheap or plastic, but ergonomically it’s not great.  The D500 is a much better camera ergonomically (as is the D850, being a very similar design).  The Z7 in principle has an interesting advantage which is the ability to do everything through the viewfinder, but the camera is so small and squished that having your face up against it, to look through the viewfinder, makes it very difficult to use any of the buttons or the D-pad.  It’s doable, but it’s awkward and I won’t be making a habit of it.  The D500 / D850 / etc are actually much more usable when your eye is at the viewfinder, control-wise.
• Button placement is a bit weird.  The D500 / D850 / etc have a superior layout – and more buttons.  My thumb rests over the ‘Disp’ button by default, not the AF-ON where it should, because the camera is so squished that the ‘Disp’ button – relative to the hand grip & other buttons – is basically where AF-ON is on the D500 / D850 / etc.  I hope I’ll get used to it, but it is definitely more awkward to hold the Z7 with your hand on its AF-ON button, because your entire hand and fingers are all relatively far to the right edge of the camera, putting a lot more torque on your grip in order to hold the camera flat.
• The function buttons on the lens are actually an improvement over the equivalents on Nikon’s DSLRs – they naturally rest under two of my fingers, more or less, making them easier to use.
• The mount diameter is way bigger than the old F-mount.  Not that it’s intellectually a surprise, but upon first seeing it in person I was irrationally gleeful.
• Image quality vs the D500 in low light appears mixed… even by the most optimistic objective measures the D850 (and by extension Z7) are only about 2/3rds of a stop better than the D500 at ISOs 100 and above (the ISO 64 base does push the advantage to one full stop in principle, vs the D500 at ISO 100).  However, given the recent, disappointing revelations from DPReview on the nasty banding exhibited by the Z7, my fear is that the D500 will actually turn out to have better image quality in many situations (i.e. anything with significant dynamic range).  This is obviously very disappointing for a very expensive, top-of-the-line, brand new camera with an FX vs DX sensor size advantage.
• Contrary to some reporting, and some of Nikon’s own misleading product material, 100fps & 120fps 1080p video is only available from a ~DX crop region.
• Focus peaking is very difficult to actually get to work.  It took me nearly an hour to figure out how – it only appears if (a) you have AF-ON held down, (b) you move the manual focus ring on the lens a significant distance in order to engage MF override, and (c) you have a lot of light and contrast in the scene.  In low light, or scenes with low contrast, it simply doesn’t show any peaking, even on the most sensitive setting, and provides no indication why.  This is all very unfortunate, as competing focus peaking systems in every other mirrorless camera I’ve ever used all perform much more reliably, easily, and consistently than the Z7’s system does.  e.g. the Sony a7R II’s focus peaking was excellent in practice for ensuring correct focus, whereas my tests so far with the Z7, when it bothers to work at all, have shown that it’s not accurate nor clean enough for me to actually get correct focus most of the time.  It’s much faster & more reliable to just engage image zoom and focus without peaking.  Also, peaking doesn’t work when zoomed in.
• The focus ring on the 24-70/4 is awkwardly placed – it’s way too close to the camera body, which is very thin to begin with, so it feels like you’re picking your nose when you operate it.  Even with a light lens like the 24-70/4, holding the lens by the focus ring makes the entire thing very front-heavy.  The focus ring is also very thin, making it a bit difficult to find and get a good hold on.
• Being able to zoom in, in the viewfinder, is awesome.  I’ve used this previously on other mirrorless systems and know from that experience that it’ll be immensely valuable in getting focus correct.  It also works pretty intuitively – e.g. it zooms in on the selected focus point, naturally – and can be assigned to most (but bizarrely not all) the configurable buttons for easy toggling.
• I miss the Nikon rubber eye-cup add-on I applied to my D500.  The Z7’s naked viewfinder, while slightly rubbery, is very hard in comparison, and – being – rectangular & flat – doesn’t fit any human face I’ve ever encountered.  No different from most cameras, of course – I just hope Nikon release an equivalent eye-cup for the Z7 soon (though I worry, from looking at the viewfinder assembly, that there’s no apparent way to pull it apart, attach anything to it, etc).
• On first use the battery jammed in the battery slot, requiring some shaking and application of fingernails to force it out.  Very weird – I’ve never encountered this in many years & many Nikon cameras.  It hasn’t done it since… yet.
• The box it comes in is surprisingly large given it’s a small camera & lens.  Much bigger than the equivalent box for the D500, or any of Nikon’s consumer DSLRs.
• The fully electronic (“silent”) shutter is very nice.  The D500 is a 5 AM garbage truck in comparison – it has always bothered me using the D500 in any even remotely quiet environment.
• Viewfinder blackout is so-so.  While I’d seen videos on YouTube demonstrating it in various modes etc, in practice I find it’s much more difficult than I expected to track moving subjects when shooting at anything approaching the maximum frame rate (8 FPS).  The D500, despite having significant black-out itself vs the D5, is notably superior than the Z7.
• SnapBridge is stupidly hard to get to work – mainly in the initial pairing.  It took me multiple tries and about an hour overall to get it to finally pair to my iPhone.  It requires an extremely precise, pedantic, and rather long sequence of steps in order to get it to pair, and some of those steps are not documented by Nikon.  I vaguely recall it being similarly bad with the D500 when I first got it – thankfully it’s a process that only needs doing once per camera body, in principle.

• The fan control algorithm is a bit amateur.  It oscillates back and forth in frequency at a high enough frequency (0.1-0.2 Hz) – and with significant range – that it’s quite noticeable, audibly, and sometimes distracting.
  
  

• For some reason the full-load CPU frequency on my machine has dropped from 3.6 GHz to 3.4 GHz.  I have no idea why.  The inlet temperature to the case is actually lower now, too.  The workload isn’t identical, so perhaps this is a natural result of subtle workload differences (e.g. use of AVX512 vs not, or something like that – most Skylake Xeons have significantly lower clock frequencies when the AVX512 unit is in use, though AFAIK the relevant data-sheets aren’t available publicly for the specific SKUs Apple use in the 8- and 10-core iMac Pros, so I can’t be sure).
  
  
  Note the 4500 (Hz) limit on the Y axis.  Still merely aspirational, as far as I can tell.  Even under the lightest loads I’m still yet to see it exceed 4.2 GHz, according to iStat Menus (or Intel’s Power Gadget).  Though I don’t put too much stock in those, as alluded to in my first impressions post – I doubt they’re relying on actual turbo bin residency counters, but rather just an average over a relatively large period (e.g. using MPERF & APERF).  (I’m not actually sure, off-hand, if Skylake has proper residency counters for this purpose)

• ‘System’ power draw as reported by the the machine’s own “Total Power” sensor maxes out at about 350W, but (including some external hard drives and other such devices) my UPS says 550W is being drawn.  For comparison my prior 2014 Retina iMac reported just over 200W for the approximately same sensor (though alas I never checked what the UPS reported).  In any case it clearly, and as expected, generates significantly more heat than the non-Pro iMacs, as immediately evident by its much improved ability to heat the room. 😄

• The login screen at boot is super sluggish and buggy – it lags behind keyboard input by up to several seconds, and often after you select a user and it transitions to showing just their picture + the password field, it’ll then inexplicably go back to showing all the users’ pictures – but with the password field still visible.  The first ten keystrokes into the password field are almost always ignored & lost.  And sometimes, upon hitting return in the password field, it just obtusely removes the field and goes back to showing just the initial list of users, requiring you to select your user account again and start over.  It’s a plausible hypothesis that whatever is implementing this under the hood is significantly different from on prior Macs.  Perhaps due to integration with the T2 SoC for security & flash access.  And it’s not implemented well.
  
  Whatever the cause, it’s kind of infuriating and baffling, that such an obvious & egregious flaw exists, given this is literally the first thing you experience every time you turn an iMac Pro on.

Relatively briefly, and in no particular order:

• I don’t see why the very slightly different colour scheme, vs the regular iMacs, is such a big deal to some people.  Yes, it’s fairly obviously a different colour.  No, it doesn’t really look any better (nor worse) than the regular iMac’s colour.
• It’s disappointing that it comes with such crappy input devices (the mouse & keyboard at least).  They’re the usual ergonomic & general usability disasters that Apple’s infamous for as of recent years.
  
  Digression:  I also recently got a new MacBook Pro 13″ with Touch Bar for my work machine, which has an even worse keyboard than the iMac Pro, if such a thing is possible.  It’s literally painful to type on.
• According to Intel’s Power Gadget tool, it basically sits at 3.6 GHz permanently.
  
  On the upside, it doesn’t seem to ever drop below that, despite nominally having a 3.0 GHz base frequency, even under the heaviest loads I can throw at it (including heavy, concurrent GPU use).
  
  On the downside, it’s supposed to turbo up to 4.5 GHz, but I’ve never seen the tool report that.  It does get up above 4.0 GHz if you only have one or two threads actually active, but only barely.  Intel’s tool only has 20ms sampling resolution, so it’s quite possible it is bursting to 4.5 GHz in very short stints.  In fairness, the regular iMacs exhibit basically the same behaviour – my 2014 Retina iMac nominally boosted up to 4.4 GHz, but in reality rarely if ever hit that.  Under load, that iMac struggled to reach 4.0 GHz.  Unless the ambient temperature was uncomfortably cold, it’d easily fall down to not much more than 3.0 GHz under any kind of sustained load, and sometimes even further, into the 2.x GHz range.
• The fan is quite audible under any real load, even though I have some loud Thunderbolt disk bays and other things even closer to me than the iMac Pro.  I have no idea what some reviewers have been talking about w.r.t. the fan being “whisper quiet” or outright “inaudible”, because it definitely is not quiet.  It’s not loud, to be sure, but you can’t miss it.
  
  Under basically no load, there is indeed very little fan noise, but that’s both an unrealistic use case and certainly no better than the regular iMacs.
• It does feel dramatically faster than a non-Pro iMac.  I did not expect this.  Certainly I expected significant objective improvements in parallel workloads – mainly batch photo & video editing in my case – but in fact the speed improvement is very noticeable even in single-threaded workloads.  I’m not sure why yet… the internal SSD is faster than the SATA SSD in my prior iMac, but the difference I’m seeing doesn’t seem plausibly explained by that [alone].
  
  I’m also seemingly seeing it perform significantly better under load, w.r.t. user interaction.  Even with all CPU cores completely busy, and the GPU likewise, interactive use remains basically as fast as when it’s idle.  This is a pretty big difference – and very pleasant improvement – over the non-Pro iMacs.  It’s really nice to not have to just walk away while CPU-intensive tasks are running.
• The screen doesn’t immediately appear much different – in terms of colours, contrast, brightness, etc – to my old 2014 Retina iMac.  But it’s very clear which is which, because the iMac Pro has no image retention issues, whereas the 2014 iMac has pretty severe ones.
  
  Though when specifically looking at sRGB vs Display-P3 examples, the difference is quite a bit moreso than I expected, which is of course a pleasant discovery.
• It’s so much better to have a proper, native VESA mount vs the hacks you had to do with prior iMacs.
• iStat Menus can’t read any sensors (except CPU frequency, once Intel’s Power Gadget is installed), though I expect this is going to be fixed fairly soon, in a future version.
• The ports on the back aren’t properly aligned with the case where they protrude, unlike non-Pro iMacs.  Meaning when you plug a cable in, it doesn’t align relatively flatly against the curved case, but rather tilts upwards a bit.  This is a really odd change – though obviously minor and practically insignificant.
• I don’t yet understand why, but Lightroom Classic CC is noticeably snappier.    Particularly in the Develop module as you make edits and then wait for the results to appear on screen.  In some cases it’s an order of magnitude faster – e.g. less than a second instead of 5-10 seconds.  It’s still not consistently fast by any means, but it’s no longer always infuriatingly slow.
  
  I’m unconvinced, regardless, that the laws of physics will allow creation of a computer upon which Adobe’s software won’t run agonisingly slowly.
• Officially it’s quite a bit heavier than the non-Pro iMacs, but I was surprised to find that it’s actually lighter for me… though that’s because with the stand removed – replaced by the VESA mount – it of course under-weighs the regular iMacs with their fixed stands still stuck in them plus a VESA mount adapter.

• Blender – BMW Scene GPU
• DaVinci – Playback/Render 3NR FPS
• Rise of the Tomb Raider – 2560×1440 High

Bare Feats – Rise of Tomb Raider: iMac Pro versus Mac Pro (8-core, Vega64)

• Rise of the Tomb Raider
  • 1920×1080 High
  • 2560×1440 High
  • 3840×2160 High

Bare Feats – iMac Pros versus Mac Pros running X-Plane 11 Flight Simulator (8-core, 10-core, Vega64)

• X-Plane 11
  • c4 test flight ‘1’
  • c4 test flight ‘3’
  • c4 test flight ‘5,4’

Bare Feats – 8-core versus 10-core iMac Pro: The Final Conflict (8-core, 10-core)

• After Effects – BenchTest Render
• Blender – BMW CPU Render
• Blender – Pavillon CPU Render
• Compressor – BruceX to HEVC
• Final Cut Pro X – BruceX 5K Export
• Geekbench – Single-core & Multi-core CPU
• Photoshop – Noise Reduction
• Premiere Pro – Export for Blu-ray
• Premiere Pro – Blur Render

Ars Technica – iMac Pro review: Expensive, hard to upgrade, but holy Jony Ive it’s fast (10-core, Vega64)

• Cinebench R15 CPU
• Geekbench 4 CPU Single-core & Multi-core
  • Native & in Windows 10 running in Parallels
• Geekbench 4 GPU Compute (Metal & OpenCL)
• GFXBench Metal Offscreen (1080p) – T-Rex, Manhattan, & Manhattan 3.1
• Quickbench Storage Test, Extended Test Average
• World of Warcraft: Legion FPS
• Xcode WordPress iOS app compile

Craig A. Hunter – iMac Pro 18-core Follow Up Review (18-core, 10-core)

• AVX-512 Vector Add Benchmark Parallel Performance
• LINPACK Shared Memory Benchmark Using Intel MKL
• USM3D NACA 0012 Airfoil Parallel Performance

9to5Mac – First 18-Core iMac benchmarks showcase obvious multi-core benefits (8-core, 10-core, 18-core)

• AJA System Test (SSD Performance)
• Final Cut Pro X 4K ProRes Export from 8K RED RAW (12:1)
• Geekbench 4

Bare Feats – What if the iMac Pro had THREE Vega GPUs? (8-core, Vega64)

• LuxMark GPU LuxBall
• LuxMark GPU Hotel
• Blender Pavillon Barcelona
• DaVinci Resolve Play/Render 3NR nodes

AppleInsider – iMac Pro vs 2013 Mac Pro (Part 4) – 3D rendering and thermals (8-core, Vega56)

• After Effects CC ProRes 422 Render
• Blender BMW CPU
• Blender BMW GPU
• Maya 2018 Model Village Render

AppleInsider – iMac Pro vs 2013 Mac Pro (Part 3) – video editing (8-core, Vega56)

• Final Cut Pro X BruceX
• Final Cut Pro X 1080p Render & Encode
• Final Cut Pro X 4K H.265 Encode
• Final Cut Pro X 4K Render
• Final Cut Pro X 4K Render & H.264 Encode
• Final Cut Pro X 4x4K Render & H.264 Encode
• Final Cut Pro X 4K Stabilisation
• Final Cut Pro X 8K Render & ProRes Encode
• Premiere Pro 1080p Render & H.264 Encode
• Premiere Pro 4K H.265 Encode
• Premiere Pro 4K Render & H.264 Encode
• Premiere Pro 4x4K Render & H.264 Encode
• Premiere Pro 4K Stabilisation
• Premiere Pro 8K Render & H.265 Encode

DPReview – Speed Test: iMac Pro vs Alienware PC, Mac Pro and MacBook Pro (8-core, Vega64)

• After Effects RAM Preview
• Photoshop Radial Filter
• Premiere Pro 4K Render

AppleInsider – Apple’s iMac Pro vs 2013 Mac Pro (Part 2) – photo editing comparison (8-core, Vega56)

• Lightroom Classic CC
  • Convert 50 RAWs to DNGs
  • Export 50 JPEGs
  • Generate 50 1:1 Previews
  • Import 52 42MP RAWs
• Photoshop CC
  • 9 Shot HDR Merge
  • Noise Reduction
  • Open 9 RAWs

Bare Feats – iMac Pro Has A Thunderbolt 3 Storage Surprise For You (8-core)

• AJA System Test – 16G Sequential Read
• AJA System Test – 16G Sequential Write

Macworld – iMac Pro review: Mac Pro power in the shape of an iMac (8-core, Vega56)

• Forecast MP3 Encode
• Geekbench Compute GPU
• Geekbench Single-core & Multi-core CPU
• Handbrake 1080p H.264 Encode
• iZotope De-Echo
• iZotope Spectral Denoise B
• Logic Bounce
• Unigine Valley (High)

Cinema5D – iMac Pro Review – Is It Worth the Money? (10-core, Vega64)

• Final Cut Pro X H.264 HD 25p Export
• Final Cut Pro X ProRes 422 4K 25p Export
• REDCINE-X PRO 6K ProRes 4444 Export

AppleInsider – Apple’s iMac Pro vs 2013 Mac Pro with benchmarks and specs (8-core, Vega56)

• Cinebench R15 CPU
• Geekbench 4 OpenCL
• Geekbench 4 Single-core & Multi-core CPU
• Unigine Heaven

Bare Feats – What if the iMac Pro had TWO Vega GPUs? (8-core, Vega64)

• Blender – BMW CPU Scene
• DaVinci Resolve – Play/Render Noise
• DaVinci Resolve – Play 5K RED Clip
• LuxMark – GPU LuxBall
• LuxMark – GPU Hotel

DigitalArts – Apple iMac Pro review – this superbly designed workstation is most powerful Mac ever (10-core, Vega64)

• Cinebench R15 Render & Real-time 3D
• After Effects CC 2018 Render

Bare Feats – 8-core and 10-core iMac Pros Running Pro Apps (Part Two) (8-core & 10-core, Vega64)

• Motion – Render RAM Preview
• Compressor – BruceX HEVC 10-bit Transcode
• Logic Pro X – Maximum Tracks
• Blender – Render BMW Scene CPU-only & GPU-only
• DaVinci Resolve – Transcode 5K RED clip to ProRes 4444 XQ

Mac Performance Guide – 2017 iMac Pro (8-core & 10-core, Vega56 & Vega64)

• Scalability with CPU-Intensive, Memory-Intensive and Mixed Workload
  • diglloydTools MemoryTester: Scalability
    • CPU / No Mem
    • SHA1 Hash
    • Memory Intensive
• CPU Cores, Clock Speed, Turbo Boost
• Power Usage (Watts)
• Flash Drive (SSD)
  • disktester Speed vs Transfer Size
  • disktester 8 GB Sequential
• APFS vs HFS SSD Speed
• Grep (Search)
• Integrity Checker Verify
• diglloyd Photoshop Benchmarks
  • Photoshop CC 2018 v19.0
• Photoshop Filters
  • Photoshop CC 2018 v19.0
• RAW to JPEG
  • Photoshop CC 2018 v19.0
• Real World Photoshop: Make Multi-Res Image Series
  • Photoshop CC 2018 v19.0
• Lightroom Import and Export
  • Export 522 JPEGs
  • Import 522 RAWs with 1:1 Previews
• CaptureONE Pro
  • Export 352 JPEGs
  • Import 352 RAWs
• Iridient Developer
  • Iridient Developer 3.2.1, Reveal v4 Detail+
• Zerene Stacker
  • 20-frame Focus Stack DMAP & PMAX
• Helicon Focus (and subsequent follow-up with Helicon Focus 7.0.0)
• XCode Build C++ Project

DigitalFilms – Putting Apple’s iMac Pro Through the Paces (10-core, Vega64)

• Adobe Media Encoder 1080p ProRes to 4K H.264 Transcode
• Adobe Media Encoder OpenCL ProRes Render
• After Effects ProRes Render
• Compressor 1080p ProRes to 4K H.264 Transcode
• Final Cut Pro X BruceX Render & Export
• Final Cut Pro X Playback
• Final Cut Pro X Render & ProRes Export
• Premiere Pro Playback w/ Single & Multi-layer sequences

Bare Feats – Low End iMac Pro Running Pro Apps (8-core & 10-core, Vega64)

• After Effects CC Render
• Compressor Export
• Final Cut Pro X Export
• Lightroom Classic CC JPEG Export
• Photoshop CC Noise Reduction
• Premier Pro CC Export

Bare Feats – Low End iMac Pro Running Games versus Other Macs (8-core Vega64)

• DIRT Rally 2560×1440 Average FPS
• Tomb Raider 2560×1440 High FPS
• Total War: Warhammer 2560×1440 High FPS
• Tomb Raider 2560×1440 High FPS

Bare Feats – Low End iMac Pro versus two Mac Pros and one iMac 5K (8-core & 10-core, Vega64)

• DaVinci Resolve 14 Noise Reduction
• Cinebench Multi-Core CPU
• Geekbench Metal Single GPU
• Geekbench Multi-Core CPU
• Geekbench OpenCL Single GPU
• LuxMark GPU LuxBall
• LuxMark Multi-Core CPU

Bare Feats – iMac Pro with Pro Vega 56 GPU
versus optional Pro Vega 64 (8-core, Vega56 & Vega64)

• Cinebench OpenGL
• Compressor Transcode (BruceX to Apple 4K)
• Final Cut Pro X Export (BruceX to ProRes 4444 XQ)
• Geekbench 4 Metal GPU Compute
• Geekbench 4 OpenCL GPU Compute

Bare Feats – iMac Pro PCIe-based Flash Storage: How Fast Versus Other Macs?

• AJA System Test 15G Sequential Reads & Writes

fcp.co – Testing the Apple Pro Video Apps on the New iMac Pro (10-core, Vega64)

• Compressor 4.4.0 H.264 & MXF Export (from ProRes 422)
• Final Cut Pro X 10.4.0 4K Export to ProRes 422, H.264, & MXF
• Final Cut Pro X 10.4.0 BruceX XML Test
• Final Cut Pro X 10.4.0 Import Clips
• Final Cut Pro X 10.4.0 Multicam Playback & Render
• Final Cut Pro X 10.4.0 ‘Real World’ H.264 Export
• Final Cut Pro X 10.4.0 Render Optimized Media
• Final Cut Pro X 10.4.0 Render Proxy Media
• Final Cut Pro X 10.4.0 Timeline Render
• Motion 5.4.0 Emitter Export to H.264 & ProRes 4444 XQ
• Motion 5.4.0 Graphic Heavy Commercial Export to H.264 & ProRes 4444 XQ

AppleInsider – Putting the iMac Pro thermals to the test (8-core, Vega56)

• Cinebench R15 Multi-Core CPU
• Wondershare Video Converter Ultimate Transcode 4K HEVC to Apple ProRes
• Unigine Heaven

Six Colors – The iMac Pro has landed (8-core, Vega56)

• ffmpeg WAV Conversion
• Handbrake Transcode 1080p to lower resolution
• iZotope RX 6 Spectral Denoise
• sidetrack Audio Sync

AppleInsider – Review: Apple’s powerhouse iMac Pro wows with stellar performance and design (8-core, Vega56)

• After Effects 2018 EQUILOUD Benchmark Sequence (inc. Export to ProRes 422)
• Cinebench R15 Single-Core & Multi-Core CPU
• DaVinci Resolve 14.2 Canon Cinema RAW Lite Playback & Export
• DaVinci Resolve 14.2 H.264 1080p & 4K Render & Export
• DaVinci Resolve 14.2 Motion Stabilization
• DaVinci Resolve 14.2 Red RAW 4.5K & 8K Playback, Render, & Export
• Final Cut Pro X 10.4 4K Motion Stabilization
• Final Cut Pro X 10.4 BruceX ProRes 422 Export
• Final Cut Pro X 10.4 Canon Cinema RAW Lite Playback & Export
• Final Cut Pro X 10.4 H.264 1080p & 4K Export
• Final Cut Pro X 10.4 Intel Quick Sync H.264 Encode
• Final Cut Pro X 10.4 Red RAW 4.5K & 8K Playback, Render, & Export
• Geekbench 4 Single-Core & Multi-Core
• Geekbench 4 OpenCL GPU Compute
• Geekbench 4 Metal GPU Compute
• Lightroom Classic CC DNG Conversion
• Lightroom Classic CC Generate 1:1 Previews
• Lightroom Classic CC JPEG Export
• Lightroom Classic CC RAW Import
• Maya 2018 “Model Village” 640×480 Render to ProRes 422
• Photoshop HDR
• Photoshop Noise Reduction
• Premier Pro 2018 4K Motion Stabilization
• Premier Pro 2018 H.264 1080p & 4K Render & Export
• Premier Pro 2018 Red RAW 4.5K & 8K Playback, Render, & Export
• Wondershare Video Converter Ultimate Transcode 4K HEVC to Apple ProRes
• Unigine Heaven Extreme

Craig A. Hunter – 2017 iMac Pro Review (10-core, Vega64)

• NASA TetrUSS CFD (Computational Fluid Dynamics) w/ NACA 0012 airfoil CRM transport aircraft
  • VGRID Surface Mesh Generation (237,660 Triangles) Single-core
  • USM3D Parallel Performance
  • USM3D Parallel Scaling
• Objective-C, C, & Swift Compilation w/ Xcode
• Vectorization Speedup – Simple Add

Lomesi – With the iMac Pro, Apple promised so lightning rates: Apple T2 chip (10-core)

• AJA System Test 64G Sequential Reads & Writes
• Black Magic Disk Speed Test

Sander Zwartepoorte – Disappointing iMac Pro performance with Motion 5… (8-core, Vega56)

• Final Cut Pro X Export
• Motion Playback
• Premiere Export

1. ≥ 50 image buffer.  In 14-bit RAW.
   
   😂 Nailed it.  The D500 never misses a shutter actuation.  It’s beautiful.  I’m pretty sure it’s ruined all lesser cameras for me.  I can’t stand anything that doesn’t take the photo when I press the shutter, nor anything which fails to keep taking photos until I decide to let go.
2. ≥ 10 FPS.  I’ll even accept complete viewfinder blackout if it means getting beyond 10 FPS.  Sony actually have a new 28 MP sensor that is capable of 18 FPS read-out.  I’ll take it.
   
   🙂 10 FPS it is.  Viewfinder blackout isn’t too bad, but isn’t great either.  18 FPS would have been awesome, and Sony have since demonstrated that you can get 24 FPS in a full frame sensor, so Nikon are still a bit behind, but admittedly 10 FPS does cover my needs most of the time.
3. UHS-II support.  And if I can actually find a card that can really do 300 MB/s, I expect my camera to write at that speed.  None of this half-arsed 60%ish crap that all the UHS-I Nikons have.
   
   😁 XQD and UHS-II support.  With good cards write speeds are indeed very fast.  I can’t complain here.
4. Lower noise.  Across the range, not just at high ISO.  ISO 100 isn’t as clean as I’d like, and I’d really love to be able to use ISO 3200 or above in typical use.  Bonus points for pushing the native ISO lower (50’d be nice, at least).
   
   😕 Not so much.  ISO 100 definitely isn’t cleaner than any other recent Nikon DX camera – even the D5x00 line, let-alone the D7x00.  And high ISOs to my eyes simply aren’t any better – in noise, dynamic range, or colour – either.
5. More, smaller autofocus points, that fill the frame.  Just give me a few hundred in an even grid.  All cross-type, all f/2-optimised at least, and all good down to f8 and -4EV at least.  And better autofocus generally.
   
   🙂 There are indeed a lot more points, with slightly wider coverage, and AF performance is marginally better overall on all those points.  Plus f/8 to -4EV support on quite a few.  So mostly positive.  However, they’re no better at wide apertures than the predecessors, sadly.  Continue to expect frequent focus failures at f/2 or wider apertures.  Possibly this just can’t be fixed in an SLR (as opposed to a mirrorless design).
6. On-sensor phase detection autofocus.  I’d actually be rather interested in a mirrorless DX F-mount body, but even with a traditional DSLR, I want usable autofocus when shooting video.  I’ll make it easier for you, though – I don’t need hundreds, or the high light sensitivity of the ‘viewfinder’ PDAF points.  Just give me some, at least.
   
   😩 Nada.  Zilch.  Zip.  Fail.
7. Let me adjust shooting settings in video mode (aperture, for example).  While recording, too.
   
   😐 Sort of.  I still somehow, sometimes, end up in scenarios where it won’t do what it’s told in video mode.  Plus it still insists on changing settings somewhat arbitrarily when I switch between video & stills mode, which is a frequent and frustrating source of exposure errors and lost moments.
8. ≥ 4K video @ 60 FPS.  At serious bitrates – at least 200 Mbps.  Preferably with a H.265 encoder option.
   
   😕 4K yes, but only up to 30 FPS, and not at particularly high bitrates.  And still no H.265.  It’s hard to be too critical, because overall video quality is massively better than the 1080p on all its predecessors, but it’s still no match for notable video-oriented cameras (e.g. Panasonic’s GH4 & GH5, or many recent Sonys).
9. And/or, full-sensor read-out video.  I’d accept being stuck with 1080p60 if it were at least from the full sensor.  But it still has to have higher bitrates than today’s mediocre offerings.
   
   🙁 Nope – pretty severe crop in 4K mode.  This has been challenging in some of the video productions I’ve filmed, where it’s simply impossible to get rectilinear wide-angle video out of the D500.  Even using an 8mm diagonal fish-eye lens, and its distortions aside, doesn’t really give you the ultra-wide experience.
10. Put the top-plate LCD back the way it was, on the D7100.  What the hell, D7200?  What the hell?
    
    🙃 I forget what my complaint was with the D7200 top plate LCD… but the D500’s top plate LCD works nicely, and I have no complaints about it.  So success, either way.
11. Quieter shutter.  Something more like the D810, or better, preferably.
    
    😔 Nope.  Still a loud clickity-clack.  On the upside, it comes across slightly moreso ‘impressive’ than merely annoying, at 10 FPS.
12. GPS.
    
    😡 WTF Nikon.  WTF.

    No, SnapBridge doesn’t count.  It’s #%!@ing useless.  It records the wrong coordinates almost all the time.  It’s ridiculously laggy – associating GPS locations from hours prior with some photos.  Absolutely a disaster.

13. Deeper, wider hand grip.  My fingers are in fact more than an inch long.  How ’bout that.
    
    🙂 Yep, the grip is improved, along the same trendline as all Nikon’s more recent DSLR.  Though it’s not actually wider – narrower, if anything – it is significantly deeper, and that works too.
14. Moar pixels!  But honestly, only if it’s amazingly more (≥ 40 MP) or otherwise at no noticeable cost w.r.t. image quality, or performance.
    
    🙁 Alas no.  21 MP isn’t too bad, but it is very slightly noticeably less real-world resolution than the myriad 24 MP Nikon DX DSLRs that preceded it.  And it really pales in comparison to the new D850, which has shown you can have quite a bit more of your cake & eat it too.
15. Real weather-sealing.  Pentax are kicking your arse here.  I should not have to bat an eyelid at rain.  I should be able to test Sigma’s 150-600 S and have it fail from moisture or dust damage before the camera body.
    
    🤔 Maybe.  I guess I’m not willing to experiment too rigorously with this.  It’s certainly claimed to be significantly more weather-resistant.
16. Lighter.  Always lighter.
    
    😒 Sadly no.  For the most part the extra weight doesn’t bother me, but it does add up, and it does hamper the user experience a little bit.
17. Wider, more recessed viewfinder cup.  I shouldn’t have to force my face through the camera in order to see the whole frame, nor buy third-party cups to actually block out glare.
    
    😐 Somewhat.  The viewfinder is indeed very nice & big by contemporary standards – even full-frame contemporaries – and that does make a big difference, which must be given due appreciation.  But, the eye-cup itself is still basically non-existent, so glare and light leakage remain ever as problematic as before, and really demand not-entirely-cheap accessories to fix.
18. High-speed video options (> 60 FPS).  But only if it’s at usable resolutions – none of this “400 FPS but only at a tiny resolution” crap like the Nikon Vn series.  Even little tiny GoPros can do this.  Seriously, you should be ashamed of yourselves.
    
    😞 Apparently high frame rates in general – even just 60 FPS, let-alone anything you’d really consider “high” – weren’t in their design goals.  Not a big deal compared to most of the wishlist items here, but still a bit disappointing not to have.
19. Magnify the viewfinder image in 1.3x mode.  I really want to like and use 1.3x mode, but it feels so pointless today.
    
    🙁 Still nothing here.  And the extra 1.3x crop doesn’t even boost FPS like it did on the D7x00 line, and buffer sizes are so gloriously large that you needn’t shrink your files on their account, so there’s very little point to it.  If you’re worried about SD / XQD card space, or disk space, I wonder if the D500 is the right tier for you anyway (you can get a lot of hard drive space – like, 50+ TB, for the price of the D500 body alone).
20. Dedicated AF-ON button.  Sometimes I actually want to use the AE-L button for its labelled purpose.  Just give me two damn buttons already.
    
    🤣 Not just this, but they actually made a whole dedicated AF joystick.  Above & beyond on this one.  The joystick is a tad fiddly w.r.t. pushing it for autofocus engagement vs swiping it for point movement, but still, I like it.

    And, they let you map different autofocus modes to different buttons, so you can have something like four AF-ON buttons, essentially, each one operating completely different autofocus modes. I never conceived of it, and might not have even though it that interesting if you’d merely described it to me, but after using it, it’s awesome.

21. Longer body.  I have actual human hands, not baby monkey ones.  I want a camera that actually fits in them, without my bottom two fingers falling off the bottom.  (without spending $7,000 on a D4s)
    
    ☺️ Yep.  I have no issues with my pinky falling off the bottom, even without a portrait grip attached – which is perfect, because the Dx line’s integrated portrait grip adds too much hand grip length, and heft.
22. Wifi.  But only if you actually provide a remote control app that’s full-featured.  Don’t even bother including your current wifi system.  I already had to buy a CamRanger because of your half-arsedness.
    
    😤 Unsurprisingly continued disappointment here.  Nikon appear bizarrely incapable of implementing connectivity intelligently, let-alone well.
23. Provide an AC adapter for what it actually costs – i.e. $5.  $120?!  Are you insane?  Here’s an idea:  just integrate USB 3 as a USB-C connector (or better yet, Thunderbolt 3).  Single-port AC power, clean video output, and tethering.  And in that case, give me at least two such ports, so I can tether and AC power simultaneously.
    
    😠 Still no convergence on a superior power & connectivity solution.  Yes, there’s USB 3, but that’s really not very impressive nor useful to begin with in its current incarnation.  Still no sensibly priced power tethering option.  Sigh.
24. Touch-screen.  Surprised to see it so far down the list?  Meh.  All I really want is double-tap to zoom and touch-to-focus.
    
    😃 I’m going to give Nikon extra due on this one, because while yes they did a touch screen, and the implementation is decent (though the inability to use touch to change settings etc is a dumb omission, and stark in contrast to their much cheaper DSLRs which do support that now).

    But what really pleases me is actually the resolution & image quality generally of the screen.  I evidently didn’t appreciate how much this matters – given I left it off my wishlist entirely – but in hindsight I really do like the upgraded rear LCD.  Kudos, Nikon!

And in hindsight there’s a few items that should have been on my wishlist, but weren’t:

1. Less mirror slap.  The D500 has a pretty hefty thwack that you can easily feel shocking into your hand, and it produces serious sensor-motion blur at even moderate, let-alone genuinely low, shutter speeds.  It’s actually a far greater disabler in low-light or narrow-aperture photography than the image quality off the sensor itself.
2. Electronic front & rear shutters.  Like the D850 now has.  Ideally this wouldn’t compromise shooting otherwise – as sadly it does with the D850 – but even with the D850’s implementation, it’d still be exceedingly useful  in things like time lapses, for combating the pretty horrendous mirror slap the D500 has.
3. More accurate and consistent autofocus.  I talked about autofocus points, and some of the specs that imply accuracy & consistency, but I should have just said:  give me an autofocus system that actually bloody works reliably.   The D500 continues the Nikon (and in fairness, DSLR-generally) tradition of troublesome autofocus.  From systematic focus errors in bodies and body+lens combinations, to limited abilities to even manually correct for that in the camera (really, a single adjustment setting for the entire lens?!).  The new “autotune” feature for autofocus adjustment is a nice notion, and it’s certainly better than nothing, but in practice it isn’t that reliable itself, and it only really scratches the surface of the autofocus issues.

So, I spent kind of a ridiculous amount of time looking for and at various options. What follows is my overview of the options I found, and their major pros and cons. It’s listed roughly in descending order of preference, for my use-case (for now I have chosen Pixieset, and it’s worked pretty well for my first gallery).

Pixieset

✅ Attractive gallery presets and display.
One of the few, if not only, sites in this list which renders photos sharply.

✅ Decent client proofing workflow.
Clients can have password-protected access which lets them do a few extra things, like view otherwise unpublished photos (e.g. drafts) and mark them as private (no longer visible to guests).

Additionally, anyone – whether with the client password or through regular guest access – can create a favourites list tied to an arbitrary string (ostensibly their email address, but no validation is performed), which can be seen by the photographer in the gallery’s dashboard (and converted to a CSV list of filenames, for example). There’s also a few handy additional features like the ability to create a new ‘Set’ (album within the gallery) based on their list of favourites. Unfortunately there’s currently no way to sync those new sets back to Lightroom, short of manually finding & arranging the photos in Lightroom to match.

Furthermore, there is a separate, optional, password for viewing the gallery at all, even as a ‘guest’. Thus you can have a password-protected gallery that also has a separate, client password.

✅ Galleries & photos load very quickly.

ShootProof

✅ Attractive & performant gallery templates.

✅ Decent client proofing workflow.
Very similar to Pixieset – you can assign a particular client (identified by email address & a pin number) to a gallery, and they can have unique privileges, protected by a pin code, like the ability to hide, label (tag, using a list of tags pre-defined by the photographer), and favourite (if you otherwise disable favouriting) photos.

Anyone – whether with the pin code or through regular guest access – can create a favourites list tied to an arbitrary string (ostensibly their email address, but no validation is performed), which can be seen by the photographer in the gallery’s dashboard.

Like with Pixieset, this allows you to have a regular guest password as well as a pin-code for privileged (client) access.

✅ Nice “filmstrip” viewer.
When a viewer clicks on any photo to view it larger, in addition to the larger photo being displayed, a “filmstrip” appears at the bottom which allows for easier navigation amongst similar photos. The film strip also shows badges for favourites.

⛔️ Client experience is a bit buggy.
In addition to the share email they’re sent not including the pin code, unless you manually enter it each time, it’s somewhat random as to if or when they’ll actually get a chance to enter it, and unlock their special privileges. In my testing I was only able to browse the gallery initially, and then at a random point it interrupted and asked for the pin.

⛔️ Photos tend to look a bit soft when displayed, as if they’re being enlarged from scaled-down copies.

SmugMug

⛔️ No free plan.
They’re well-reputed and look like they have a lot of good features, but I don’t make money from my photography, so I try to keep expenses low.

Not that they’re expensive by any means, but there are good alternatives which are free (for my levels of use).

Redcart

⛔️ No free plan.

PhotoShelter

⛔️ No free plan.
And their cheapest plan, at $8 per month, doesn’t include client proofing support. Their first tier that does is $25 a month – way higher than their competitors.

StickyAlbums

⛔️ No free plan.
And their cheapest monthly plan is $29, which is way higher than their competitors’ entry-level rates (even ignoring those that offer ‘free’ as their first tier).

Zenfolio

⛔️ No free plan.

⛔️ Buggy galleries.
Despite not being free, they were one of the first on my list (before I’d explored Pixieset or ShootProof, for example), so at that point I was presuming I’d have to pay something. So I signed up for a trial account, and set up a test gallery.

And that’s how I discovered that their web page layout is stupidly broken – the ‘Add To Favorites’ button, crucial to my intended proofing workflow, is obscured by the copyright footer, and rendered unclickable. Ugh… what a stupid bug.

Instaproofs

✅ Attractive pricing.

⛔️ Really ugly galleries.

⛔️ Requires an arbitrary string from all visitors before they can see anything (ostensibly their email address, but no validation is performed).

⛔️ Very much targeted at selling prints.
There can still have favourites lists and a few other things, but the entire interface is very clearly intended to funnel you into a shopping cart. It’s very inappropriate if you’re just sharing a portfolio, but still a bit crass even if you’re doing print-centric client work like weddings or family shoots.

Instaproof only get their income from print commissions, so it’s unsurprising that they try to hard sell at every corner. Unfortunately they’ve done it distastefully and fatally undermined the entire experience.

PASS

✅ Attractive pricing (particularly re. free for any and all galleries of fewer than 100 photos).

⛔️ Does not work.
I was unable to view any photos that I’d uploaded into a gallery – whether going through the ‘normal’ link or a ‘VIP’ invite, it’d prompt for the gallery password (if set), then demand an account be created, but even once that was done, it wouldn’t actually show any photos.

The login prompt says that Facebook is the preferred method, blah blah blah, but doesn’t actually provide any way to log in via Facebook.

Viewing in Safari on a Mac it was showing what very much seemed to be a mobile interface – everything squished into a ~4″ screen space in the top left of the browser window.

⛔️ Limited templates & control over appearance generally.

⛔️ Requires use of a desktop Flash app.
Yep, both Flash and only works after you download and install it.

Furthermore, it doesn’t follow standard user interface conventions, both visually and w.r.t. interactivity – e.g. ‘Select All’ simply doesn’t work (even though there’s a menu item for it).

⛔️ No Lightroom plug-in.

⛔️ Uploads are slow.

⛔️ Doesn’t appear to have any client proofing capabilities.

⛔️ Does not seem to allow you to close an account once created.