Mac OS Big Sur logbook (2) - Control Centre

August 19, 2020
by Riccardo Mori
Software

Now that I’ve shared my perplexities regarding the menu bar, let’s just… stay with the menu bar a bit more. One of the new features of Big Sur that was touted in the preview at the WWDC 2020 is Control Centre. Clearly taken from iOS, on Mac OS it serves the very same purpose: to provide a series of shortcuts to the most used settings, all in one convenient place. Here it is in its default configuration on my MacBook Pro:

Control centre

First impression: why not? I don’t particularly dislike it, and it kind of makes sense. Those are all useful controls to have handy.

From a usability standpoint, here’s what I’ve noticed. On previous versions of Mac OS, not having something like Control Centre available, users would populate the menu bar with the controls they need and use most. Let’s just take three examples: Bluetooth, Wi-Fi, and Volume. These three menu extras provide both access to the respective settings and instant information on their current state. You can immediately see whether Bluetooth is on or off. You can see whether Wi-Fi is turned on or off, and see whether the Mac is connected to a wireless network and the intensity of the signal. And you can have an approximate idea of the system volume level by looking at the Volume icon.

When you click on these controls and bring down their respective menus, you get additional information and additional control:

  • Bluetooth: you can turn it off/on immediately; you can select a previously paired device and connect to it; you can open Bluetooth preferences.
  • Wi-Fi: you can turn Wi-Fi off/on immediately, connect to another network with a click on its name, plus access other options like create a network or open Network preferences.
  • Volume/Sound: you can adjust the volume, change the output device, access the Sound preference pane.

Bluetooth, Wi-Fi, Volume menus (High Sierra)
Bluetooth, Wi-Fi, and Volume menus in previous Mac OS versions (High Sierra pictured here)

I know this is pretty much self-evident, but bear with me. If you combine the information provided by these three menu bar icons, with the level of control their respective menus give you, you end up with a pretty efficient way of dealing with their status and settings. It’s all quite immediate and a couple of clicks away.

Bluetooth, Wi-Fi, Volume menus (Big Sur)
Bluetooth, Wi-Fi, and Volume menus in Mac OS Big Sur (beta)

Now in Big Sur, their function hasn’t changed. They behave the same way. Their look has been refreshed, but they work exactly like before. The only difference is that, due to the UI redesign, now it takes you one click more to turn e.g. Bluetooth or Wi-Fi off and on. Before, you clicked on their icon and just moved the mouse on the Turn Bluetooth Off/On or Turn Wi-Fi Off/On menu command. Now you have to click on their icon and then click on their on/off switch. I know this is incredibly subtle and the delay in the corresponding action is only a fraction of a second higher, but still, it feels unnecessary; it feels like something clearly designed for touch interaction that was simply copied and pasted on a desktop paradigm driven by a mouse or trackpad.

There’s another interesting detail to note, in my opinion. Given the excessive spacing introduced between menu bar elements (both between icons and — something I failed to point out in the previous logbook entry — menu names), what you’re tempted to do is remove the separate Bluetooth, Wi-Fi, and Volume controls, and just use Control Centre. And this is both a practical and impractical solution. Practical because, well, you have multiple controls all in one place. Impractical because, by removing the single controls from the menu bar, you lose the ability to know about their state at all times. To see whether Bluetooth or Wi-Fi are turned on, you have to click on the Control Centre icon. To access their additional features you have to click on the annoyingly tiny light-grey arrow near each control (by the way, the arrow appears on mouseover, it’s not always visible).

And here is where things slow down more noticeably and get a bit more awkward. Before Big Sur, if I just wanted to switch networks, I would pull down the Wi-Fi menu from the Wi-Fi control on the menu bar, and select the other network. One click, one scroll of the menu, and selection. In Big Sur — provided you only want to use Control Centre in the menu bar — the same operation takes three clicks, one scroll of the menu, and finally the selection:

