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 threadMichael Tsai

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

Oct 28, 2024 at 7:07pmWeb
Show threadChris HansonOct 28, 2024
What was last year’s bug, and what’s this year’s? Sounds like an API with incorrect availability markup?
Show threadMichael TsaiOct 28, 2024
@eschaton No, they were linker issues. Last year there were several, including FB13097713, https://github.com/swiftlang/swift/issues/68163, and a SwiftUI asset symbols one that may still exist. This year, the bug is FB14667312, which is not yet mentioned in any Xcode release notes, but oddly I just saw that the *macOS* 15.1 release notes say is fixed. Fingers crossed.
Regression: Xcode 15 cannot build correctly for macOS versions older than 10.15 · Issue #68163 · swiftlang/swift

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

GitHub