111–120 of 216 posts
If you like SwiftUI, I challenge you to a SwiftUI fizzbuzz: a square, screen width, 10x padding, red background. inside it, a little square, centered and a little square, top left corner, 10px padding, blue background for both. Tell me that was easy, so that I know you're lying :)
Context: I’ve been working with iOS full time since a few years before Swift came out. A few startups ago we built our app using SwiftUI 1.0. At that time, while 90% of it was fantastic, 10% was either unworkable or extremely unreliable, causing for some maddening bugs. The documentation was laughable so for these reasons I chose to do the app for a subsequent startup in UIKit. Fast forward to my most recent company;…
Earlier quoted context omitted.
There are official escape hatches in SwiftUI to let you leverage UIKit. As someone actively working on a slow migration from UIKit to SwiftUI (where possible), it doesn't feel discouraging to wrap a UIKit view to use it in SwiftUI if necessary.
That’s more of a compatibility solution than an escape hatch. An official SwiftUI escape hatch should have access to the underlying imperative object, call methods on it, etc… Unfortunately the underlying ‘things’ in SwiftUI is implementation detail, inspecting the view hierarchy and finding the UIViews that implement a SwiftUI view is a hack.
The whole programming experience of declarative UIs is predicated on the fact that you’re manipulating lightweight structs (really just state representations) that are rendered into heavyweight views by the system only where necessary (determined by diffing the state changes).
React’s refs are an attempted answer to this very problem, and they get nasty fast.
Earlier quoted context omitted.
Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underlying platform's abstractions instead of trying to superimpose a new leaky abstraction on top of them. I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfo…
I apologize to the people who bought into this pattern but what was anyone thinking? Just reading through how it was supposed to be done set off so many red flags I never even considered it. There is so much useless abstraction it makes no sense.
Context: I’ve been working with iOS full time since a few years before Swift came out. A few startups ago we built our app using SwiftUI 1.0. At that time, while 90% of it was fantastic, 10% was either unworkable or extremely unreliable, causing for some maddening bugs. The documentation was laughable so for these reasons I chose to do the app for a subsequent startup in UIKit. Fast forward to my most recent company;…
The problem with SwiftUI is what Apple seems to consider its advantage: that it hides complexity from the developer (see their “Avocado toast maker” analogy in one of the WWDCs). The reason this is a problem is because sometimes you do need to break out of the paradigm, and doing so is basically always painful. At least with UIKit and AppKit you are always in full control. Complex apps will break out of the SwiftUI b…
If you like SwiftUI, I challenge you to a SwiftUI fizzbuzz: a square, screen width, 10x padding, red background. inside it, a little square, centered and a little square, top left corner, 10px padding, blue background for both. Tell me that was easy, so that I know you're lying :)
Took me 5 minutes. Copy and paste this into a playground: https://gist.github.com/maxhumber/1dbdf0d9c4539a8e145b3c630c...
Earlier quoted context omitted.
Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underlying platform's abstractions instead of trying to superimpose a new leaky abstraction on top of them. I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfo…
Could be worse, they could have adopted RIBs https://github.com/uber/RIBs
Earlier quoted context omitted.
Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underlying platform's abstractions instead of trying to superimpose a new leaky abstraction on top of them. I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfo…
> the VIPER architecture