Control centre hover

  • You first click on the Control Centre icon;
  • You carefully position the mouse to make the grey arrow appear (otherwise your click will just turn Wi-Fi off);
  • A second click, and you enter Wi-Fi settings;
  • If the network you want to switch to is among the Preferred Networks, then you just select it here;
  • If not, you have to click a third time on Other Networks and finally scroll down the list and select the network you want.

Yes, you get a prettier interface, but that’s pretty much what you get. For now, Control Centre on the Mac feels simultaneously handy and awkward. You have faster access to multiple controls, but slower access to each control’s finer settings.

Previous logbook entries

Mac OS Big Sur logbook (1) - Installation, the menu bar, first impressions

August 15, 2020
by Riccardo Mori
Software

Before proceeding, a disclaimer

Section 5 of the Apple Beta Software Program Agreement (“Definition of Confidential Information”) states:

You agree that the Pre-Release Software and any information concerning the Pre-Release Software (including its nature and existence, features, functionality, and screen shots), the Seeding Tools, and any other information disclosed by Apple to you in connection with the Beta Program will be considered and referred to in this Agreement as “Confidential Information.” Information that otherwise would be deemed Confidential Information but (a) is generally and legitimately available to the public through no fault or breach of yours, (b) is generally made available to the public by Apple, (c) is independently developed by you without the use of any Confidential Information, (d) was rightfully obtained from a third party who had the right to transfer or disclose it to you without limitation, or (e) any third party software and/or documentation provided to you by Apple and accompanied by licensing terms that do not impose confidentiality obligations on the use or disclosure of such software and/or documentation will not be considered Confidential Information under this Agreement. 

Everything I’ll talk about in my Big Sur logbook should not be considered confidential information according to points (a) and (b) specifically. In other words, I will do my best to limit my observations and the subjects discussed here to what Apple has made available to the public during the WWDC 2020 and via the macOS Big Sur Preview page on the company’s website.

Big Sur public beta: download and installation

The first thing to do when you enroll your Mac in the Apple Beta Software Program is to download the Mac OS Public Beta Access Utility, which is essentially a tool that enables Software Update to detect the Big Sur beta releases. When you start installing this tool, it reminds you to perform a backup before installing beta software. It’s a nice touch. It would be even nicer if Time Machine backups worked reliably under Catalina, but that’s a story for another time.

No Time Machine detected

Another tool called Feedback Assistant is also installed. You use it to send feedback directly to Apple as you evaluate the beta software.

Once everything is set up, Software Update informs you that there’s a new Mac OS version available. And Big Sur is big — on my MacBook Pro the installer is 12.30 GB. I’m hopeful that the download won’t take long: my home wireless network is working at full speed, and Apple servers are usually fast. Unfortunately the download is annoyingly slow, and it takes between 3 hours and a half to 4 hours to complete.

The installation process, on the other hand, isn’t much different from a regular new release of Mac OS, and it takes about 38 minutes from start to finish. As the installer itself warns, the Mac will be restarted a few times. I also notice that the MacBook Pro becomes rather hot at a certain point, and fans appears to run at full speed for a little while, but then things return to normal. 

The MacBook Pro restarts for the last time, and I’m at the usual login screen. Everything went well.

That menu bar: uh-oh

I already noticed it when Big Sur was previewed during the WWDC 2020, and on the Preview page on Apple’s site, but — at least for now — the menu bar in Big Sur is a bit of a mess.

On Twitter I remarked the most obvious detail: the increased spacing of the various menu bar icons, but the menu bar’s transparency is also an issue.

Let’s start with icon spacing. On bigger displays, like we saw in the WWDC demos, it may not be a problem, but the situation on my retina MacBook Pro’s 13-inch display is jarring:

Big Sur menu bar
(If this and the following images of the menu bar look too small on your computer, try right-clicking them and selecting ‘Open Image in New Tab’ or a similar option in your Web browser.)

This is how it looks in the Finder, which has only a few and short menu names (in English, at least). Also consider that I’m only using two third-party menu bar additions here: Dropbox (1) and iStat Menus (2). The rest of the icons (3) are from the system.

Menu bar with legend

Compare and contrast with the menu bar of my 11-inch MacBook Air running High Sierra:

