Dave DeLongOct 27, 2024

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?

Show threadpatzearfossOct 27, 2024
@davedelong I feel like Three20 was or could have been that.
Show threadChris HansonOct 27, 2024
@patzearfoss @davedelong Three20 definitely tried to be that, there have been tons of attempts at filling that exact role. One of the latest attempts seems to be Swift Composable Architecture.
Show threadpatzearfossOct 27, 2024
@eschaton @davedelong makes you wonder why there’s not much staying power.
Show threadChris HansonOct 27, 2024

@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.

Show threadChris HansonOct 27, 2024
@patzearfoss @davedelong That’s one of the biggest problems with using third party developer tools; they always lag the platform, which causes apps that use them to lag the platform too, which can further hold back platform evolution.
Show threadHelge HeßOct 27, 2024
@eschaton @patzearfoss @davedelong Not sure, that seems to put the blame on the 3rd party dev tools "being behind", when it's the specific platform vendor which causes that. 3rd party tools can be as successful as the 1st party one if given the same disclosure.
Java is a somewhat good example for that with a diverse dev tools ecosystem, including completely different languages.
Show threadChris HansonOct 27, 2024

@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.

Show threadChris HansonOct 27, 2024
@helge @patzearfoss @davedelong So in a sense it does put the blame on the third parties, but they (and the developers using them) need to fully understand the reality of the constraints under which they’re operating: A platform vendor needs the flexibility to evolve their platform. In exchange, the platform vendor preserves customer binary compatibility, including for software made using third party tools that adhere to the rules/documentation.
Show threadHelge HeßOct 27, 2024
@eschaton @patzearfoss @davedelong Generally I would say I agree, but the reality is that this is only true for a single vendor: Apple.
All the other major platform vendors focus on backwards compatibility.
(yes, I understand that Apple makes more money :-) )
Show threadChris HansonOct 27, 2024
@helge @patzearfoss @davedelong Apple focuses extensively on backward compatibility. For something like 10 years after it shipped, you could still target Mac OS X 10.6 with an x86_64 application, and use newer features on newer OSes. As someone who worked on the platform and tools directly for two decades, I find the “Apple doesn’t focus on backwards compatibility” meme rather offensive, honestly. Where’s the idea come from?
Show threadJeff Watkins
@eschaton @helge @patzearfoss @davedelong AMEN! I added a few specific checks for apps into GameKit back in the distant mists of time to ensure backward compatibility.
Oct 28, 2024 at 10:06amIvory for iOS
Show threadDave DeLongOct 28, 2024

@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

Show threadJeff WatkinsOct 28, 2024
@davedelong @eschaton @helge @patzearfoss Swift has become a particular nightmare for this. I’d be willing to bet any one of my old pure Obj-C projects would build and run just fine.
Show threadDave DeLongOct 28, 2024

@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.