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!)
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.
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.
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…
Apple tried to solve this with @AppStorage, but if you lean on MVVM... it doesn't really work. Hoping we get some new CoreData + UserDefaults stuff this upcoming WWDC
SwiftUI is not less daunting than UIKit. In fact I would say that the SwiftUI "magic" is far scarier for beginners than IBOutlets and UIViewControllers
Beginners love magic, it lets them do things they otherwise couldn't do.
I don't agree, magic is confusing and scary. Especially in SwiftUI where it literally looks like it's invalid syntax if you're used to basic Swift.
I just finished a contract on an app with 400K users. It was in pretty bad shape when I got my hands on it. Last update: February 2020. Targeting iOS 11+, mostly UIKit, powered by Cocoapods with 25 dependencies, and 1.3M LOC. It took me 3 months to rewrite everything from scratch in SwiftUI, with 100% feature parity. Of the ~20 different view/components that I had to write, just one required me to dip into UIKit (wit…
Wait, it went from 1.3M LOC to 6.5K? Was the UI layer really that bloated or are you counting the 3rd party dependencies? I envy you the 3 months without adding any "customer value" (not joking, I'd love that).
Yeah. 1,300,000 to 6,500 (not counting the dependencies). While the previous devs obviously had programming experience, it was clear they were quite green in Swift/iOS.
Customer value was that the OG app was crashing like 1 in every 6 uses. Updated app was crash free. Plus, added two new features during the rewrite.
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;…
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
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.
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
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 (shameless plug; check us out at https://www.withapollo.com we're YCS21, just launched last week, and are hiring an iOS engineer!)
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
One recurring issue I see on native Android navigation is, when you open an image in a file manager, switch back to the file manager and open a second image in the same viewer, sometimes pressing Back takes you to the first image. As a specific example, in Foxy Droid, if you download 3 apps in the background, get 3 "app downloaded" notifications, and click each one in sequence, you have to press Back 3 times to get back to Foxy Droid's home screen. What's the best way to avoid this issue without reimplementing your own navigation system replacing activities?
Flutter is almost exclusively used by web developers in my professional and personal experience which is odd considering the lack of JS. The types of companies that hire iOS developers and build iOS apps also hire android developers and build android apps, again, IME.
Work for a financial institution which hired iOS and Android developers and had them rewrite everything in Flutter.
It’s the natural move, it’s just odd I’ve mostly seen adoption using web developers so far.
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 (shameless plug; check us out at https://www.withapollo.com we're YCS21, just launched last week, and are hiring an iOS engineer!)
Ok, wow, yeah impressive! [Edit]: Thank you kind stranger.
> though the top of the pack ripping is PNG sequences so we did cheat a bit