Menu bar 11-inch MacBook Air

iStat Menus is a very useful tool, and can display much more information on the menu bar than the particular configuration I’m using. But even if you’re not using a utility that takes up much space with icons in your menu bar, you can see how the menu bar can get crowded by third-party additions very quickly. If you’re even a minimally tech-savvy Mac user, your menu bar is probably already crowded. Cloud services like Dropbox, Box, Microsoft OneDrive, etc. put an icon up there. TextExpander puts an icon up there. Any utility that offers quick access to its options puts an icon in the menu bar. Plus there are even utilities that run in the background for which the menu bar icon is the only way to access them.

There are third-party utilities, such as Bartender, that help keep the menu bar clean and organised, but menu bar icons mainly serve two purposes: one, they’re shortcuts to the corresponding applications; two, they are status indicators. Their position is strategic, and users can check if something is happening at a glance. What’s the CPU temperature? How much battery charge is left? Is Bluetooth on? Is the Mac connected to a wireless network and does it have connection? Is Dropbox updating? And so forth. A utility that hides menu bar icons (even with Bartender’s useful feature that shows menu bar icons in the menu bar when they update) takes away a lot of their immediacy. They’re supposed to be glanceable and easy to reach, otherwise we could just sweep all of them away under a rug — or a Control Centre.

With such excessive menu bar icon spacing, Big Sur exacerbates the problem and makes menu bar icons more cumbersome and more in-the-way, even in a default setup. True, you can remove or hide some of these (Siri can be removed, and you could also hide Wi-Fi, Bluetooth, Volume and Battery, since you can access them in the new Control Centre), but really, this kind of workaround would be understandable on a phone, where screen estate is more limited; and again, you just end up adding unnecessary friction and reducing immediacy. 

Some have suggested that the increased spacing is because this interface is being already optimised for possible future touchscreen Macs, and it may be the case, but unless the majority of future Macs are touch-enabled (also: consider all past Mac models that can run Big Sur), a touch-friendly menu bar UI should be considered the exception, not the rule. That’s why I think Apple should give the user the option to adjust the spacing, much in the same way users can adjust the grid spacing of icons on the Desktop and in Finder windows.

Menu bar transparency

I may be old-school, but if I were an operating system UI designer, one of my core principles would be, You don’t mess with the menu bar. I believe that there are essential places in a user interface that must remain as clear and utilitarian as possible. The menu bar in Mac OS is one of these. It should be always clearly visible. It’s a functional anchor. It’s your safe place. It shouldn’t be fancy, mutable, confusing.

In Big Sur, the menu bar by default isn’t solid white, but has a noticeable degree of transparency: it takes the colour of the desktop wallpaper behind it, in an attempt to blend in with the rest of the desktop environment. Some may consider this sleek, but it’s just gimmicky and usability-hostile.

What happens when the desktop wallpaper has darker colours? Well, menu items and menu bar icons become white, of course. The problem is that the wallpaper doesn’t have to be too dark. This is with the background picture “Mojave (day)”:

Menu bar with dark desktop

The contrast is awful, and so is giving that subtle shadow to the menu bar elements. For now, the only solution is to select Reduce transparency in System Preferences → Accessibility. This brings the menu bar back to a useful state, solid white with black elements. And I hope this is just a bug, but with certain desktop wallpapers, when you select Reduce transparency, the black menu bar elements retain that subtle shadow and have this embossed, glossy look that I don’t find particularly pleasing or useful (personal preference) — text and icons look smudged:

Menubar with dark desktop and transparency on

Also, this shifting between black and white menu items and icons may become annoying if you have your desktop wallpaper set to change at specified intervals. Light wallpaper! Black menu bar elements. Dark wallpaper! White menu bar elements. Neither light nor dark wallpaper! Whatever Big Sur decides.

Reduce transparency should be more fine-grained, too. When you select it in the Accessibility preference pane, it makes the menu bar look ‘good’ again, but it also makes the Dock background milky, and this, at least to my eyes, makes the app icons in the Dock more difficult, not easier to parse. Perhaps the simplest solution would be to bring back this option, which was first introduced in Mac OS X 10.5 Leopard under System Preferences → Desktop & Screen Saver:

