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.
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.
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.
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.
Uggh electron. I’m now getting bug reports for my Mac app that the keybindings don’t work like windows.
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.
Previously:
- Music.app and TV.app Use JET in macOS 12.2 Beta
- The Persistent Gravity of Cross Platform
- Apple Execs on the Mac App Store
- 10th Anniversary of the Mac App Store
- Sketch on Native Mac Apps
- Catalyst and Cohesion
- Desktop Apps Post-Catalyst
- Scripting Languages to Be Removed
- Mojave’s rsync From the Days of Tiger
- Is There Hope for the Mac App Store?
- Electron and the Decline of Native Apps
- Apple Removes Apps From Their Affiliate Program
- An Aging Collection of Unix Tools
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
My 2¢:
- Documentation: Apple’s is the worst of any platform I use.
- Bugs: fix ’em. Also, the secret bug tracker is stupid.
- @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.
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.
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.
Previously:
