Riccardo Mori

In general, when I feel I have something to say on a certain subject, I tend to write articles with the goal of being as thorough as I can, at least within the scope I’ve established for the article. This is a habit I’ve formed over time primarily because

1. Too often I stumble on posts or articles that seem to just share an idea, impression or opinion without elaborating much on it. They’re frustrating reads, because it feels as if the author never wants to commit to the next step — why they think it’s a good idea, where this impression comes from, why their audience should take their opinion on the matter into consideration. A casual example could be a post that goes like, “Apple should implement this feature” and the ultimate reason is because such feature would be handy for how the author uses their Apple products. Tunnel vision galore. When people read my articles, I really want to avoid giving them the impression that, technically speaking, I’m talking out of my ass.
2. I want to be as clear as possible with regard to the subject I’m elaborating on. If sometimes my tone feels pedantic, it’s because I want people to understand exactly what I mean. I still don’t always succeed, but in some cases it turns out that it’s because some people are just incapable of reading long-form pieces, or are so prejudiced about a topic that they’ll never accept my viewpoint no matter how clearly I explain it.

There are times, however, where I feel that I have enough observations on a subject to write an article but that, past a certain threshold, I can’t be as thorough as I’d like because I’ve hit the ceiling of my knowledge and venturing further would clearly show that I’m out of my depth.

This is what happened with my previous article, A brief reflection on Mac software stagnation, where I could provide a few impressions as a power user and observer, try to explain where those impressions came from, and then stop there, because to venture further without being a developer, without having the technical know-how and perspective of a developer, just felt like a bad idea. Still, I hoped to receive some feedback from developers, so that I could understand whether my impressions were on the right track or not.

The feedback

I noticed some very good reactions and received valuable feedback, which I wanted to share here so that it doesn’t get lost in Twitter’s ephemerality.

1.

Sam Rowlands, a long-time Mac developer, reacted with this short thread on Twitter:

It’s my belief, the App Store has caused irrevocable harm to the Mac software industry. There is ‘sideloading’, but the Mac Media is just a shell of its former self after Apple gutted it, with a bait & switch campaign of affiliate links.

Many indie developers can’t afford the kind of advertising that Apple’s “preferred” developers can. So we’re forced to adopt a Minimize Risk attitude, which reduces indie devs’ incentives to allocate years into building a complex, complete, great Mac application.

Not to mention that [when you] support more than one year macOS version [I think Sam means supporting backwards for more than just the previous year’s Mac OS version], your code ends up littered with minor performance degradation as you need to use this API on this version, that API on that version, and flip the result for version, sometimes these need to done for point releases of the macOS, not just major versions.

All in all, developing for the macOS is not as great as it was 10 years ago, it’s become expensive to maintain a macOS application, which eats into the time an indie can be creative, and eats away at them emotionally.

I believe I’ve watched more indie give up in the last few year, than I’ve met new excited macOS developers, who’re ready to tear up the rule book and bring the Mac back into the spotlight.

I believe Apple needs a CEO upgrade.

Sam also pointed me to three relevant articles he has written on his blog over time:

• No one downloads, no one sees — Sam told me: “[Here is] where I discuss how I feel the App Store has changed in a way to the detriment of indie developers”.
• Improving Mac app exposure — “My second article was trying to put a positive spin on it, and list some things that indies could do to help promote their apps”.
• The Mac App Store in 2022 — “The third article is about the changes I feel Apple could make, which would make the App Store a better environment for indie developers and customers”.

In the first of these articles, among other things, Sam says, While a great many things changed over the next decade, negatively affecting Apple’s indie developer industry, the massive reduction in exposure is a major problem.

This has got me thinking about how I used to discover Mac software before the Mac App Store was launched in January 2011. Essentially, there were four main channels that led to discovery:

