Hacker News new | ask | show | jobs
by manmal 1620 days ago
It’s possible (and IMO enjoyable) to write UIKit apps with ComposableArchitecture, a purely value-typed approach. I’ve also mostly used MVVM with UIKit since 2015, and found my apps to be stabler and easier to maintain than standard MVC apps.

In projects I lead I’ve been discouraging inheritance because I’ve found it highly detrimental to maintainability. “Base” classes invite bloat and overgeneralization, especially with inexperienced devs.

1 comments

Isn't TCA a dependency framework?

I haven't found much joy in MVVM. I haven't found that it provides enough benefits to spend the time switching over.

I am looking forward to SwiftUI. I really hope that the documentation improves, though.

> Isn't TCA a dependency framework?

It is but it's quite straightforward to build your own simpler version using only Combine - that's what we're doing at the moment and it tends to work very well, interacting with Core Data has been kind of clunky though.

> I am looking forward to SwiftUI. I really hope that the documentation improves, though.

I've been on a project using it for the last 8 months both for macOS and iOS, I would honestly not rush into using it anytime soon. It's improved significantly since release, especially if you can target the newest iOS but requiring that is a hard-sell for most. On the Mac it's a different story and is much more neglected, macOS versions also tend to have far longer tails than iOS so it's a non-starter to try and sell a Monterey-only Mac app.

Edit: rereading my comment it sounds like I'm really down on SwiftUI - which I'm not, I think it's great when it works but there's a lot of rough edges at the moment and also quite a lot of hype.

If you are using TCA only for dependency management, I’d suggest to reconsider and put all business logic in it. In my experience, most serious efforts of wrangling SwiftUI into a complex app wind up with a solution that’s similar to TCA.
Ah! We're putting all our business logic in it, I guess I misunderstood what OP was asking and assumed they meant something else, that's why I mentioned we built our own version of it internally.
Nah. I meant that it is a library, that needs to be included as a dependency.

That's a nonstarter, for me. I'm pretty picky about dependencies. If I use external ones, I like them to be something that can be encapsulated/injected, as opposed to being totally interwoven.

But I'm not trying to make money, I just want to write really good apps.

I share your sentiment, and try to avoid dependencies like the pest. But, I wouldn't write my own crypto library, and TCA falls into a similar category - it's a really good solution for a hard problem. Those guys invest a big part of their time into just those few hundred lines of code. There's word that even Apple uses their stuff internally.
TCA is a Redux/Elm-style data and state management lib that aspires to handle an app’s complete business logic, preventing devs from mixing the logic into the UI layer via SwiftUI’s @State and @StateObject. And contrary to Redux, it’s completely type safe and aware of deep component nesting (sub reducer states and actions are “pulled back” into their parent reducer pendants), so it allows truly composable components.

If you haven’t checked out PointFree’s content (authors of TCA among many other things), it’s one of the best resources on Swift and algorithms for sure.

Thanks, both of you, for the explanations.