3 ms·

I built my first iOS app in 2010. Today, it's fantastically easier to get started. A night and day comparison. My biggest piece of advice: pick something you're

by gdubs 3y ago

I built my first iOS app in 2010. Today, it's fantastically easier to get started. A night and day comparison. My biggest piece of advice: pick something you're interested in, build it, see how it comes out, and then do it again. You'll learn way more with a project you're interested in to motivate you.

ChrisMarshallNY 3y ago
The only issue that I've had with SwiftUI -and it's a showstopper- is that SwiftUI makes writing fairly basic apps insanely easy, but really has problems, when I try to veer off the beaten path (which describes pretty much every single one of my projects). Apple has always enabled staying in their desired UI and workflow, but I've usually been able to find a way to coerce the system to do what I need. That appears to not be the case, with SwiftUI. You need to follow The Rules. Workarounds are crazy complex. But I love working in Swift. It's just that I ship [UI|App|Watch]Kit.
- 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

The only issue that I've had with SwiftUI -and it's a showstopper- is that SwiftUI makes writing fairly basic apps insanely easy, but really has problems, when I try to veer off the beaten path (which describes pretty much every single one of my projects). Apple has always enabled staying in their desired UI and workflow, but I've usually been able to find a way to coerce the system to do what I need. That appears to not be the case, with SwiftUI. You need to follow The Rules. Workarounds are crazy complex. But I love working in Swift. It's just that I ship [UI|App|Watch]Kit.

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.