{"id":49154,"date":"2025-09-04T15:15:22","date_gmt":"2025-09-04T19:15:22","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=49154"},"modified":"2025-09-04T15:15:22","modified_gmt":"2025-09-04T19:15:22","slug":"writing-mac-and-ios-apps-shouldnt-be-so-difficult","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/09\/04\/writing-mac-and-ios-apps-shouldnt-be-so-difficult\/","title":{"rendered":"Writing Mac and iOS Apps Shouldn’t Be So Difficult"},"content":{"rendered":"

Brent Simmons<\/a> (Mastodon<\/a>):<\/p>\n

\n

A scripting language plus key bits implemented in C was more than fast enough for an app. Even all those years ago.<\/p>\n

[…]<\/p>\n

I’m not writing this article to praise Frontier — I’m talking about it to make a point, which I’ll get to.<\/p>\n\n

But I wanted to bring up a second aspect to this: it’s not just frictionless iteration that was so great, it was also the scripting language and environment.<\/p>\n

[…]<\/p>\n

I’m not saying apps these days need to be Frontier-like in any details. But it seems absolutely bizarre to me that we — we who write Mac and iOS apps — still have to build and run the app, make changes, build and run the app, and so on, all day long. In the year 2025.<\/p>\n<\/blockquote>\n\n

I was just listening to a Larry Tesler interview<\/a> where he talks about live editing the Xerox Alto’s Smalltalk code in the middle of a demo to Steve Jobs. This was in 1979.<\/p>\n\n

And it seems retro in the worst way that we’re still using anything other than a scripting language for most of our code. We should be using something simple and light that can configure toolbars, handle networking callbacks, query databases, manage views, and so on. And maybe with a DSL for SwiftUI-like declarative UI.<\/p>

[…]<\/p>

And at some point I suspect these things are going to be table stakes for any platform that wants to attract developers. If you were a new developer right now, would you pick Xcode’s build-and-run, edit, build-and-run, edit — plus the growing complexity of Swift — over something like Electron and JavaScript?<\/p><\/blockquote>\n\n

Manton Reece<\/a>:<\/p>\n

\n

I also used Frontier a lot<\/em> during that time. It was great. Personally, instead of Swift, I would’ve loved to see RubyCocoa taken to the next level.<\/p>\n<\/blockquote>\n\n

Frontier was great, and I was excited about Apple’s initial embrace of PyObjC, RubyCocoa, and other bridges, but they’ve now gone completely in the other direction<\/a>. AppleScriptObjC is still there, but it doesn’t work with the newer Swift-based APIs, and the initial hopes that Swift would lead to a successor scripting language seem to have completely evaporated.<\/p>\n\n

Kyle Howells<\/a>:<\/p>\n

\n

This idea, a higher level, live reloading, scripting language built on top a compiled, fast core language you can drop down to when needed was my hope when Apple released Swift.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n