5 ms·

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, whi

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; decided to give SwiftUI another shot (targeting iOS 14 & SwiftUI 2). I am 100% glad we did. It’s been pretty incredible; we’ve built a reasonably complex banking app at a pace not possible with UIKit. The animations in particular are crazy good to work with; we’ve got some very complex animated flows that would have taken weeks and thousands of lines with UIKit… with SwiftUI it was about 5 days. It’s definitely not without its downsides; documentation is still slim at best, but there’s plenty of blogs and resources (https://swiftui-lab.com/ https://swiftui-lab.com/ is the most helpful IMO) available now. There are also still some maddening bugs that appear in production and take a day or two of head scratching only to discover it’s a bug in the framework (most recently; using #available causes code to crash on the platform it’s protecting against lol), but there are always workarounds. Still, time wasted on these has been vastly outweighed by the weeks / months of time saved. Finally, you can always use UIKit as an escape hatch through UIViewRepresentable. iOS 15 is at 85% adoption, so we plan to drop support for 14 somewhat soon, which will give us an even more robust framework as well as async await APIs. Not feasible for most companies I know, but even supporting 14+ Will be pretty reasonable when iOS 16 drops in September.

emehex 4y ago
I'm targeting iOS 14+ for most projects and planning to drop when iOS 16 drops as well. Thankfully async/await was back-ported to iOS 13 (can't live without it!)
- aplummer 4y ago
  What kind of work are you doing with async/await that is so improved? Very interested in what kind of code on the client that is.
  - tarentel 4y ago
    Same. I toyed with a bit for a networking stack but outside of that I haven't found anything super useful. I never went into production with it, the code I re-wrote was definitely cleaner but it wasn't really mind blowingly better that I felt the need to pursue it further.
  - cvwright 4y ago
    I'm not the OP, but I'm updating my iOS app now to use async/await instead of callback hell for all of its networking code. It is much, much nicer. I also recently did some work with Vapor on the server side. Night and day difference there. The old Vapor EventLoop stuff was doable, if you squinted just right and concentrated really hard. The async/await version is as delightful as anything else I've ever used. Nearly as easy as writing Python.
    - aplummer 4y ago
      This is what I was expecting. I think for Vapor for example it's incredible because you are always in async land. For client code, because you are returning to the main thread quite a lot - I'm not seeing so many benefits.
anonymouse008 4y ago
Do you mind explaining exactly what animations would take that much work? I’m struggling to see how animations could ever take as long as estimated for UIKit
- ketzo 4y ago
  The parent said “animated flows” and mentioned a banking app, so I’m betting a multi-page form with lots of transitions between a lot of different state combinations. Again, just guessing, but I would imagine that it’s managing that state and animating it in a sane way which requires LOTS of code, less so the animations themselves.
- joshuawright11 4y ago
  Here's a part of the flow I'm talking about; for context it's a debit card that rewards users with stock as they use it. The entire flow is SwiftUI (though the top of the pack ripping is PNG sequences so we did cheat a bit). https://streamable.com/56pha0 https://streamable.com/56pha0 (shameless plug; check us out at https://www.withapollo.com https://www.withapollo.com we're YCS21, just launched last week, and are hiring an iOS engineer!)
  - anonymouse008 4y ago
    Ok, wow, yeah impressive! [Edit]: Thank you kind stranger.
    - dean177 4y ago
      > though the top of the pack ripping is PNG sequences so we did cheat a bit
- NonNefarious 4y ago
  How about explaining why you have a bunch of animations in a UI to begin with? Animations are so often an ill-advised, interaction-slowing pain in the ass for users that I'm curious about beneficial and non-annoying use cases.

emehex 4y ago

I'm targeting iOS 14+ for most projects and planning to drop when iOS 16 drops as well. Thankfully async/await was back-ported to iOS 13 (can't live without it!)

aplummer 4y ago
What kind of work are you doing with async/await that is so improved? Very interested in what kind of code on the client that is.
- tarentel 4y ago
  Same. I toyed with a bit for a networking stack but outside of that I haven't found anything super useful. I never went into production with it, the code I re-wrote was definitely cleaner but it wasn't really mind blowingly better that I felt the need to pursue it further.
- cvwright 4y ago
  I'm not the OP, but I'm updating my iOS app now to use async/await instead of callback hell for all of its networking code. It is much, much nicer. I also recently did some work with Vapor on the server side. Night and day difference there. The old Vapor EventLoop stuff was doable, if you squinted just right and concentrated really hard. The async/await version is as delightful as anything else I've ever used. Nearly as easy as writing Python.
  - aplummer 4y ago
    This is what I was expecting. I think for Vapor for example it's incredible because you are always in async land. For client code, because you are returning to the main thread quite a lot - I'm not seeing so many benefits.

anonymouse008 4y ago

Do you mind explaining exactly what animations would take that much work? I’m struggling to see how animations could ever take as long as estimated for UIKit

ketzo 4y ago
The parent said “animated flows” and mentioned a banking app, so I’m betting a multi-page form with lots of transitions between a lot of different state combinations. Again, just guessing, but I would imagine that it’s managing that state and animating it in a sane way which requires LOTS of code, less so the animations themselves.
joshuawright11 4y ago
Here's a part of the flow I'm talking about; for context it's a debit card that rewards users with stock as they use it. The entire flow is SwiftUI (though the top of the pack ripping is PNG sequences so we did cheat a bit). https://streamable.com/56pha0 https://streamable.com/56pha0 (shameless plug; check us out at https://www.withapollo.com https://www.withapollo.com we're YCS21, just launched last week, and are hiring an iOS engineer!)
- anonymouse008 4y ago
  Ok, wow, yeah impressive! [Edit]: Thank you kind stranger.
  - dean177 4y ago
    > though the top of the pack ripping is PNG sequences so we did cheat a bit
NonNefarious 4y ago
How about explaining why you have a bunch of animations in a UI to begin with? Animations are so often an ill-advised, interaction-slowing pain in the ass for users that I'm curious about beneficial and non-annoying use cases.