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?

Featured Content Ads

add advertising here

Join Bing with ChatGPT-4

Use the new internet where you get what you ask, Fast and precise using AI.

https://www.bing.com

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.

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

Catalyst (Marzipan) Cocoa Electron Mac Mac App Store macOS 12 Monterey Notarization Sandboxing SwiftUI Transparency Consent and Control (TCC) Web

Stay up-to-date by subscribing to the Comments RSS Feed for this post.