4 ms·

>After repeated deliberation, I had to make a tough decision: abandon the thousands of lines of SwiftData code I had completed and return to Core Data. The sam

>After repeated deliberation, I had to make a tough decision: abandon the thousands of lines of SwiftData code I had completed and return to Core Data. The same story many experienced with SwiftUI vs UIKit. Apple has flubbed the move to declarative APIs hard. It's a scary experience committing to these APIs, because of the wild changes they experience, the performance issues, and the fact that they are borderline un-debuggable by the average mind compared to imperative APIs, so when you run into real trouble, you're often kind of just fucked. And it's not even like normal 1st party frameworks where the bug is virtually always in your code. With these, sometimes the bug really is Apple's. I wish these things didn't have "Swift" in the name, since their problems have nothing to do with the language as far as I can tell, and they make Swift look bad.

TheJoeMan 2y ago
You hit the nail on the head, but if SwiftUI screws up, I catch that pretty easily. I am too scared to try SwiftData because schema migration is entirely on Apple’s hands, and customer data loss is a bigger deal.
bartvk 2y ago
I don't know about SwiftData, but my experience with SwiftUI is great. I've put a EU-sized project into production and it wasn't a problem at all. In my experience, the trick is making small tested and working views, and combine these into fullly-fledged screens.
- cageface 2y ago
  What is an EU-sized project?
cageface 2y ago
SwiftUI’s problems are due to Swift in one respect. The way Swift’s type inference works plays very badly with SwiftUI view builders leading to very long compile times and many cases in which the compiler will just give up entirely and you’re left randomly commenting out bits of code. That this is the best the richest company in the world can do with the API to their most valuable product is quite astonishing.
- yen223 2y ago
  Sometimes I lament the fact that in Jetpack Compose, @Components don't return anything. They are all side-effecting functions, even though the view is supposed to be a function of the arguments. But then I hit a "Unable to infer complex types" error in SwiftUI, and think maybe the Google folks got it right after all.
  - cageface 2y ago
    I much prefer the Flutter approach. Everything is a widget. It can lead to more nesting but the tooling, compilation times, and performance are great.
  - pjmlp 2y ago
    Given the amount of performance rants bashing Compose, probably not quite.
    - kaba0 2y ago
      Are they even doing a release build?
jwells89 2y ago
Unfortunately debugging challenges aren't unique to SwiftUI. Having having your application code get buried underneath miles of framework magic in stack traces can also be experienced with Jetpack Compose.
- yen223 2y ago
  Jetpack Compose has the benefit of being mostly open source. I can always crack open a misbehaving TextField to see what's going on underneath. SwiftUI has the unfortunate combo of being closed-source, being platform-dependent, and being buggy in the most unusual ways. Which is a shame, because SwiftUI has a lot of good things going for it.
  - jwells89 2y ago
    That's a great point and I agree, but it'd be nice if it weren't necessary to pop the hood to debug garden variety issues. The simplicity of UIKit in that regard is hard to beat.
lachenmayer 2y ago
What's incredibly annoying is that a lot of the SwiftUI components are just wrappers around the equivalent UIKit components (eg. ScrollView/UIScrollView), but are missing a lot of the functionality of the underlying components. These should really be open source: it's such a waste of time to have to experimentally poke around to see how the SwiftUI components interact with their UIKit counterparts, when these should really just be straightforward wrappers. In many cases, the declarative APIs are just poorly thought out and/or clearly not "battle tested", and there is a lot of API churn in really crucial components which are also often not backported to older OS versions.
- myko 2y ago
  > These should really be open source: It's funny, when SwiftUI and Compose were coming out we waited a bit but jumped in as soon as we could. With Compose, our early versions required us to make builds of Android Studio on our own machines that supported it. But even then Compose felt more polished in a lot of ways - and if we ran into issues we could _see the code_ and make our own components with the changes we needed if necessary. SwiftUI is great, really, but has so many rough edges, gotchas, and bugs. They do get fixed, but you're still supporting 4 year old versions of iOS without those fixes, so you're screwed. Just completely boneheaded not to open source SwiftUI from the start, especially with how great the open source Swift community is.
- fingerlocks 2y ago
  Since it’s trivially easy to bridge a UI/NSView into SwiftUI, why don’t you do that? If you think of SwiftUI as a dumbed-down children’s toy box version of the grown-up’s tools, there’s nothing to complain about. It’s really better that way since UI/NSKit has so many footguns.
  - happytoexplain 2y ago
    This is only true for the very simple cases you might see in an example snippet. If you need a UIView because you need access to some kind of imperative action (which is usually why you need a UIView), there is no channel for that. Declarative vs imperative are fundamentally incompatible when in the same abstraction layer. You have to use the kind of hacks you used to only see in "bad" codebases, like notification broadcast instead of delegated function calling.