Old menu bar preference

In Big Sur, it could be added to the options available in System Preferences → Dock & Menu Bar.

Wrapping it up on a positive note

When it comes to user interface details I know I can be pedantic. I largely focused on the menu bar because it’s such an essential part of the UI that you can’t ignore when something feels wrong. But my first general impression of Big Sur beta on this 2015 13-inch MacBook Pro is overall positive: the system feels a bit snappier than Catalina, and 24 hours after installing it I haven’t encountered any particular issue, save for an unexpected quit of the Maps app when I first launched it. 

All the sleep-related issues this MacBook Pro showed after installing Catalina have disappeared. Now the computer sleeps reliably when I put it to sleep, even by simply closing the lid — as it should. As for battery life, it’s too soon to say, because so far I haven’t stressed the Mac very much, but the feeling is that Big Sur seems better than Catalina at energy saving. It feels less wasteful. Which is a good thing, because I’m always wary of beta software and battery management.

So far, this beta of Big Sur — apart from some rough edges related to the user interface — doesn’t really feel like beta software. Whew.

Previous logbook entries

Mac OS Big Sur logbook (intro)

August 14, 2020
by Riccardo Mori
Software

Before I start this, I think a brief recap is in order. 

In recent years, I’ve become increasingly wary about installing a new Mac OS release right away. Persistent bugs, new features that haven’t been particularly compelling to convince me to leave behind what is not broken, things that used to ‘just work’ becoming more like ‘it should work, hopefully’ have all contributed to significantly cool my enthusiasm when it comes to Mac OS. 

After many years with a 2009 15-inch MacBook Pro as my main machine, running all supported Mac OS versions from 10.6 Snow Leopard to 10.11 El Capitan without issues (I skipped 10.10 Yosemite entirely, however), now my two main Macs are a 2017 21.5‑inch 4K retina iMac and a 2013 11-inch MacBook Air. The iMac was purchased new, the Air second-hand. I got both Macs in 2018, and they’ve been running Mac OS 10.13 High Sierra without a problem.

When Mac OS 10.14 Mojave was released in September 2018, I honestly didn’t find anything in it that was worth leaving the stable environment of High Sierra behind. Also my iMac, unfortunately, still has a traditional hard drive, and Mojave would have upgraded the filesystem to APFS — and this, in turn, would have meant a noticeable performance loss, as APFS notoriously works much better with SSDs. So I stayed on High Sierra.

Then came Mac OS 10.15 Catalina, and after learning about the level of bugs and disruption it would bring to my workflow, I was even less eager to upgrade. I heavily rely on Mail. I have email archives that go back 20 years which I was able to preserve Mac after Mac, and Mac OS X version after Mac OS X version. Believe it or not, I haven’t had an issue with Apple’s Mail app since I started using it in Mac OS X 10.1. After hearing about Catalina’s Mail-related bugs, I didn’t want to take the risk. Also, I still use some 32-bit apps and games, and Catalina dropped support for 32-bit apps completely. So nah, Catalina was more trouble than it’s worth, and I was not alone in thinking that. 

But still I was in a bit of a predicament. A part of me would just curmudgeonly be happy to stay on High Sierra, or maybe update the 11-inch MacBook Air to Mojave at least, and that would be that. End of the story of Mac OS for me. But what if one day some specialised application I use for work updates and starts requiring Catalina? What if some Mac app I need to test or localise has Catalina as minimum requirement?

I don’t believe in upgrading your devices for the sake of upgrading, but I believe that in this day and age one has to be technologically flexible. So I started to consider the idea of acquiring a used Mac that is recent enough to run Catalina but at the same time doesn’t break the bank. An ideal candidate could be a 2014 Mac mini, a model that on the used market is less sought-after than the 2012 models due to its limited upgradability and more intricate disassembly. I could perform a clean install of Catalina on it, and use such a machine as guinea pig, for app testing purposes, and the like.