• Word of mouth, both online and offline. It could be a friend’s recommendation, an email from one of my readers, a message in a mailing list, a mention on Twitter, etc.
• Computer magazines. It could be an in-depth review, a mention within a particular, larger feature (e.g. The best utilities for compressing files), or simply a freeware/shareware included in the magazine’s CD-ROM.
• Online reviews: in Mac-oriented tech websites (like the digital counterparts of the same computer magazines I used to buy — Macworld, Mac User, MacFormat, etc.) or personal blogs. By the way, there used to be many more blogs and sites specifically dedicated to app reviews, curation, and discovery. I’ll always lament the loss of places like AppStorm and AppShopper. (I’ve linked to archived pages so that you get an idea of what I’m talking about.)
• Web search: a bit of a last resort, but still useful to discover new applications. If I stumbled onto something interesting and I wanted to know more before risking a download or purchase, I could always perform another search for reviews of such app.

Now here’s what I’m thinking. Given that app discovery is currently still terrible in the Mac App Store (the sheer crappiness of App Store search after more than a decade since its launch never ceases to baffle me); given that App Store exposure is still problematic for a lot of indie developers, for the reasons Sam outlined in his article; and finally, given that at least three of the four ways to discover new apps I’ve listed above are still perfectly valid to discover apps today, I’m really wondering if, for a developer, publishing their app on the Mac App Store is worth all the trouble.

Think about it: as a user, how many useful apps have you discovered only via the Mac App Store? I’m not talking about apps prominently featured on the App Store’s home page, of course, but apps you found by searching or actively browsing the App Store. In my case, I think it was just one. I needed an aspect ratio calculator and I was pressed for time, so I did a quick search in the App Store, found one after a while, it was generally mediocre but did the job I needed it to do at the time. One app in eleven years of the Mac App Store’s existence is just ludicrous. And honestly, it would still be ludicrous if it were five apps, or even ten.

Go read Sam’s articles now — he makes good points I very much agree with.

2.

Another reaction worth pointing out is Maciej’s, who told me on Twitter:

The sad part is that Catalyst and native iOS apps running on macOS aren’t even the largest offenders. That title goes easily to all those who push “apps” written in Electron and similar. Compared to those, Catalyst is marvellous.

There’s also the matter of crappy documentation. I’m not a developer but this has been a recurring theme for years. Introduction of APFS is a great example. Major change with piss-poor support articles. How can you write advanced software with crap like this?

There’s the lack of effort on Apple’s part too. Why would third parties be interested in developing exceptional software when even the OS maker doesn’t seem to be that interested? Music [the app] is a great example here. There are exceptions (iWork) but that’s what they are, exceptions.

[…] The Mac App Store has been a failure and Apple has largely failed on improving it in any meaningful way. Despite the influx of new Mac users the software discovery process seems to be worse than ever. The crap (normal) people get from the App Store is incredible.

There’s also Big Sur: a visual redesign that nobody asked for. And one I think nobody was super-positive about. If I were a small dev who actually cared about this I would have been seriously annoyed.

Here’s how this process looks like for laypeople, who are completely new to the platform:

• get a Mac;
• open Mac App Store;
• type the name of their favorite iPhone app into the search box;
• get some terrible knock-off version.

When even die-hard Mac companies refuse to put their products in the App Store (or do so and remove them after some time or put a castrated version in MAS) you know something’s seriously broken. And it’s often not even about the money.

I think that (all faults aside) Setapp has done more good in terms of curating and giving easy access to quality Mac software than Apple over the past few years. If I had a new user in front of me I’d rather they sourced their apps from there rather than MAS, less overall crap.

Again, I pretty much agree with everything Maciej points out here. The Music app (at least for how I typically organise and listen to music on my Macs) is so bad for me that Apple has managed to make me feel nostalgic about iTunes. In fact, I still use iTunes to manage my local music library, and I do so on Macs with older versions of Mac OS. For instance, on my PowerPC Macs running Leopard, iTunes 10.6.3 is a rock-solid app. iTunes 9.2.1 on my PowerPC Macs running Tiger is another very good, very stable version.

It’s funny how we always complained that iTunes had become a bloated, mastodontic piece of software, that it simply had too much stuff to manage for its own good, that it needed to be split into several smaller apps to better tackle certain tasks, and we ended up with a series of single-task apps that are just mediocre when taken separately, and still of lesser quality than iTunes when taken collectively.

I also agree with Maciej about Setapp, at least when it comes to app curation. I tend to avoid subscription services, but I’m sure that Setapp’s model and pricing is a really good deal for users and participating developers. I’m not a subscriber simply because, figuratively speaking, it’s a buffet that offers much, much more than I can eat.

