Writing Mac and iOS Apps Shouldn’t Be So Difficult
A scripting language plus key bits implemented in C was more than fast enough for an app. Even all those years ago.
[…]
I’m not writing this article to praise Frontier — I’m talking about it to make a point, which I’ll get to.
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.
[…]
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.
I was just listening to a Larry Tesler interview 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.
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.
[…]
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?
I also used Frontier a lot during that time. It was great. Personally, instead of Swift, I would’ve loved to see RubyCocoa taken to the next level.
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. 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.
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.
Previously:
- The Automation Gap
- Is Electron Really That Bad?
- Swift at 10
- Larry Tesler, RIP
- Scripting Languages to Be Removed
- 30 Years of Frontier
- Frontier Diary #1
17 Comments RSS · Twitter · Mastodon
> 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.
Honestly using the currently existing things, we can have a very very very nice bridge.
First is the setup: https://github.com/Frizlab/apple-music-to-slack/blob/90964bbef3e61d7874fdcdf47fcd8761ba817b4c/Sources/ScriptingBridge/%20Readme.md
Then you can use the Music app like any Swift object, even with type-safe enums. Example for instance here: https://github.com/Frizlab/apple-music-to-slack/blob/90964bbef3e61d7874fdcdf47fcd8761ba817b4c/Sources/CurrentTrackInfo.swift#L34
This is not very well known, but it is incredibly good to use.
@Frizlab That’s cool, but I was referring to the opposite case, where you can’t call Swift API from AppleScript.
Oh! Sorry, I misread.
But also I really don’t mind that’s not possible, IMHO writing AppleScript apps is and always was a terrible experience.
And on the opposite side, writing a Swift app is excessively easy now. That in addition to the seamless bridge to the AppleScript world, I really see no point in writing an AppleScript app.
@Frizlab The point is not to write an AppleScript app but to be able to write a script that has access to all the APIs.
But… why?
Personally I even write my scripts in Swift now (using to have third-party imports possible). I really don’t see the point of writing more than one-liners in AppleScript.
PyObjC and RubyCocoa are products of an era when Apple needed to court developers. When standards like OpenGL and Unix compatibility were key marketing points.
Since then, Apple pursued (and achieved) platform lock-in and lockdown. Now Apple won't push anything unless it furthers their lock-in or proprietary push (like pushing Metal over Vulcan).
The "frictionless iteration" we want won't come from Apple. Even /if/ Apple ever achieves frictionless *app dev* (and it isn't a buggy pos), "friction" is how Apple enacts control and enforces their Toll Booths: Apple is not removing the developer friction of Notarization, App Review, the Yearly Developer Fee, or iOS app installs only through the App Store.
Wight and Howells echo a lot of my sentiments: Swift impedes app dev with its relentless complexity. It's unsalvageable. Almost no one uses Swift unless they have to or are okay with Apple lock-in. I don't think Swift's cracked the top 20 on TIOBE in a decade. Compare that to Golang which focuses more on simplicity and mogs Swift in terms of devs choosing it and notable projects made with it.
Absent a mass developer exodus, iOS marketshare collapse, profitability collapse, or court breakup of the company, I don't think Apple will care about developer experience again.
The hot-reloading tools provided by the Injection series of programs are quite useful , if a little cumbersome to get set up with. InjectionIII has greatly increased my ability to work on SwiftUI apps that have outgrown Xcode Previews.
Frictionless interaction?!?!? At Userland, all friction came from DW, he is a professional troll. Frontier failed because of his own arrogance, regardless of any qualities of the software itself.
When the rumors were running wild about a new Apple language, I was convinced it’d be some high-level scripting language that would make App development super easy. I was very surprised to see them go the complete opposite direction with Swift.
It makes some sense – Chris Lattner behind it, binary compatibility with Objective C objects, ability to use the same language everywhere (kernel development, embedded environments, all the way to apps). Who knows what might have been.
I often think of that Larry Tessler demo too.
@Frizlab Because I’m already writing in AppleScript to be able to control/automate other apps. It’s often handy to be able to call system APIs in the course of doing that. If I were to write my whole script in Swift it would be much worse at the main part of calling those apps’ AppleScript APIs.
> 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.
I'm an Umbraco CMS developer, which is probably a very unfamiliar thing to the crowd on this site given that it's built on C# and .NET and built in Denmark. I'm one of 16 certified master developers in the US, and I've done heavy customizations on the platform.
The way they've built the backoffice to be extensible is something of Scandinavian beauty, and something Apple needs to copy for constructing AppKit apps. The current MacOS and iOS paradigms are stuck in the 1980s RAD drag-n-drop era, with SwiftUI trying to change that by copying react, but even that feels dated after what I've seen with the new Umbraco backoffice architecture.
They've got a bunch of pre-defined components. You extend them. You register them in a manifest file and use conditions to make your extended components appear when you need them to., Ex: `alias: "Umb.Condition.SectionAlias", match: "Umb.Section.Settings"`. (I'm on the community team actively working on rewriting the documentation - mind the construction: https://docs.umbraco.com/umbraco-cms/customizing/extending-overview/extension-types/dashboard#full-example)
It's not hard to imagine a world with: `alias: "AppKit.Condition.SectionAlias", match: "AppKit.MainWindow.Toolbar".
It wouldn't work for all apps, but it would cover a helluva lot of ground for the things it would work for, modernize the development experience and allow developers to focus more on the core problem domain of their product instead of providing toolbar delegates and positioning things ever so and auto layout and ....
The app was implemented in two pieces:
- The kernel, written in C, implemented the database, networking, inter-application communication, various built-in data types, script compiler and evaluator and debugger, and so on
- The scripts used the kernel and implemented most of the actual app behavior
--
Basically videogame architecture: super fast low level code, using scripts for behavior/UI.
I wonder how will iOS/macOS devs will feel if they use modern Delphi. I’m not saying switch to Delphi, but I just wanna see how they feel.
Jack Rusher gave nice a talk about how sick edit/compile/run a.k.a. batch programming is:
"Stop Writing Dead Programs" https://jackrusher.com/strange-loop-2022/
I found Bjorn Stahl‘s Arcan the perfect example of low level speed in C and high level script ability with Lua. Protocol, display server, TUI, GUI, ZUI and more. I don’t pretend to possess the knowledge to actually comprehend it. But found it very neat.