With the help of a couple of splendid fellows, I was able to acquire a much better candidate — a 2015 13-inch retina MacBook Pro — for probably less money than a 2014 Mac mini. Having a newer machine is always a plus, and a laptop is overall much better because it’s more manageable. You don’t have to hook it to an external display, keyboard and mouse every time you need to use it.

So I installed Catalina on it, had my share of issues (though somewhat fewer than expected), and at this point — I thought — why not wait for the public beta of Mac OS Big Sur, install it, and share my notes as I go along? (Where possible, of course.)

Here we are, then. Over the next days I plan to do just that in the form of short-to-medium ‘logbook entries’, just as I did with Snow Leopard eleven years ago. This is Entry Zero because I needed an introduction, and because for now I still haven’t installed the Big Sur beta. My plan was slightly delayed by the temporary unavailability of this and another website of mine. The hosting company apparently did a server migration and there were some DNS issues along the way. As I was waiting for the records to update and propagate, whenever I loaded my website another one appeared. This went on for about 24 hours and gave me a bit of a scare. My mind was elsewhere as I waited for things to get back to normal. 

First step: enroll my Mac in the Apple Beta Software Program

That went rather smoothly: you basically do it using your Apple ID and accepting Apple’s Terms and Conditions. During the Sign-up process, though, I was forced to enable two-factor authentication, and I just don’t like it. I know, two-factor authentication is an added layer of security, how can I not like it? Oh, I don’t have an entirely rational explanation. Some friends of mine ran into issues and were locked out of their accounts after enabling Apple’s 2FA, so there’s that. But mostly it’s just that I don’t entirely trust the method, preferring to rely on stupidly strong passwords, and I don’t like giving my phone number to tech companies. 

I also don’t like to be forced into doing something without having a choice. Another example: I can’t access the iCloud Web interface anymore because Apple thinks my password is not strong enough and doesn’t fit their password criteria, so if I want to access my iCloud account from a browser, I must update my Apple ID password. I have that password stored on so many devices that it would be a huge hassle to update it everywhere; but more importantly, I just don’t like Apple’s patronising attitude here. So I won’t budge. 

Anyway, tomorrow I’m downloading the Big Sur beta on the MacBook Pro — let’s see how it goes.

Mac OS Catalina: more trouble than it’s worth (Part 4)

July 30, 2020
by Riccardo Mori
Software

I am the first to wonder whether it makes sense to write yet another part of this little saga, when Catalina is basically entering its last two months of active duty. But Catalina remains, I think, one of the most (if not the most) controversial Mac OS X releases, and now that I have finally had direct experience with it on a new machine I’m using just for testing, I can confirm. But first things first.

Feedback update

When I wrote Part 3 back in February, the feedback amounted to 107 emails. Of those, 96 were negative, 7 neutral, and only 4 positive. As a reminder, by ‘neutral’ I mean emails from people who wrote to tell me that they updated to Catalina and things kept going on in a business-as-usual fashion. ‘Positive’ feedback means emails from people explicitly telling me their experience since updating was better than before, for a reason or another (performance; a new feature of Catalina they found especially useful; etc.).

As of this morning, the email count is at 370. The negative-neutral-positive ratio has essentially remained the same, with 309 negative-feedback emails, 29 neutral, and 32 positive. And once again let me stress the fact that I’m not trying to use this data to prove anything — it’s all very anecdotal. 

At the same time, I can’t but remark that it’s all very suggestive, too. Back in October 2019, when I wrote Part 1 of this accidental series of posts, I never expressly solicited readers to send me emails and tell me their tales, whether of woe or joy. And yet, I’ve never received such amount of feedback about any other Mac OS X release, or any other topic I’ve ever written about in the 15 years I’ve kept a tech blog. And while there is the occasional terse email, and the occasional message that goes off-topic and simply criticises my articles (I’ve left these emails outside the Catalina-feedback pile, of course), most emails are detailed accounts of what went wrong since updating to Catalina — or what Catalina does right in the case of positive feedback messages.

