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

181–190 of 216 posts

Re: SwiftUI in 2022

#181

Post by bryansum »

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.

Re: SwiftUI in 2022

#182

Post by pornel »

hdjjhhvvhga wrote: post #144
pornel wrote: post #45

Earlier quoted context omitted.

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.

I had mostly desktops in mind where there are more widget toolkits to choose from. On mobile it's not so great indeed. Cordova is a mobile equivalent of Electron, but often you can get away with your own native app shell + WebView.

Re: SwiftUI in 2022

#183

Post by bsaul »

i don't see how apple think swiftui can compensate for not being cross platform.

At thid point, unless you really need to reach the absolute top of UX, there is no reason not to go for react native, or flutter.

Knowing that videogames are already developped in cross platform tools, it only leave a very very small market IMHO.

I had hopes that swiftui would be cross-platform ( or at least ios + web, since apple don't want to facilitate android adoption), but i don't think it's going to happen now..

Re: SwiftUI in 2022

#184

Post by eunoia »

eunoia wrote: post #139
pcr910303 wrote: post #135

Earlier quoted context omitted.

> you’re manipulating lightweight structs that are rendered into heavyweight views by the system Yes, and I’m arguing that not exposing the ‘heavyweight views’ to the programmers at all is a mistake.

Yup, and my understanding of the problem is that if you expose the heavy weight views to the state layer (structs) and allow direct manipulation, render calls lose incompetency, the structs are no longer the source of state truth and the whole abstraction gets terribly leaky. Edit: once again I think it’s important to look at the limitations and advantages of prior work in this area and I believe React refs to be a g…

Oops autocomplete. Incompetency should be idempotency.

Re: SwiftUI in 2022

#185

Post by joshuawright11 »

NonNefarious wrote: post #165
anonymouse008 wrote: post #115

Earlier quoted context omitted.

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.

Good question! I'm very much in alignment that most non-system animations get in the way / are just annoying.

I think it depends on what the goal of the screen is. If the goal is to simple provide information to the user, it makes sense to have clean, simple, and snappy animations.

However, I think there are also situations where the experience itself is the goal. i.e. give the user a visually pleasing graphic, animation, interaction, etc. In this case going a little wild with animations can be a good thing.

Most in app situations should be the first (snappy, clean, useful). But selectively sprinkling a few instances of the second throughout your app can bring the experience to the next level.

In our case, we wanted the rewards flow (it's a banking/brokerage app) to be a fun, gamified experience to separate us from typical banks. So we opted to add a very visual, interactive experience in this single part of the app. There's a demo video above. While it's certainly extra, I think it makes the core flow of the app a unique experience.

Re: SwiftUI in 2022

#186

Post by topspin »

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 site seem like exactly the sort of mysterious behavior one faces and might be resolved with access to the source.

SwiftUI is closed source, correct? I made an effort to discover the source and it doesn't appear to be available.

Re: SwiftUI in 2022

#187

Post by bowsamic »

emehex wrote: post #171
bowsamic wrote: post #162

Earlier quoted context omitted.

No, @AppStorage just does scalars, as I said

"tried" being the operative word. But you really shouldn't be persisting an ObservableObject. You should extract what you need into a model and use Codable...

Why shouldn't I try and persist an ObservableObject? Has some Apple guru given you this secret information in a WWDC, or personally? It seems totally reasonable to do so. Observability is something you bestow upon a model, it shouldn't exclude it from persistence. You are talking nonsense to defend Apple's lazy approach. They simply have not covered this base, that's the actual non-Apple-fanboy explanation. Get it together

Re: SwiftUI in 2022

#189

Post by robert-boehnke »

I'm writing a component library[1] on top of SwiftUI and while there are ton of unsolved problems in SwiftUI, the separation of concern allows for much more productive workflows than were ever commonplace in UIKit.

We're dropping into UIKit land quite frequently but for the user of the API, that remains implementation detail and while likely change as SwiftUI advances.

Ironically, a "Stock iOS" style app like Mail or Contacts is much harder to pull off with SwiftUI than an app like AirBnB that brings has its own design aesthetic and establishes its own conventions – cooperating closely with your designers and keeping them aware of what's easy/hard is a much better use of your time than trying to rewrite a pixel perfect `UISearchController` clone.

That said, navigation remains a complete mess and I hope that's a top priority for iOS 16.

[1]: You might find this relevant to your interest if you write SwiftUI for a living: https://movingparts.io/variadic-views-in-swiftui

Re: SwiftUI in 2022

#190

Post by alexashka »

saagarjha wrote: post #155
alexashka wrote: post #105

If you like SwiftUI, I challenge you to a SwiftUI fizzbuzz: a square, screen width, 10x padding, red background. inside it, a little square, centered and a little square, top left corner, 10px padding, blue background for both. Tell me that was easy, so that I know you're lying :)

How's this? It's not quite "screen width" if you make the screen wider than it is tall, but I could make it stick to that if you really want I guess. struct ContentView: View { var body: some View { ZStack { Rectangle() .fill(Color.red) Rectangle() .fill(Color.blue) .frame(width: 100, height: 100) HStack { VStack { Rectangle() .fill(Color.blue) .frame(width: 100, height: 100) Spacer() } Spacer() } .padding(10) } .asp…

Your answer is wrong. You've failed the fizzbuzz :)
Post reply on HN