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

121–130 of 216 posts

Re: SwiftUI in 2022

#121

Post by alexashka »

emehex wrote: post #111
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 :)

Took me 5 minutes. Copy and paste this into a playground: https://gist.github.com/maxhumber/1dbdf0d9c4539a8e145b3c630c...

Your answer is wrong. You've failed the fizzbuzz :)

Change frame (screen width) to 300, 500 to see why.

Re: SwiftUI in 2022

#122

Post by jkubicek »

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…

> better off cutting with the grain of the underlying platform's abstractions

That's a great little turn-of-phrase that I plan on stealing in the future. Apple's APIs will absolutely reward you for taking the time to step back, figure out how Apple wants you to use them, and try your hardest to use them in that way.

An example from the olden days of iOS development: many of the apps I worked on went out of their way to avoid subclassing UIView, filling their view controllers with layout and interface updates that would have made much more sense in a view. If only they had read all the docs for UIView would they know that doing something like subclassing a button and tweaking a few methods would have done exactly what they wanted with a minimal amount of work.

Re: SwiftUI in 2022

#124

Post by bryansum »

akmarinov wrote: post #14

Has anyone gotten SwiftUI previews to work at all with a project that has more than 20 files or some dependencies? My project utilizes Firebase as the backend and as soon as you add that dependency - SwiftUI previews never compile, due to build time outs.

Yes, I recently built an entire app with 70+ frameworks that works fine in Previews. The key is to isolate dependencies into their own modules, and also split those into interface / live implementation modules if needed if the live impl causes preview crashes. See https://www.pointfree.co/episodes/ep171-modularization-part-...

Re: SwiftUI in 2022

#125

Post by PStamatiou »

b3morales wrote: post #104
PStamatiou wrote: post #102

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

> Good. Now take a pixel-perfect mockup of a new screen from your designer at work and implement that.

I'm also a designer and have built many detailed screens with custom components/interactions in SwiftUI.

Re: SwiftUI in 2022

#126

Post by austinl »

> “Hey I got 90% of what I wanted really quick! Neat!” “…oh turns out that last 10% is basically impossible, eh?” Adam Kaump

I've been working on an app that's mostly SwiftUI for about a year now. It feels magical when it works, but I don't think I've saved time vs. using UIKit at this point due to all of the workarounds that I've needed to find.

Particularly, SwiftUI List views are still loosely supported, and in some cases broken. Unfortunately for devs, lists are the cornerstone of many apps.

For example, it's very difficult to get the content offset of list. You cannot put multiple buttons in a list row without breaking their tap targets. You can't change the background color of a grouped list without changing it globally (and it's very difficult to customize many SwiftUI components, like the navigation bar). It's difficult to control the spacing between sections in grouped lists. I could go on.

Developers are stuck in a hard place right now. If you're starting an iOS app today, do you go with UIKit (and accept that your code will soon be considered legacy by Apple and many engineers?) Or do you go with SwiftUI, and accept that many things will be broken or impossible to make right?

Re: SwiftUI in 2022

#127

Post by aplummer »

emehex wrote: post #112
joshuawright11 wrote: post #101

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

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.

Re: SwiftUI in 2022

#128

Post by throwaway1777 »

ragnese wrote: post #9
dgellow wrote: post #2

I looked a bit of the posts on Twitter, and wow, it’s really polarized. People seem to either love it or hate it. Is SwiftUI still that controversial, or is it just an effect of people posting on Twitter?

> 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?

Re: SwiftUI in 2022

#129

Post by jeffreyrogers »

ChildOfChaos wrote: post #93

I haven't done much programing as a kid and i'm just starting to learn Swift/SwiftUI through the hacking with swift course, interesting to read the comments here as I didn't realize it was so hated? Seems fine to me for building apps but I don't really know enough.

SwiftUI is good enough to make apps with. All tools/libraries have problems. You'll advance much faster by learning to work with their limitations than you will be trying to find the perfect framework to use at the start (it doesn't exist anyways).

Re: SwiftUI in 2022

#130

Post by b3morales »

emehex wrote: post #111
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 :)

Took me 5 minutes. Copy and paste this into a playground: https://gist.github.com/maxhumber/1dbdf0d9c4539a8e145b3c630c...

Now please see how it looks on a device: https://postimg.cc/crtKHSTG
Post reply on HN