> how I shipped an amazing full-featured cross-platform SwiftUI app in 10 minutes
For anyone wondering: "cross-plaftorm" means Apple platforms, not real multiplatform like Flutter.
SwiftUI in 2022
141–150 of 216 posts
Re: SwiftUI in 2022
#142I 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 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.
Re: SwiftUI in 2022
#143I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit. A couple of reasons: 1) The documentation for SwiftUI, when I started (about two years ago) was awful . I was shocked at how bad it was. I believe that it has since improved. 2) I knew of no major apps (even Apple ones) that had been done with it. I already knew that UIKit was up to the task, and held my nose, w…
> I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril.
I dont understand this. MVVM is an extremely abstract pattern. It transcends the technology stack. How it is implemented on the platform differs, and yes you are not going to avoid the UIViewController when doing it on iOS. But you are still doing MVVM even if your V is actually a UIViewController.
I use MVVM almost exclusively now, and I usually do it in a cross-platform framework (Xamarin/MAUI). The codebase is portable across both iOS and Android with no re-architecting of the high-level architecture pattern.
Re: SwiftUI in 2022
#144Earlier quoted context omitted.
Wouldn't be surprised if no one quoted there has ever used Flutter. The Apple dev comment-sphere is quite insular.
It's not a surprise there's zero overlap. The type of people who develop native Apple-only apps really care about having proper first-class native UI down to every detail, not merely something close enough. As you can see, for many even Apple's own SwiftUI isn't "native" enough, so at this level of detail using Google's generic UI framework is completely unthinkable. For cases where portability or development time is…
> there are lots of better options
Could you give some examples? Most people I talked to really hate React Native, for example. Ionic doesn't seem to have gained enough momentum. You mention Electron, but the last time I checked it's only for the desktop, not mobile. Each year new options appear, but I'm not sure they are that great.
Re: SwiftUI in 2022
#145Genuine question: is there still a good reason to build CRUD type apps in Kotlin / Swift in 2022 with stuff like React Native and Flutter out there?
Not talking about award winning, unique apps that may require more device specific capabilities, rather the 90% of apps out there that just want to offer users an easier way to CRUD into a database.
Re: SwiftUI in 2022
#146[deleted]
Re: SwiftUI in 2022
#147Earlier quoted context omitted.
I watched a youtube video about VStacks and Spacers and I was having fun making real layouts my first hour in - with a fast, live preview environment. That was my "oh wow" moment. What's the equivalent with UIKit? Interface Builder is nothing like what's now possible with SwiftUI. I've tried IB in the past and it was not for me.
> What's the equivalent with UIKit? UIStackView > I was having fun making real layouts my first hour in Good. Now take a pixel-perfect mockup of a new screen from your designer at work and implement that.
UIStackView is much more boilerplate to use than just a HStack/VStack. And I do a lot of design work in SwiftUI–it's really easy to get stuff on the screen and directly how you want it to look, even for a design mockup. I'll just not hook up interactivity and it works just fine for that kind of storyboarding. If you have a designer that wants you to follow their lead "to the pixel" then they're probably not doing their job of UI design very well–a good process works both ways, where you provide insight into what works well on the platform and they provide their own suggestions until you meet in the middle.
Re: SwiftUI in 2022
#148Lots of great and specific points in these threads, many of which I have personally seen. SwiftUI was really promising at first, and even fun to use (nothing like ripping out entire UI files or pages of code). Yet, issues were almost immediately apparent. A major concern is that it seems to take Apple a really long time to address even basic issues, e.g. years go by and things still broken since day 1 are there, whil…
> deprecate Combine and move further toward actors and async APIs Combine is an abstraction to encapsulate changes in state over time, while actors and async APIs are abstractions to encapsulate concurrent behavior. I think these are orthogonal concerns, so they wouldn't likely drop one in favor of the other. > SwiftUI is very dependent on Combine As someone who's been writing SwiftUI a lot over the last year or two,…
Yeah I've never used Combine and I've written a decent amount of SwiftUI. My impression is that Swift Concurrency is the future and will slowly get more and more adoption in the APIs.
Re: SwiftUI in 2022
#149Earlier quoted context omitted.
> People seem to either love it or hate it. Or is that just an effect of people posting on Twitter? I'm sure that a big part of that is the effect of it being Twitter. How often do we feel the urge to post something online that we have no strong feelings about? More on topic, though: I'm a SwiftUI hater still. It's a cool concept, but there are two big problems with it, IMO: 1. It's totally out of place with the rest…
Not to be super rude, but why are you a polyglot dev if you don’t like learning multiple frameworks?
I don't find that to be a rude question at all.
I love being a polyglot dev and I love learning and using different programming languages, frameworks, and app platforms. The issue I have is with learning redundant frameworks that don't actually give me more power.
To continue berating ORMs, I am in charge of several different projects at work that communicate with SQL databases. The set of programming languages that span these projects is: Kotlin, PHP, Rust, and JavaScript (being phased out). I love getting to switch between these languages (just not too frequently, lest the context switching kills my brain), and I feel like it helps me to see the strengths and flaws in each, and it's just really fun to find effective patterns in each.
Whether I use an ORM in all or none of those projects, I'm going to have to be competent with SQL. But if I decided to use an ORM for all four, I'd have to learn five different ways to get data in and out of our databases. Rather than learning four redundant, incomplete, data retrieval "languages" that sit on top of SQL, I rather learn... almost anything else.
I have used lots of ORMs: The Symfony one for PHP whose name I can't recall, Magento's weird one for PHP, Hibernate (Java), Sequelize (JavaScript), and a few others in other languages. They all have subtle issues. And they are "issues" and not just different design choices- I'll never ever accept that Hibernate/JPA/JDBC returning a `(int) 0` when it encounters a null result from a nullable integer SQL value is anything short of lunacy when Java has a native null value. And they all have stupid things like that. Learning those gotchas, bugs, abstraction leaks, performance problems, etc, is not the fun kind of learning for me- it's just tedious and frustrating.
So, to bring it back to SwiftUI, I love that I manage an iOS app. I like learning about how iOS works, and I like working with Swift. It's still required that we know how to use UIKit APIs for non-trivial stuff, so why would I learn SwiftUI (and its problems and gotchas) so that I can do 75% of my work with SwiftUI and 25% with UIKit APIs? It's possible that it would make me an even better iOS dev, but I doubt it (at this point). I think my time is better spent learning something that will allow me to accomplish tasks with computers that I don't already know how to do.
Re: SwiftUI in 2022
#150Things were easier when it was just Objective-C and UIKit / AppKit. Swift killed my joy of making iOS apps.
How is Objective-C easier than Swift.
Swift is very strict. Objective-C lets you get away with more. E.g. optionals in Swift are kind of annoying. if let, guard let, blah blah blah. I like Swift more than Obj-C, but Obj-C is a fine language in its own right. Definitely easier to write once you get a hang of the notation. Swift may have a more familiar syntax, but it forces you to think about more things when writing code.