When a couple of articles from this series on Catalina reached Hacker News in the past months, a lot of quips I got as response were from people who dismissed the problem altogether with remarks along the lines of These nerds must always find something to complain/whine about. There’s nothing wrong with Catalina. Well, that’s simply not the impression I’ve had and continue to have. And not because I have 309 emails of negative feedback and horror stories to prove it, but because this volume of feedback itself is an indicator, in my private sphere, of a larger discussion that has been going on publicly (in online forums and specialised mailing lists) since Catalina was released last autumn.

Finally updating to Catalina: my first impressions

I closed Part 1 by writing:

So, to conclude, do I plan to stay on High Sierra or Mojave indefinitely? It’s hard to say and too soon to tell. Both my main Macs are really working flawlessly at the moment, and Catalina is beta-quality software that’s likely to give me headaches I don’t need right now. Who knows, maybe down the road I could acquire a cheap used Mac that can run Catalina (something like a 2014 Mac mini) and use it as a test machine. As things are now, I absolutely do not want Catalina to mess with my current setups and data. The cost for me would be higher than getting a second-hand Mac mini. 

Recently, a very kind soul from the UK gave me the opportunity to acquire such a test machine, but it ended up being a far better deal than a 2014 Mac mini. For a really low price given its specs, I was sent an Early 2015 13-inch retina MacBook Pro, with 8 GB of RAM and 256 GB of flash storage. The Mac is in overall very good condition, save for a blemish on the display (which can be ignored in normal use, fortunately), and a well-used battery with more than 1,250 cycles (but still working well and giving me plenty of hours of use). 

The machine arrived completely wiped and reset, with a clean install of OS X 10.11.6 El Capitan. My plan was to perform a clean install of Catalina, take a look at it for a while, then move on to the Big Sur betas.

What I was eager to test was something I’d been thinking about while reading all the feedback emails on Catalina. My simple hypothesis was that clean installs of Catalina tended to be less problematic than mere updates from High Sierra or Mojave. I know, nothing particularly original or astute. But even in my limited sample I could see a pattern forming:

  • Many negative emails were from people who were attempting to upgrade, and Catalina gave them trouble both during the update process and afterwards;
  • Very few negative emails complained about having issues with Catalina after a clean install (currently only 8 emails out of 309);
  • About half of the positive emails were from people who, after I enquired, told me they had performed a clean install of Catalina.

These points strongly suggested that the less the system was cluttered with preexistent crap, the better Catalina would behave.

And so, after a few days spent on El Capitan to see if everything was working fine on this ‘new’ MacBook Pro — and it was — I downloaded and installed Catalina. Unfortunately, as I wrote on Twitter, I haven’t had much time to tinker with it or to inspect it more closely due to a very high workload I was subjected to for the past three weeks. The only things I’ve noticed so far are these:

  • After installation, there were a few constantly-running processes that kept the CPU busy all the time. This seriously impacted the MacBook Pro’s battery life, and its general performance. I found a solution to the problem by searching online, and it probably wasn’t something a regular user would know how to apply.
  • After installation, and recalling other people’s accounts, I expected a barrage of security and permission-related dialog boxes. I haven’t really seen one so far. Probably because it was a fresh install and not an update?
  • I can’t say anything about data loss because it’s a fresh install on a new machine for me, so I had no data to lose in the first place. But there were things that didn’t download/update after installation (Dictionary app without dictionaries, App Store app without updates, etc.)
  • Just out of curiosity, I installed the Steam client and took a look at my games’ library. Less than one third of them are Catalina-ready. I know games aren’t critical apps, but I would have been really bummed to discover this if I had rushed to update my main Macs. I’ve been told that, a lot of times, despite the warning that a certain game is not compatible with Catalina, it turns out that it’s not the case, and the game runs fine. But in my case I have verified that most of the games in my library really won’t run in Catalina.
  • On a slightly less serious note, by installing Catalina on this MacBook Pro, I finally had the opportunity to try Dark Mode for the UI (remember, my main Macs are still on High Sierra, so I hadn’t experienced it yet), and I immediately reverted to Light Mode. Dark Mode feels like possibly the most overhyped feature in the history of Mac OS X. I think the traditional light UI with Night Shift or f.lux is much easier on the eyes when working at night.
  • Another issue that seems to plague this MacBook Pro since installing Catalina is related to sleep. In a nutshell, sleep has become unreliable. I put the MacBook to sleep either by selecting Apple menu → Sleep, or by just closing the lid, and sometimes the Mac goes to sleep correctly and stays hibernated, but sometimes it does not. You get the bitter surprise the day after you fully charged the MacBook before putting it to sleep, when you wake it up and discover the battery charge has fallen to 65–70%. I have tried several solutions and workarounds but nothing definitive so far. I’ll have to thoroughly check the sleep/wake logs to find which process(es) interfere with the MacBook’s sleep[1].
  • Finally, Time Machine backups keep failing. Why? Your guess is as good as mine.