3.

I confess I was nervous about how developers could respond to my article. I always triple-check every time I mention technical aspects of software development, because I’m not a developer and I’m afraid of basing an impression or an opinion on something that turns out to be technically wrong or misunderstood on my part.

I was particularly honoured by Tyler Hall, who not only did appreciate my initial article, but took the time to write a response: Half-assed Mac Apps. It’s a really great piece, and I felt that Tyler added the necessary knowledge and insights to pick up my sort-of unfinished reasoning and bring it to completion.

4.

Just as I was finishing this piece, I noticed another reaction on Twitter, by user teknisktsett:

For the English-speaking market, the Mac app market covers most users’ needs in terms of commercial apps like MS Office, Adobe or Affinity apps and other productivity apps, as well as Utilities. What’s missing is catering to the international market.

When was the last time you made a Mac app to serve the needs of users in India, Thailand, Greece or Italy? Just to name a few examples. Not being in US or UK, I’m pretty tired of yet another clone of a US-catered leisure app measuring how many cups or gallons of water I should drink, or how many miles I ran yesterday. Who knows? I measure in metric kilometers, so to make me a user, I need the metric system support.

I care about carefully-designed native apps, but it’s not the only thing to consider: localization (not AI-translated), cultural diff, metric and imperial — and properly native in Cocoa (using Objective‑C or Swift) or SwiftUI.

Localisation is an important point, and I feel especially bad for not having brought it up myself, given that I’m a translator and localisation specialist. In the section Why choosing a professional translator is important on my Services page, I even say, “A translator helps clients expand their audience: multilanguage versions of texts, websites and localised applications can thus reach a broader, international audience, which is always an advantage”. So I absolutely agree on what teknisktsett is saying here. In a sense, staying English-only limits your user base abroad to only those people who know enough English to use your apps. This generally means a demographic that’s largely made of younger people and/or people with higher education.

However, what I’ve noticed in my 10-year experience in localising applications, is that in at least 80% of the cases, only medium-to-big software studios can afford the investment of having their application(s) professionally localised. Most of the times that I’ve reached out to indie developers proposing a collaboration where I could localise their app in Italian or Spanish (which is the second most-spoken language in the US), the reaction I got was always the same — I’d love to, but can’t afford your services. And this is not because my fees are particularly demanding. I think it’s more related to that ’Minimising Risk’ approach Sam Rowlands mentioned when he responded to me on Twitter.

Because while I’m sure that many developers would be thrilled to offer their apps in more languages than English — the potential of extending their user base is undeniably there — investing money on that is still a risk for them because there still exists the issue of poor discoverability and exposure.

Update — About the localisation aspect, Jeff Johnson responded on Twitter:

1. I can’t provide customer support in anything except English, which makes me wary of localization.
2. I can’t just localize once and be done. I’m constantly updating my software, web site, and documentation. So it feels like I’d need a permanent translator on staff.

Fair enough, and it further corroborates my experience, that in most cases only medium-to-big software companies can afford the investment of professional localisation.

I think that’s it for now. I want to thank all those who have given me valuable feedback on the topic so far, and I’ll definitely be adding other personal thoughts and external contributions in the future. This is a subject that’s particularly close to my heart, because at this stage I think that Mac users — especially power users — do need more than just professional, ultra-fast Macs. Great hardware without great software isn’t enough to make a platform thrive or continue to thrive.

If you’ve been a Mac user for more than a few years, let me ask you a question: what is the newest application you have installed that turned out to be so useful and well-made it’s now part of your essential tools? An app that really got you excited and happy to be a Mac user? For the sake of argument, let’s leave out games (obviously) and single-purpose little utilities.

In my case, it’s TextBuddy by Tyler Hall — but it’s truly an outlier in an otherwise flat landscape. I was reflecting on this a few days ago as I was looking at the Purchased section of my account in the Mac App Store app.

First, as you can see, the apps I’ve purchased or downloaded since 2019 are just a handful. Most are single-purpose utilities, social media clients, or Safari extensions. The biggest apps in this short list are Microsoft Word, flickery, and Pixelmator Pro. None of these is a ‘new app’: Word has been around for a long time; I don’t know when flickery first debuted, but the fact that its minimum system requirement is Mac OS X 10.6.6 suggests that the app has been around since Snow Leopard; Pixelmator Pro is the newest of the three, but still, its first version was released in November 2017, more than four years ago.

