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 Hanson
@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.
Oct 27, 2024 at 11:10pmIceCubesApp
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 threadHelge HeßOct 27, 2024
@eschaton @patzearfoss @davedelong From Swift? I totally agree that this is true for Objective-C.
Show threadChris HansonOct 28, 2024

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

Show threadHelge HeßOct 28, 2024
@eschaton Yes, that's not the meme I'm after. Being able to target only 5 years back doesn't suggest any stability to me, but the exact contrary. Meanwhile you can still do Win32, all COM, Java, Python 2( ;-) ) what-not, etc.
It's a Swift era issue (not limited to the language itself, it spreads heavily into the frameworks like SwiftUI).
I used IJSVG w/ manual ref counting on a modern system and that just worked. So yes, if I hurt feelings, I do think that the (ObjC) base system *is* stable.
Show threadJeff WatkinsOct 28, 2024
@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.
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.

Show threadMichael TsaiOct 28, 2024

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

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
Show threadBrianOct 28, 2024
@eschaton @helge @patzearfoss @davedelong To build for Monterey successfully required a specific version of Xcode 14 because of changes in Swift and the tool chain. That’s a lot less than 10 years.