After these preliminary findings, I can say that even with the cleanest of installs Mac OS Catalina can be problematic. This is disappointing, but a part of me is somewhat not surprised.

All in all, I’m glad I have this new MacBook Pro to use as guinea pig, because I still don’t feel comfortable updating my production Macs. I haven’t even logged into iCloud in this Catalina installation, for fear it might mess things up. But again, as I said, I haven’t had the time to explore Catalina properly yet, and at this point I don’t even know if I will, because as soon as I’ve dealt with this demanding workload, I will install the Big Sur betas.

Previously:

 

  • 1. The pulsating sleep light was such a nifty visual clue that your Mac was effectively sleeping when you told it to. Now it’s a guessing game. ↩︎

 

On the possibility of touchscreen Macs

July 12, 2020
by Riccardo Mori
Tech Life

In this video, Quinn Nelson points out something I, too, had noticed when taking a look at the user interface of the first beta of Mac OS Big Sur. That is, many controls and UI elements appear to have odd spacing for a traditional desktop user interface. It seems as if they were prepared to accept touch input. So now of course the next wave of speculation, post-WWDC, is that touchscreen-enabled Macs may appear in the not-so-distant future.

The biggest piece of evidence to support this theory seems to be what Craig Federighi himself announced during the WWDC 2020 keynote:

As you saw, Macs built with Apple Silicon will be able to run iPhone and iPad apps directly. Starting day one, users can download these apps right from the Mac App Store, and most apps will just work, with no changes from the developer.

Quinn Nelson adds:

The implications of this are huge, but it goes even a step further than that, because during the State of the Union address after the keynote, Apple announced that all iOS apps, both iPhone and iPad, would be available for Apple Silicon Macs in the Mac App Store by default, and the developers, if they didn’t want their apps available for ARM Macs, would have to actively opt out. From the outset this might sound like a good idea: if your desktop and your laptop and your mobile operating devices all run the same instruction set and codebase, well, why wouldn’t you allow for cross-compatibility to bolster these newfangled ARM Macs with the largest software catalogue possible?

But here’s the thing. I don’t peg Apple as a company that would fill their App Store with a bunch of broken, crappy apps that would significantly diminish the experience for these new ARM Mac users. And without a touchscreen, that’s what it would be for a lot of apps — crappy. Most games (which, remember, will be made available by default on day one) require Multi-Touch, and the last time I checked a mouse cursor could really only replicate one finger […]. Come on, you really think that that’s what Apple’s gonna do for consumers? This is Apple: a company that is obsessed with image and visual polish to a fault; and that’s why I was a bit confused by the announcement at all. Because think about it: without a touchscreen, the experience of using iPad and iPhone apps on a Mac will be pretty terrible — even worse than the really really bad Catalyst apps that Apple has been fervently trying to prove can be good.

It’s a solid argument. But on the other hand, consider the following: if making iPad and iPhone apps available for Apple Silicon Macs from the start is the primary reason that signals the impending arrival of touchscreen-enabled Macs, then, by this very reasoning (a Mac with a touchscreen would help achieve the most seamless experience when using iOS apps directly), all Apple Silicon Macs would need to have a touchscreen. Is Apple going to introduce an external touchscreen display for Mac mini users? Is Apple really going to equip all laptops and iMac-like Apple Silicon Macs with a touchscreen? I may be wrong about this, but to me it looks like a terribly expensive solution for Apple and for the consumers. Can you imagine a 27-inch iMac with a good quality touchscreen display?