And while Pixelmator has indeed become part of my essential tools, I tend to use Acorn more often, and Acorn has been around since 2007. By the way, the impact Acorn had on my workflow can’t be overstated, since it was the application that made me move away from Photoshop back then; it’s currently installed on all my Macs, even old machines running Mac OS X 10.4 Tiger.

In other words, if I open my toolbox with all the essential Mac apps I use on a daily basis for everything I do, what I see are old (some very old), tried-and-trusted applications: BBEdit, Transmit, MarsEdit, Acorn, NetNewsWire, Reeder, Notational Velocity/nvALT, Graphic Converter, Aperture (yes, still using it under Mac OS 10.13 High Sierra), The Unarchiver, Skim (a solid PDF viewer that’s been around since 2007), VLC, Apple’s Image Capture (still the fastest for importing images from an iOS device), xScope, Find Any File, SuperDuper!, AppZapper, f.lux, iA Writer, iStat Menus…

This may be a completely subjective observation, but I’ve been feeling a certain stagnation in Mac software these past few years. There are always exceptions and things I’ve missed, sure, but it seems to me that the landscape appears to be more tired than vibrant. More broadly — and this is an image I’ve already used in the past — the Mac as a platform appears trapped in inertia instead of progressing; it feels as if the Mac software train has reached its final destination, and everyone is just building over and around the terminal station.

Ideally, at this point in my article I should start the next paragraph with The reasons for this perceived stagnation are — followed by a bullet list. But I don’t feel it’s so clear-cut.

There are factors that should be considered when observing the current state of Mac software, factors we could use to paint a picture that is necessarily imperfect and speculative.

The first factor to consider is the iOS platform. Historically it has had a considerable impact on Mac software development, starting within Apple itself. It’s no mystery that Mac OS X 10.5 Leopard took so long to be released because Apple internally turned most of its resources to the development of the iPhone and its operating system. When iPhone OS opened to third-party developers in 2008, many third-party Mac developers similarly started concentrating their efforts to come up with fun and useful iOS apps to add to their catalogue.

Did this slow down Mac software innovation? I’m not sure. Certainly not at first. The 2008–2010 years were a period in which iOS meant iPhone and iPod touch. And as revolutionary as the iPhone has been, in its first years it was still perceived as an ancillary device, with the Mac still at the centre of that Jobs-defined ‘digital hub’. But things started to change, again, with the introduction of the iPad in 2010. While many iPhone/iPod touch apps initially had a ‘Dashboard widget’ feel to them, the iPad’s biggest canvas allowed for more Mac-like applications.

During the golden era of iOS — both on iPhone and iPad — it was understandable that they would become the priority for any Apple developer, especially for new developers, since iOS looked more appealing to develop for, both from a financial and technical standpoint.

Then there’s Apple’s agenda to consider. Remember when Mac OS 10.14 Mojave was previewed at WWDC 2018? Craig Federighi (Apple senior VP of software engineering) said that some iOS apps for iPhone and iPad would also work in Mac OS, then he emphatically added: “Are you merging iOS and Mac OS? I’d like to take a moment to briefly address this question”, and this slide appeared behind him:

“No, of course not,” he continued. “We love the Mac, and we love Mac OS, because it’s explicitly created for the unique characteristics of Mac hardware”.

The problem is that, while it’s true that iOS and Mac OS have remained two separate operating systems, Apple has been really pushing to have them both work in the same way when it comes to their underpinnings.

Let’s take a little step back and try to explain this as simply as possible, mashing together a few lines taken here and there from Wikipedia.

Cocoa is Apple’s native object-oriented application programming interface (API) for its desktop operating system macOS. Cocoa consists of the Foundation Kit, Application Kit, and Core Data frameworks, […] and the libraries and frameworks included by those, such as the C standard library and the Objective‑C runtime.

