Live data from Hacker News

Should I use SwiftUI in production? A code-to-code comparison to help you decide

triplebyte.com

41–50 of 76 posts

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#41
“Unlike a collection view, all items will be loaded into memory at once.”

I recently had to rewrite a UIView where the dev implemented a 3 by 30 scrollable image display only using StackViews. Despite image disk caching it took forever to load, the table was a veritable forest of spinners for 30 seconds. Re-Implementing as CollectionView only partially improved the display, eventually I had to add a memory cache to make it snappy.

I’m at start of switching to SwiftUI right now for a new project and these are the kinds of edge cases that worry me. But as long as I can build UI in UIKit too I’m okay with it. Build the 90% that is easy on SwiftUI, and the 10% performant pieces in UIKit and I should still be much faster.

So far it reminds me of a version of React not crippled by JavaScript. I once spent a year on a React Native project as iOS frameworks lead, and it was a nightmare. Terrible build problems every time they added new libraries, and debugging problems that crossed the Swift/React boundary was at times nearly impossible.

Nothing like being blamed for endemic updating problems for months while pulling your hair out trying everything to solve them. Then to have the React lead quietly say “oh, I found the problem” during an offsite. The rest of the company never remembers that, just the months of the iOS team looking incompetent.

This is so far a piece of cake by comparison, with far higher code quality.

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#42
post #9

I've been working full time on an app in SwiftUI for the past 8 months or so. I'll sum it up this way: I frequently oscillate between thinking "This is amazing, it truly is a joy to work with SwiftUI" and "Holy FUCK this is the most infuriating thing I've ever experienced in my life". I can't comment on the documentation, because there isn't any. The closest thing you get is the WWDC videos from the past few years wh…

The only documentation you can count on is to just read the code. It’s all pretty well commented and the interfaces make sense. I’d say the difficulty is it’s not very discoverable, and you actually have to watch the wwdc videos to learn the high level concepts. The only discoverability you get is just surfing around, reading the code. I think it’s all in SwiftUI though, which is obviously a huge file.

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#43
Apple's going to keep this platform closed, so you should write in a cross-platform framework. Don't adopt their tools or dance to their beat.

The best way to protest Apple's iPhone dominance is to write cross-platform, non-native code.

iOS should be a second class citizen.

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#44
post #9

I've been working full time on an app in SwiftUI for the past 8 months or so. I'll sum it up this way: I frequently oscillate between thinking "This is amazing, it truly is a joy to work with SwiftUI" and "Holy FUCK this is the most infuriating thing I've ever experienced in my life". I can't comment on the documentation, because there isn't any. The closest thing you get is the WWDC videos from the past few years wh…

The only documentation you can count on is to just read the code. It’s all pretty well commented and the interfaces make sense. I’d say the difficulty is it’s not very discoverable, and you actually have to watch the wwdc videos to learn the high level concepts. The only discoverability you get is just surfing around, reading the code. I think it’s all in SwiftUI though, which is obviously a huge file.

What code? SwiftUI is closed source.

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#45
post #43

Apple's going to keep this platform closed, so you should write in a cross-platform framework. Don't adopt their tools or dance to their beat. The best way to protest Apple's iPhone dominance is to write cross-platform, non-native code. iOS should be a second class citizen.

You mean make every platform a second-class citizen?

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#46
Disclaimer: I make an app that is basically WYSIWYG SwiftUI for designers (https://www.detailspro.app).

I think the author put it best with "If you've undergone the mental paradigm shift, the productivity gains were worth the minor setbacks, which really weren’t so hard to fix."

My career has included periods where I had a React day job and a bunch of iOS side projects. So many times, I'd come home from work, stoked on React, and look at iOS and wish it were declaratively already. I actually took a stab at an open source, declarative UI library that's still on GitHub.

SwiftUI, IMO, brings the smarts of React, with many dashes of magic that only Apple HIG magic that only Apple could come up with. Definitely, there are plenty of holes today, but I never, ever, ever have to hook up a UITableViewDataSource and a UITableViewDelegate ever again, and for that I am infinitely thankful.

Looking purely ahead at SwiftUI and what it will do for Apple platform years from now. I recommend anybody who is thinking about it to try it out.

Soon enough, I'll forget the signatures of the UITableView stuff, and other UIKit stuff, happily.

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#47
post #24

Earlier quoted context omitted.

I don’t understand why Apple doesn’t just document this. Is the team responsible for it just pro-UIKit and doesn’t actually want people to use SwiftUI or something? Because the lack of documentation for so long really does give me the impression that they actually don’t want people to use it. It’s hard to believe it could just be incompetence.

For what it's worth, I've been getting plenty of Feedback Assistant responses from Apple to requests related to SwiftUI and its documentation. And Josh Schaffer who led UIKit also leads SwiftUI now.

> Is the team responsible for it just pro-UIKit and doesn’t actually want people to use SwiftUI or something? Because the lack of documentation for so long really does give me the impression that they actually don’t want people to use it.

> And Josh Schaffer who led UIKit also leads SwiftUI now.

This makes it sound like GP's theory is at least plausible

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#48

Earlier quoted context omitted.

The only documentation you can count on is to just read the code. It’s all pretty well commented and the interfaces make sense. I’d say the difficulty is it’s not very discoverable, and you actually have to watch the wwdc videos to learn the high level concepts. The only discoverability you get is just surfing around, reading the code. I think it’s all in SwiftUI though, which is obviously a huge file.

What code? SwiftUI is closed source.

...maybe asimpletune is really good at reading disassembled machine code?

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#49
post #43

Apple's going to keep this platform closed, so you should write in a cross-platform framework. Don't adopt their tools or dance to their beat. The best way to protest Apple's iPhone dominance is to write cross-platform, non-native code. iOS should be a second class citizen.

And let the user experience of the paying users suffer due to the completely uncanny valley and frankly second tier implementation of the cross platform toolkits?

Sorry my friend, it's the users that take the first priority and should take the first priority, not the developers or anyone else.

Re: Should I use SwiftUI in production? A code-to-code comparison to help you decide

#50
post #43

Apple's going to keep this platform closed, so you should write in a cross-platform framework. Don't adopt their tools or dance to their beat. The best way to protest Apple's iPhone dominance is to write cross-platform, non-native code. iOS should be a second class citizen.

And let the user experience of the paying users suffer due to the completely uncanny valley and frankly second tier implementation of the cross platform toolkits? Sorry my friend, it's the users that take the first priority and should take the first priority, not the developers or anyone else.

> Sorry my friend, it's the users that take the first priority and should take the first priority, not the developers or anyone else.

Our field, ethics, and freedom take priority over users. If they don't, you should reevaluate what you're doing.

In servicing those concerns, users will win.

Post reply on HN