My theory can be roughly summarised in two main points.

1. There is going to be a Mac model with a touchscreen display

Whether I agree or not with Nelson’s overall take, his observations regarding the increased space in several UI elements within Mac OS Big Sur’s interface have merit. That spacing could very well be simply a cosmetic feature, just to bring more homogeneousness between Mac OS and iPadOS’s interface; or it could indicate that Big Sur is going to support touchscreen Macs. I think Apple is maintaining this sort of ambiguity to have more freedom of movement, to keep their options open just in case. I think they could be planning to release an Apple Silicon Mac that works like a 2‑in‑1 laptop/tablet hybrid, a sort of portable professional/business machine with advanced tablet functions. Apple’s version of a Microsoft Surface, in a nutshell.

It makes sense that they would prepare Big Sur from the start to have a touch-friendly interface. And this wouldn’t even contradict Apple’s long-time stance that touchscreen Macs make little sense. They could say, This class of device can be used just like a traditional Mac with full support of traditional input methods, but it can also become a powerful pen- and touch-based device when needed. Of course, like other 2‑in‑1 devices, it would be more focused on portability and long battery life than sheer performance (though a considerable level of performance would be guaranteed anyway due to it being equipped with an Apple custom SoC). This way, it wouldn’t interfere too much with the sales of ‘regular’ Mac laptops and iPads.

2. Another way to interpret Apple’s announcement

While it’s great that Apple Silicon Macs will be able to run iPad and iPhone apps directly, and that “Starting day one, users can download these apps right from the Mac App Store, and most apps will just work, with no changes from the developer”, it’s also obvious that developers will have to implement a few changes in their apps if they want to offer a good experience to those who want to use them on their Macs. So, what do you think is more likely?

  • (a) That Apple goes the extra mile and starts equipping all new Apple Silicon Macs with a touchscreen display; or
  • (b) that Apple is giving a not-so-subtle hint to iOS developers that goes like this: With full cross-platform compatibility, your apps will run on Macs directly and we will make them available from the Mac App Store from day one, so if you want the opportunity to extend your apps to Mac users as well, you should start working on optimising them for the Mac and its user interface right now, because the clock is ticking.

I’m thinking (b). With a bit of optimisation (how hard this is going to be depends on the type of apps they offer), an iOS developer can provide a separate Mac OS and iOS app with a seamless experience across the platforms (visually and functionally), instead of just having an iPad app that can run on a Mac, but poorly. It’s also more lucrative for a developer, who can effectively charge for two distinct versions of the same app, instead of offering just a one-size-fits-all app at a single price. Who knows, maybe Apple will also let developers offer Mac OS/iOS bundle pricing, so if you have a Mac and an iPhone, or a Mac and an iPad, or the three devices, instead of purchasing Cool App for iOS/iPadOS at $3.99 and Cool App for Mac OS at $6.99, you could get a bundle with the two apps for, say, $8.99. Or maybe it could be a higher subscription tier, for those developers who favour such an approach. What is more lucrative for a developer is also more lucrative for Apple, ultimately.

 

Again, I may be completely wrong about this, but it’s a bit hard for me to see Apple just start making Macs with a touchscreen display so that they all can run whatever app you throw at them, as is. If all new Macs with Apple Silicon could be used this way — especially laptops — then the only reason to get an iPad would be its lightness and compactness. There would be more overlap between classes of devices.

As I said above, Apple could offer one class of device with Surface-like functionality. But Apple isn’t Microsoft. They don’t need to offer such a device: they already have good tablets and good desktop/laptop computers; it’s probably in Apple’s best interest to keep the two lines separate. A Surface-like Apple convertible, however, could function as bait for people outside the Apple ecosystem — people who today are using Surface devices because they love and take full advantage of the laptop/tablet hybrid formula.