3 ms·

You'll definitely have a much more pleasant time following conventions – which arguably provides the best user experience. But for those times when you just rea

by gdubs 3y ago

You'll definitely have a much more pleasant time following conventions – which arguably provides the best user experience. But for those times when you just really have to have something non-conventional, I've found that the UIViewRepresentable fallback works well. Just easier in those circumstances to not try and mix the two approaches, but separate them. Example in a recent app was it was easier for me to use a UIScrollView for the image panning and zooming functionality it offers. Simple matter of wrapping that one element in the Representable. Generally, for me it's been a ginormous productivity booster. I can rip apart and re-design a SwiftUI app and it doesn't break. That was always a lot more of a challenge with pre-SwiftUI apps.

ChrisMarshallNY 3y ago
It's not just non-conventional UI. For example, I wrote a dashboard app for the social app we wrote. Part of it, is a map, displaying the geographic distribution of users. It needed to be affected in a number of ways, and SwiftUI completely fell down. I spent over a week, trying all kinds of crazy stuff, and then gave up, and coded up the map screen in about four hours, with UIKit. Since this is a central feature of the dashboard, it meant that I had to also toss the previous week's SwiftUI work, and start from scratch with UIKit. I'm not very happy with UIViewRepresentable, and I eagerly await native SwiftUI API elements.
- fingerlocks 3y ago
  I’ve wrapped MapKit in a UIViewRepresentable without any problem, what was your specific issue? UIKit and SwiftUI are both built on top of CALayers, SwiftUI is just way more opinionated. Once you grasp this the difference between the two APIs feels superficial, like a mere style preference.
  - ChrisMarshallNY 3y ago
    It's a long story, and not one I feel like rehashing. Not a big deal. I basically like the philosophy of SwiftUI, and want it to work, but I feel as if it still has quite a ways to go, before it is ready for the kind of stuff I do. The documentation, in particular, is pretty ... sparse. That's a cardinal sin, if you are publishing a framework (I've written frameworks, and spent a huge amount of time on documentation). I'm quite aware of the enormity of the task at hand. I sometimes wonder if the folks that started on that path really understood what they were getting themselves into. It's a real rabbithole. I really dislike AutoLayout, but I've also gotten quite good at it. UIKit/AppKit with AutoLayout can do just about anything.

by gdubs 3y ago

ChrisMarshallNY 3y ago

It's not just non-conventional UI. For example, I wrote a dashboard app for the social app we wrote. Part of it, is a map, displaying the geographic distribution of users. It needed to be affected in a number of ways, and SwiftUI completely fell down. I spent over a week, trying all kinds of crazy stuff, and then gave up, and coded up the map screen in about four hours, with UIKit. Since this is a central feature of the dashboard, it meant that I had to also toss the previous week's SwiftUI work, and start from scratch with UIKit. I'm not very happy with UIViewRepresentable, and I eagerly await native SwiftUI API elements.

fingerlocks 3y ago
I’ve wrapped MapKit in a UIViewRepresentable without any problem, what was your specific issue? UIKit and SwiftUI are both built on top of CALayers, SwiftUI is just way more opinionated. Once you grasp this the difference between the two APIs feels superficial, like a mere style preference.
- ChrisMarshallNY 3y ago
  It's a long story, and not one I feel like rehashing. Not a big deal. I basically like the philosophy of SwiftUI, and want it to work, but I feel as if it still has quite a ways to go, before it is ready for the kind of stuff I do. The documentation, in particular, is pretty ... sparse. That's a cardinal sin, if you are publishing a framework (I've written frameworks, and spent a huge amount of time on documentation). I'm quite aware of the enormity of the task at hand. I sometimes wonder if the folks that started on that path really understood what they were getting themselves into. It's a real rabbithole. I really dislike AutoLayout, but I've also gotten quite good at it. UIKit/AppKit with AutoLayout can do just about anything.