Was chatting with a friend today and was finally able to vocalize one of the big things that's been nibbling at my brain.

When it comes to building mobile apps, where is our equivalent of Wordpress or Shopify or Drupal? Why is it that every single app must start over from "Hello world" and build from there?

@davedelong The whole point of AppKit was to be that. Unfortunately, it went through a long period of aversion to adding both new API (especially classes) and more automatic functionality that thwarted this a bit.

For example, I argued NSViewController should be an NSResponder, which is how it shipped in Mac OS X 10.5. But it took several more major releases (e.g. lots of convincing) for it to *automatically* participate in the responder chain like NSView, NSWindow, and NSDocument.

@davedelong Similarly, AppKit still doesn’t have a native “command” or “selection” concept, only the responder chain. So any application that wants a higher-level concept of commands and typed selections still needs to implement that using the pieces AppKit provides. Heck, bindings & KVO were never _really_ finished, insofar as there are KVO observation options that are likely still not supported by the NSController hierarchy. Same with no support for a real preferences window (or concept).
@eschaton @davedelong I think what he's talking about is probably at least one level further up in the abstraction - something more like hypercard, filemaker, etc.
@pixel @davedelong I got the impression he was more talking about something like Three20 or Swift Composable Architecture that gives you something to slot the rest of your application into. Either way, it’s worth thinking about.

@eschaton @pixel I want even higher level than that. There was a big push over the years for "shoebox" apps like Music or Photos or even iMovie.

So … where was Shoebox.framework that gave you the core of that kind of app? With master-detail-inspector interfaces and a ready-to-go database layer where you could customize the kinds of things you wanted stored, etc.

@davedelong @pixel We had all the pieces necessary to do this with Core Data, predicates, and bindings (modulo incomplete KVO option support in the NSController hierarchy).

Another engineer and I always wanted to make something like DirectToWeb/DirectToJavaClient for Cocoa atop an NSPredicate-based rule engine so CRUD apps would “just” be a matter of modeling data & business rules. Such a thing could still be done today using SwiftData and SwiftUI, in some ways more easily…

@davedelong @pixel I even had the start of it in the original Core Data interface generation for Interface Builder: When you dropped an entity from the modeling tool on an Interface Builder document, IB used a static set of rules (written in ObjC) to create the corresponding view/controller objects and bindings which you could then tweak directly. Moving that into AppKit (say in an NSViewController) would’ve been a good next step, followed by “externalizing” the rules…
@davedelong @eschaton @pixel I did this at Pixar 20 years ago for a class of apps we wrote. You could drag and drop the whole thing together in IB.
See previously my phd thesis wavesworld