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 Any abstraction you build must contend with Apple adding new developer APIs and interactions and design rules every year. A ton of your time is spent on rearchitecting and rewriting things to support the new shiny, which is time not spent on improving the abstraction.
Consider game engines, they thrive on mobile with multiple offerings, some paid, some open source. They don't really have to contend with Apple's shifting priorities, so they can innovate.
@stevestreza @davedelong @nicklockwood 🎯
Even abstractions that have huge budgets behind them like Flutter struggle to keep up and frequently have bugs leak through the abstraction.
@davedelong There are a few boilerplates for iOS popping up in the last year or so, like https://swiftship.dev/
I believe this is the closest that we have today.
@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.
@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…
@patzearfoss @davedelong I think a big part of it is that these architectures are often created by people with very specific opinions of what an application’s architecture should be but are not the platform vendor, so they have no visibility into the platform vendor’s future plans.
You then wind up in the situation where the architecture lags the platform and the platform vendor resents the architecture holding developers back from new feature adoption.
@helge @patzearfoss @davedelong It’s said with the complete understanding that the platform vendor will never provide third parties with the level of disclosure they would need to be at parity when new platform versions are introduced.
The platforms and their tools aren’t and shouldn’t be separate: There’s substantial dialogue between them throughout development to provide an integrated experience. Third party participation in that would effectively make them first parties.
@helge @patzearfoss @davedelong Swift has had an enormous amount of work to do, and even so it’s still possible to target substantially earlier releases (around macOS 10.15, from 5 years ago) using much more recent Xcode releases.
The popular statement of the meme isn’t about not being able to write Swift 6 that targets Snow Leopard, it’s about being (remaining) mad that Apple dropped the boat anchor that was 32-bit Intel nearly 10 years after shipping 64-bit Intel.
@jeffwatkins @eschaton @helge @patzearfoss Apple for sure spends enormous amounts of effort in maintaining *binary* compatibility. But there are other kinds too. And it's very very common that a simple Xcode/SDK upgrade will radically change OS framework (esp SwiftUI) behavior and require bizarre and opaque workarounds in order to maintain *deployment* compatibility and latest OS compatibility.
So it has become a trope that, despite bincompat, Apple doesn’t care about *source* compatibility
@jeffwatkins @eschaton @helge @patzearfoss The language is a factor, yes. But part of it are the frameworks themselves that blindly assumes that just because a new SDK has been linked that the developer has therefore *chosen* and consciously agreed to opt-in to all the new behavior.
This has gotten especially bad over the past 5 years.
@eschaton @helge @patzearfoss @davedelong I’m not sure how many people cared about 32-bit Intel per-se vs. dropping the promised migration path from it (64-bit Carbon).
To me, it’s mostly in the Swift era. For example, for two years in a row, Apple has shipped broken Xcodes that build Mac apps that crash when deployed on older (in this case, Big Sur, so not that old) versions of macOS. In both cases, the bugs were reported in the summer. Last year, fixed December 13. This year, unfixed so far.
Description According to the documentation, Xcode is supposed to be able to build for macOS 10.13 and up. However, this does not seem to be the case in practice; my testers on 10.14.6 have reported...
Chicago-based mobile app development startup Red Foundry has raised $1.1 million in Series A funding from OCA Ventures and I2A Fund. Red Foundry, which is in private beta, develops a SaaS that allows users with limited technology experience to create and manage iOS apps. We have 200 invites for TechCrunch readers with the code "TechCrunch" here. Red Foundry's software allows users to create professional-looking iPhone and iPad apps that include menus, RSS feeds, images, videos, maps and more. Apps have built in sharing options like Twitter, Facebook, email, and comments and include a built-in storage and delivery solution.
Dave DeLong
Kyle Hughes
Tom Harrington
Steve Streza
Jonathan Joelson
Bruno Delgado 
Chris Hanson
Eric Vitiello
Michael B. Johnson
patzearfoss
Helge Heß
Jeff Watkins
Michael Tsai
Brian
Maximilian Mackh
Christian Beer
Daniel Kasaj