SwiftUI in 2022

• BreadBuddy

  5 119 0.0 Swift

  Recipe scheduler for iOS

I'm an iOS contractor, and do most of my work in SwiftUI. Sure the framework has it's warts, but I honestly love it.

Shameless plug -> I recently open-sourced an app showcasing how to use SwiftUI + MVVM in a production: https://github.com/maxhumber/BreadBuddy

• RIBs

  5 7,668 7.9 Kotlin

  Uber's cross-platform mobile architecture framework.

  

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• EffectivePower

  3 156 4.2 Swift

  Apple PLSQL viewer

I just finished writing a little Mac app in SwiftUI for my personal use yesterday: https://github.com/saagarjha/EffectivePower (https://twitter.com/_saagarjha/status/1528937319171887104 for a slightly out-of-date screenshot). Here are my thoughts.

The good:

* Making all the graphs (they're drawn by hand!) was very nice and easy. The speed at which I could iterate with them was incredible, and I could just move code around and lay things out and move them between moves in a way that AppKit (or UIKit) would not allow, at all.

* I could keep the code very clean, with each component being very specific and isolated. Plumbing bindings through made things very natural and I can imagine taking the code I made there and just plopping it into another project as-is.

* The result is actually kind of nice, IMO? There's a lot of focus on whether SwiftUI works and stuff but not much focuses on what the end result is. I had an app in my mind that I wanted to make, and it was mostly possible to make it in SwiftUI. In some places I was pleasantly surprised that things I would have been hesitant to try before (slider in a toolbar!) "just worked".

The middling:

* I initially supported macOS 12.0 only. Someone asked me to backdeploy to 11.0, which was a little painful mostly because Material didn't exist back then and neither did support for initializing a color from a NSColor. I did kind of a lazy stab at it and the end result being fairly simple, but took about an hour to write: https://github.com/saagarjha/EffectivePower/blob/main/Effect.... If I had to support 10.15 I think I would honestly rewrite large parts of the app in AppKit, maybe keeping just the graphs as view representables.

* My data model has tens of thousands of elements. Ensuring the "reactivity" didn't cause a bunch of things to be recalculated when they shouldn't was a bit of a challenge. The place I have it now is very nice (I have them defined in such a way that they will never update unless they need a redraw) but this definitely does not come "for free", you'll find out about it after profiling and need to figure out how to fix it.

* I wrote simple versions of things that don't seem to exist in SwiftUI but AppKit provides for free, such as magnification bouncing. It was like three lines of code to get something that seems reasonable, but with SwiftUI I'm never sure if this is a "we just didn't add it yet" thing or a "oh this is so simple in the framework that you should just write it yourself".

The bad:

* Things are broken and I don't know why. If you use magnification gestures the callbacks stop getting called. No indication why. I have some commented out code that would've used a table in the sidebar, but I had to use a List instead because it seems like SwiftUI does not properly update the table and it crashes with an assertion.

* Documentation sucks but that's nothing new. There's a lot of things that work but you need to be clever at arriving to getting to that point. It's a fun challenge for a toy project but for a production thing I can see this being super frustrating.

* If you mismatch a type somewhere the compiler is just going to time out rather than telling you what is wrong. Thankfully you can just go through and comment out large parts of the app to reduce the scope of where the error is coming from, but the fact that this is necessary is kind of annoying.

• DeepMenu

  3 4 5.1 Swift

Am experimenting with a new menuing idiom with SwiftUI [1]. It is both delightful and infuriating. Am delighted by autolayout. But, way too much semantics for observers. To simplify, I intentionally avoided structs, for view models, and resorted to classes.

I hope to create a package and use it for metal based visual music synthesizer. But, those complaints about playing nice with UIKit? Am rather worried.

[1] https://github.com/musesum/DeepMenu

• swift-composable-architecture

  59 11,377 9.6 Swift

  A library for building applications in a consistent and understandable way, with composition, testing, and ergonomics in mind.

  

One point that's not being discussed enough -- using SwiftUI (since it's heavily value-typed / struct-based) prevents a whole host of problems around retain cycles, typically the bugbear of iOS dev. I recently built an iOS app from scratch with recent grads with zero Swift experience (but had done React).

It was ~2mo before they even had to learn what a retain cycle was, and that was from using UIKit.

Of course you still eventually see this if / when you use `@ObservedObjects` and their implementation, but in our case we were also using https://github.com/pointfreeco/swift-composable-architecture which hides this away as well.

• swift-async-algorithms

  6 2,776 6.7 Swift

  Async Algorithms for Swift

  

• Builder

  1 137 0.0 Swift

  Demonstrates SwiftUI builder patterns for UIKit and networking. (by hmlongco)

Then again, you can eliminate a lot of that boilerplate. I have a demo app up where I generate UIViews using resultBuillder such that you get a very SwiftUI-like experience using UIKit views.

https://github.com/hmlongco/Builder

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

Suggest a related project