For end users, Cocoa applications are those written using the Cocoa programming environment. Such applications usually have a familiar look and feel, since the Cocoa programming environment provides a lot of common UI elements (such as buttons, scroll bars, etc.), and automates many aspects of an application to comply with Apple’s human interface guidelines.

For iOS, iPadOS, tvOS, and watchOS, a similar API exists, named Cocoa Touch, which includes gesture recognition, animation, and a different set of graphical control elements. It is used in applications for Apple devices such as the iPhone, the iPod Touch, the iPad, the Apple TV, and the Apple Watch.

One important framework of Cocoa Touch is called UIKit, which derives from the Mac’s Cocoa framework Application Kit, or AppKit. When Mojave was previewed at WWDC 2018, Federighi said that four new apps would be included in Mojave — Home, Voice Memos, Stocks, and News — and that these apps were ports of their iOS counterparts. Such porting was made easier because Apple was incorporating iOS frameworks into Mac OS.

Such ‘hybrid’ apps, containing both the (Mac) AppKit and (iOS) UIKit frameworks took the name of Catalyst apps. The base concept appears to be practical and developer-friendly: let’s remove the friction of having to deal with platform-specific frameworks, and let’s just have a system where you can effectively build universal apps that can run on iPhone, iPad, and the Mac with little effort. The problem of many such apps, especially those built with too little effort, is that they appear and behave in a way that doesn’t feel very Mac-like, with UI elements that clearly are just cut & pasted from iOS and poorly adapted to offer a good, usable, consistent experience under Mac OS.

Now it’s 2022, more than three years after Mojave and the first Catalyst apps appeared, and while Apple and others have released a few decent Catalyst apps so far, this software transition isn’t going so smoothly. Nick Heer has summed up the situation very aptly and concisely in a recent commentary piece on his blog:

Right now, it feels a little bit like the three main MacOS app frameworks are floating in unanchored space: AppKit is not the future, Catalyst is not ready to replace it, and using SwiftUI remains a long way off for big, complicated apps.

Remember when I was pointing out that iPads were becoming incredibly powerful machines but with an OS that wasn’t capable of taking full advantage of that amazing hardware? Apple has managed to put the Mac in a similar position, in my opinion. The new 14-inch and 16-inch M1 Pro/Max MacBook Pros are brutally performant and energy-efficient machines, but with an operating system that instead of aging well has been rendered immature by too many haphazard plastic surgeries. We have once again Mac ’pro’ hardware, but in the meantime the Mac as a device has been effectively demoted and removed from the centre of the digital hub. Now it’s just a device. Conceptually and from a software standpoint, now there’s the iPhone, the big iPhone (iPad), and that other desktop/laptop device that’s kind of a big iPad but without touch (the Mac).

So, back to what Federighi said in 2018 — “We love the Mac, and we love Mac OS, because it’s explicitly created for the unique characteristics of Mac hardware” — I called bullshit then, and I call bullshit now. An operating system (and relative first- or third-party applications) that really embraces the potential and the characteristics of the specific hardware it runs on needs to be built on an equally specific set of frameworks, and does not need to be contaminated by frameworks and paradigms from an operating system that historically is a simplified derivation of Mac OS X itself. It’s like manufacturing a car with the same manufacturing tools and processes of a model car. (Not my best analogy, but you get the idea).

Or, if maintaining a separate set of frameworks is too cumbersome for everybody, at least Apple should commit to improving this unified set of tools — by making it at least more complete, more versatile, and more clearly documented — in order for developers to create good applications that feel at home and UI-consistent whether they’re used on an older iPhone 8 or on an M1 24-inch iMac. The current stagnation of Mac software, I think, boils down to developers who now find themselves with having to decide which path to take, when all paths are unclear, incomplete, or awkward to follow through.

As a Mac power user and observer, I’m not optimistic. I’m not saying we won’t see great Mac apps in the future, don’t get me wrong. But I have the feeling that they’ll be the notable exception in a software landscape that will share all the worst traits of iOS — an overabundance of mediocre-to-crappy apps, the same race to the subscription model, the lack of very sophisticated software applications that can tackle more than a handful of tasks. All this on increasingly powerful Macs that could run an entire power plant alone… if only they had the right software.

A brief reflection on Mac software stagnation was first published by Riccardo Mori on Morrick.me on 24 February 2022.