Archive for January 12, 2022

Wednesday, January 12, 2022

Catching Native Apps

Daniel Jalkut, in 2010:

If you imagine a world where the sum of all things you can do with a computer is exactly matched, and locked down for all time with what you can do inside a browser, then the arguments for the web are persuasive. Why write for a specific platform when you can write for all platforms at once and gain the other advantages as well?

The error is in disregarding the many unmatchable attractions of “the desktop.”


But if I want to write a truly great app, it has to be a desktop app. And this will be true forever, or until there is no difference between the web and the desktop.

Daniel Jalkut:

Apple fixed the hardware problems with the Mac, now they must address software. We need M1-level software platform differentiation, and three competing app frameworks won’t create it. Are they even aware how tentative their footing in consumer software is? They’re not showing it.

12 years ago, I wrote “Can’t Catch Me”, wherein I proclaimed with confidence that the Mac would continue to outpace web platforms. That cockiness presupposed a much greater level of commitment from Apple than we’ve seen.

Since then, Apple has slowed the pace of improvements to the frameworks for writing native Mac apps. It added technical (sandboxing, TCC, SIP, kernel extension restrictions) and policy (App Review) roadblocks that make it harder to develop apps that go beyond what can be done with Web technologies. Apple switched to an annual release cycle, increasing the proportion of time native developers spend testing and working around bugs. For the most part, that doesn’t affect Electron apps, which are insulated from the OS with a layer of middleware, or apps that don’t take advantage of OS-specific features. And it doesn’t affect apps that run purely in the browser. So it has the effect of holding back the types of apps that push the envelope, that increase the distance between Web and desktop.

Meanwhile, Apple is no longer leading by example, at least not in a good way, as its recent Mac apps have been Catalyst ports or weird hybrids that feel more Web or iOS than Mac. Former role model apps were rewritten for iOS, then brought back to the Mac, losing features and desktop-oriented design in the process.

Automation has been a major platform-specific advantage. We once hoped for a successor to AppleScript; now we are grateful that it is at least still on life support. Automator never got much follow-through. Shortcuts for Mac is finally here but is currently rough and lacking some capabilities of the iOS version. The Mac’s Unix layer has been withering, and built-in scripting languages are being removed. Developer tools used to come free on a CD with the OS. Now, you need a paid account to ship an app that isn’t accompanied by a malware warning, and even then you have to upload each build to Apple first. Web app developers don’t need permission to deploy their code.

Apple stopped maintaining an online directory of Mac apps, so it’s harder for customers to find what’s available if it’s not in the Mac App Store. The more distance there is between your app and what a Web app could do, the less likely it is to be allowed in the store. (Even for apps in the store, browsing is more difficult than with the old directory.) Apple also stopped offering affiliate commissions on apps, reducing the incentives for third-party coverage that would help people find a Mac-only app. Web apps, however, get to share marketing across multiple platforms, and they don’t have to pay Apple 30%.

In short, it feels like the distance has closed somewhat since 2010. This is partially because Web technologies got better, but also because of inattention and poor incentives from Apple.

Daniel Jalkut:

To head off any critics who might ask, “OK, smartass, what would YOU do to improve the Mac as a platform?” I say: I don’t know, I look to historic innovators like Apple for that. I would probably start by picking three intrinsic advantages of web apps and strategize against them.

Ilja A. Iwas:

Never gonna happen, but:

  • provide means for updating/crash catching of non-MAS apps
  • provide means for paying/licensing of non-MAS apps
  • make cross-device document storage suitable for shoebox-style apps the default (indexing, full text search, conflict handling just work)


Isn’t it ironic how the Mac App Store promised a quick, secure, and easy way for developers to get their apps discovered, installed, and paid for - and it turned out to be the exact opposite with its sandboxing requirements, malware infestation, and bogus review process.

Jesse Grosjean:

Uggh electron. I’m now getting bug reports for my Mac app that the keybindings don’t work like windows.

Craig Hockenberry:

This past summer we narrowly avoided a major user interface regression on Apple devices. The story ended well, but I think it’s important to look back on the situation and ask a simple question:

Why did this happen in the first place?

My answer is something I call “consistency sin”. Understanding the cause lets us avoid similar situations in the future.


Update (2022-01-14): See also: Hacker News.

Update (2022-01-17): Steve Troughton-Smith:

I think a big part of what Apple needs to do is give AppKit apps an onramp to the future of Apple’s universal app ecosystem. SwiftUI is decidedly not that, and I think that’s a huge mistake. The Mac is going to be minimized further when Apple’s next major OS/platform ramps up

Ken Harris:

My 2¢:

  1. Documentation: Apple’s is the worst of any platform I use.
  2. Bugs: fix ’em. Also, the secret bug tracker is stupid.
  3. @SwiftLang: make it good on every platform; nobody wants an(other) OS-specific language.

Update (2022-01-24): Francisco Tolmasky:

I think the history of tabs serves as a fascinating case study of how Apple’s neglect for its own UI frameworks assisted the rise and acceptance of cross-platform frameworks like @electronjs and the corresponding decline in the importance of “nativeness” and “the HIG”.


Apple did eventually end up adding an API for tabs to AppKit, but not until 2017, 12 years after they shipped their first tabs in Safari! By that point, it was more of a pain to convert legacy code than anything, and it wasn’t helped by a woeful lack of documentation.