lenkite 2y ago
In the not-distant past, Apple had beautiful software (OS/lang/frameworks) and sucky hardware. In the present, Apple has beautiful hardware and sucky hardware. No idea when they will get both beautiful hardware AND software. (Frankly, I preferred good old, stable Objective-C - Apple ditched the KISS principle, when they adopted Swift).

TheJoeMan 2y ago

You hit the nail on the head, but if SwiftUI screws up, I catch that pretty easily. I am too scared to try SwiftData because schema migration is entirely on Apple’s hands, and customer data loss is a bigger deal.

bartvk 2y ago

I don't know about SwiftData, but my experience with SwiftUI is great. I've put a EU-sized project into production and it wasn't a problem at all. In my experience, the trick is making small tested and working views, and combine these into fullly-fledged screens.

cageface 2y ago
What is an EU-sized project?

cageface 2y ago

SwiftUI’s problems are due to Swift in one respect. The way Swift’s type inference works plays very badly with SwiftUI view builders leading to very long compile times and many cases in which the compiler will just give up entirely and you’re left randomly commenting out bits of code. That this is the best the richest company in the world can do with the API to their most valuable product is quite astonishing.

yen223 2y ago
Sometimes I lament the fact that in Jetpack Compose, @Components don't return anything. They are all side-effecting functions, even though the view is supposed to be a function of the arguments. But then I hit a "Unable to infer complex types" error in SwiftUI, and think maybe the Google folks got it right after all.
- cageface 2y ago
  I much prefer the Flutter approach. Everything is a widget. It can lead to more nesting but the tooling, compilation times, and performance are great.
- pjmlp 2y ago
  Given the amount of performance rants bashing Compose, probably not quite.
  - kaba0 2y ago
    Are they even doing a release build?

jwells89 2y ago

Unfortunately debugging challenges aren't unique to SwiftUI. Having having your application code get buried underneath miles of framework magic in stack traces can also be experienced with Jetpack Compose.

yen223 2y ago
Jetpack Compose has the benefit of being mostly open source. I can always crack open a misbehaving TextField to see what's going on underneath. SwiftUI has the unfortunate combo of being closed-source, being platform-dependent, and being buggy in the most unusual ways. Which is a shame, because SwiftUI has a lot of good things going for it.
- jwells89 2y ago
  That's a great point and I agree, but it'd be nice if it weren't necessary to pop the hood to debug garden variety issues. The simplicity of UIKit in that regard is hard to beat.

lachenmayer 2y ago

What's incredibly annoying is that a lot of the SwiftUI components are just wrappers around the equivalent UIKit components (eg. ScrollView/UIScrollView), but are missing a lot of the functionality of the underlying components. These should really be open source: it's such a waste of time to have to experimentally poke around to see how the SwiftUI components interact with their UIKit counterparts, when these should really just be straightforward wrappers. In many cases, the declarative APIs are just poorly thought out and/or clearly not "battle tested", and there is a lot of API churn in really crucial components which are also often not backported to older OS versions.

myko 2y ago
> These should really be open source: It's funny, when SwiftUI and Compose were coming out we waited a bit but jumped in as soon as we could. With Compose, our early versions required us to make builds of Android Studio on our own machines that supported it. But even then Compose felt more polished in a lot of ways - and if we ran into issues we could _see the code_ and make our own components with the changes we needed if necessary. SwiftUI is great, really, but has so many rough edges, gotchas, and bugs. They do get fixed, but you're still supporting 4 year old versions of iOS without those fixes, so you're screwed. Just completely boneheaded not to open source SwiftUI from the start, especially with how great the open source Swift community is.
fingerlocks 2y ago
Since it’s trivially easy to bridge a UI/NSView into SwiftUI, why don’t you do that? If you think of SwiftUI as a dumbed-down children’s toy box version of the grown-up’s tools, there’s nothing to complain about. It’s really better that way since UI/NSKit has so many footguns.
- happytoexplain 2y ago
  This is only true for the very simple cases you might see in an example snippet. If you need a UIView because you need access to some kind of imperative action (which is usually why you need a UIView), there is no channel for that. Declarative vs imperative are fundamentally incompatible when in the same abstraction layer. You have to use the kind of hacks you used to only see in "bad" codebases, like notification broadcast instead of delegated function calling.

lenkite 2y ago

In the not-distant past, Apple had beautiful software (OS/lang/frameworks) and sucky hardware. In the present, Apple has beautiful hardware and sucky hardware. No idea when they will get both beautiful hardware AND software. (Frankly, I preferred good old, stable Objective-C - Apple ditched the KISS principle, when they adopted Swift).