Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI in 2022

mjtsai.com

Post reply on HN
Print view View original

201–210 of 216 posts

Re: SwiftUI in 2022

#201

Post by b3morales »

saagarjha wrote: post #147
b3morales wrote: post #104

Earlier quoted context omitted.

> 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 the…

> UIStackView is much more boilerplate to use than just a HStack/VStack.

It is. It's also far more flexible in return.

But the point is that if someone has to ask this question then they don't have enough experience with UIKit to be comparing SwiftUI and UIKit.

Re: SwiftUI in 2022

#202

Post by b3morales »

topspin wrote: post #186
czhu12 wrote: post #145

Genuine 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.

Another genuine question: is there a good reason to use a closed source UI framework in 2022? Given the number of high quality, cross platform UI frameworks available today this should be a consideration. Inevitably, while developing a UI, I find it necessary to investigate some part of the framework implementation. This is impossible with a closed source framework. Indeed, many of the complaints that appear on this…

SwiftUI is very closed source, yes.

Re: SwiftUI in 2022

#203

Post by JamesSwift »

cageface wrote: post #72
ChrisMarshallNY wrote: post #44

I'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…

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…

UIKit isnt even deeply MVC. Its purely C. The Controller is the god object by design, but also because the first 10 years of iOS tutorials never took the time to even split out a single View. So that became the gateway for everyone learning the platform, and is what they imitated.

Its not much better today overall, but is usually not an issue within companies themselves.

Re: SwiftUI in 2022

#204

Post by aaaaaaaaata »

nyanpasu64 wrote: post #168
quux wrote: post #96

Earlier quoted context omitted.

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 b…

Build a PWA =^]

Re: SwiftUI in 2022

#205

Post by pjmlp »

Not to steal the thread, on the other side of the fence it feels similar.

Jetpack Compose performance is a pain versus traditional Android views, hence some performance related talks at Google IO 2022.

The UWP, WinUI 2.0, WinUI 3.0 mess, that makes it more fun to keep using Forms/WPF/MFC than adopt them.

Makes one wonder where are those teams coming from, with what resources are they dealing with, that in the end we get such quality.

Re: SwiftUI in 2022

#206

Post by pjmlp »

czhu12 wrote: post #145

Genuine 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.

It makes no sense with any of them.

For CRUD stuff we do regular Web applications, naturally with the necessary optimizations for mobile Web, in the process you can also make use of PWA features for mobile devices.

Try it out on your device, https://whatwebcando.today/

Re: SwiftUI in 2022

#207

Post by ChrisMarshallNY »

JamesSwift wrote: post #200
ChrisMarshallNY wrote: post #198

Earlier quoted context omitted.

I liked the "cut with the grain" comment, someone made earlier. The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers. It's entirely possible to basically use a "skeletal" one, and have the main code in the linkages between the Model and the View, but that makes the Storyboard Editor useless. I use the Storyboard Editor a lot . It is not my fav…

> The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers. I dont think you understand the point I'm making. Just because Apple has created a framework that has something called UIViewController which has child UIViews doesnt matter when using a pattern called MVVM. The V is just the _visual_ representation of the pattern. It could be a terminal…

Actually, I understood just fine. I’ve been doing this kind of thing for a while. I’m not even disagreeing. I understand where you are coming from.

It’s just Apples and oranges.

I write in Swift, as a native developer of Apple software. I won’t go into all the reasons I do what I do (actually, I’ve covered a lot, in this thread). I have my reasons, and there’s nothing wrong with my approach. I get a lot done, very quickly, and at a fairly high Quality level.

Life is a compromise. We always need to make trade-offs.

Re: SwiftUI in 2022

#208

Post by saagarjha »

alexashka wrote: post #196
saagarjha wrote: post #191

Earlier quoted context omitted.

I generally expect interviewers to tell me what the problem is ;)

My apologies, you've successfully passed FizzBuzz, in a rather unwieldy way by relying on nesting vstacks, hstacks and adding spacers. The larger point being - placing squares on a page went from drag and dropping and setting a few constraints, to now doing zstack/hstack/vstack/spacer wizardry.

I think I'd ideally want to do this with some alignment constraints but I don't see this as being far more difficult than setting constraints manually. Doing this correctly is actually somewhat non-trivial because you'll want the square to respond to rotation appropriately, etc. which will require less-than-or-equal constraints.

Re: SwiftUI in 2022

#209

Post by andrekandre »

emllnd wrote: post #85
gh123man wrote: post #20

Earlier quoted context omitted.

You are probably pulling firebase into your preview code somewhere. You should structure your previews to depend on mock implementations of your model (or mock data). It will make the previews much faster and more reliable. My app also uses firebase and SwiftUI with hundreds of files (views, view models, and more) with no problems.

+1 on this Got working SwiftUI previews on a 50-100k LOC project with many big libs as dependencies, must be hundreds of files but havent counted. SwiftUI code is gaining share of the total UI code, probably around 20-30% now Mock data is a must. Need to be mindful of the preview build (+ preview simulator startup) time too, sometimes it will timeout but just building again (now warmer) will make it work Had some ini…

one other solution is to build a sub project that links to a subset of minimum dependencies needed for ui development and build your swiftui stuff there...

it will be lightning fast compared to large xcode project... and it might even be better architecturally too, since you'd have to factor out lower level logic (view models or whatever) anyways

Re: SwiftUI in 2022

#210

Post by andrekandre »

Willamin wrote: post #87
makecheck wrote: post #64

Lots 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,…

  > Combine is an abstraction to encapsulate changes in state over time
so is https://github.com/apple/swift-async-algorithms
Post reply on HN