For a long time, the best resource on how to use AppKit’s tabs was a single WWDC video. And of course, being new, it lacked many of the features existing apps had already implemented.


In the last decade, macOS has slowly been allowed to degrade into an environment where there are increasingly fewer downsides to counteract the benefits of going non-native, and that’s not on developers. It’s been a long time coming, and it isn’t going to be easy to fix.

Update (2022-01-25): Colin Cornaby:

Apple has made the Mac experience much more web like. And that makes it easier to ship a Mac app as a web app.

Back in the day, Mac apps used to have a lot of rich behaviors that were best exposed by system frameworks. Stuff like sheets, utility panels and windows, rich customizable toolbars, etc. As those were all striped away, it provided less of a reason to use the system frameworks.

I think there is a decent argument that this maybe traces back to the iOS-ification of the Mac experience. Apple trying to unify the macOS UX with the iOS UX lead to a lot of those behaviors being stripped out, as they weren’t as easily implementable on an iPhone or iPad.


Also in case it wasn’t clear: Catalyst and iPhone apps on Mac are clearly not solutions to this problem, and may be exacerbating this problem. These frameworks should probably exist but the core Mac experience should not be built around them.

Alexander Griekspoor:

Yeah, unfortunately the calendar APIs are a good example where things have gone wrong with Apple loosing interest in devs and purely focusing on making the features ship before wwdc.. 😢 None of the stuff they added in recent years made it into the dev API.


Of course the big problem here is that if you can’t do more than what Apple has thought of for their Apps, you can’t expect to innovate beyond what’s there either. […]

Sadly, at first instance this might even lead to Apple believing that they are the only ones out there doing real innovation, not seeing that this and things like the sandbox simply curbs us developers. Ultimately it will simply mean a dead by a thousand cuts…

If even die-hard Apple devs like myself start to long back to the web world where your creative idea is just one upload away from anyone who can type a web address (just like it felt to make Mac apps for OSX in 2001), it should raise alarm bells, but I doubt it does in Cupertino.

Update (2022-02-11): Orta Therox:

I love the care & attention in solid native apps but on the Mac I only use ~4 3rd party apps now.

As the Mac becomes more iOS-y, x-plat apps have made regularly switching between Linux easier.

It’s a trade of polish/convenience for long-term value alignment.

Which is a shame because I have the strongest value alignment with the sorts of folks who make native apps, and I’m very happy to pay for good software.

Yet they don’t have much say in how the OS and ecosystem shift, and everyone has to adapt in their own ways.

Jeff Johnson:

One reason why people “live in the browser” is that Apple has totally undermined the native Mac software ecosystem. The crap store race to the bottom. Gatekeeper. Notarization. Catalina Vista TCC, implementing what Apple parodied in “Get a Mac”.

Look at the flaming hoops you have to jump through just to install Audio Hijack on M1 Macs. It’s absurd!

No wonder people live in the browser. Apple doesn’t let you live anywhere else.


Wordle Clones

John Gruber:

Apple’s App Store is lousy with Wordle rip-offs. I mean not just the concept — there’s a long history of “guess the word” games, including a defunct game show called “Lingo” that was clearly an inspiration for Wordle — but literally the name “Wordle” and its design. As observed by Greg Karber, as I write this, the #3, #7, #14, and #15 word games in the iOS App Store are shameless Wordle clones stealing the name “Wordle”.


And then we get to the real gem of the bunch. “Wordle - The App”, by Zach Shakked, a free-to-download app with a 30-fucking-dollar-per-year “Pro” unlock. Shakked’s rip-off doesn’t just steal Wordle’s name, design, and mechanics, its “The App” suffix clearly was chosen to make it look like the official App Store version of Wardle’s original.

Apple removed the ones using the “Wordle” name last night.


Update (2022-01-24): John Gruber:

Some good rules of thumb, if you’re weighing whether a derivative new work crosses the threshold into ripping off the original: If the derivative steals the original’s title or name, that’s a rip-off. If the derivative is designed to confuse people into thinking it is the original — as Shakked’s Wordle clone clearly did — that’s a rip-off. If the derivative is indistinguishable from the original or brings nothing new to the table, it’s probably a rip-off.


When last week’s controversy erupted, I watched some footage of Lingo, and rolled my eyes at the “Wordle is just a rip-off of Lingo” allegations. Yes, both games are about guessing five-letter words. But a game show where you compete against other contestants and against a clock “smells” quite different from Wordle’s solo gameplay and leisurely “take as much time as you want” pace.

Turns out Lingo isn’t just a TV game show, though. It’s an officially-licensed video game — in both the App Store and Play Store. David Barnard was the first person I saw who pointed to the official Lingo game, tweeting thus[…]

Update (2022-03-07): Chaim Gartenberg:

The Wordle clones are back on the App Store, just a few weeks after Apple wiped out nearly all the copycat games in January.


None of the new games are actively passing themselves off as Wordle — at least, not in name. Instead, the clones have creatively rebranded to “Wordus,” “Word Guess,” “Wordl,” and other thinly veiled references to the original game. But all of them offer some variant on Wordle’s gameplay, down to the same gameplay, UI, design, and color scheme.