Live data from Hacker News

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

triplebyte.com

51–60 of 76 posts

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

#51

My personal experience: after working on existing UIKit application for over a month or so, I spent a couple of weeks trying SwiftUI out in last summer, by first watching most of the Stanford's great SwiftUI iOS lectures https://www.youtube.com/watch?v=SIYdYpPXil4&list=PLpGHT1n4-m... With the little experience I got, I agree with mikenew's comment. SwiftUI felt like an expressive way to define UI elements, but I had…

Thank you for pointing out the Stanford lectures. I wasn't aware of them and they look really good to get up to speed. I messed around with SwiftUI a while back but I haven't for the past year, so those should help me get back into it.

The game looks very impressive for being new to iOS. If you haven't looked into it yet, I recommend learning SpriteKit as well. Its animation system (SKAction) is pretty nice. I actually ended up basically re-implementing it in C# for another game I was working on, since it wasn't terribly hard to do (got the subset of actions I needed working in a couple of hours), and you can be very expressive with it, once you grok groups and sequences.

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

#52
post #48

Earlier quoted context omitted.

What code? SwiftUI is closed source.

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

Anyone who can do that for SwiftUI code can’t be human

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

#53

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

Nice! I love you app. I’ve been working on a similar one I call App Maker that’s more for developers. https://appmakerios.com

I’ve even made the entire App Maker app inside SwiftUI to prove to myself just have viable it is.

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

#54

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.

I just meant the interface.

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

#55
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.

How is this the best way of protesting? Apple doesn’t care if you write an app in React Native.

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

#56
I have two apps in the Store built with SwiftUI, one ported from UIKit and the other started from scratch in SwiftUI. I’ve been “all in” since it’s announcement in 2019, despite suffering through it’s growing pains. I really wish the framework was opened up or at least distributed separately to OS updates, watching how open and quick the Android team are with Jetpack Compose really shows the different approaches to library development and Apple’s feels really outdated.

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

#57
post #4

> As of June 2020, Apple Reports that 92% of devices introduced in the last 4 years use iOS 13, while 81% of all devices (including the oldest) use iOS 13. Some businesses are not willing to part with that remaining 8%-19% of users. I'm surprised that so many people have the latest iOS. I was reluctant to use SwiftUI because I thought that more people have older iPhones which wouldn't support it.

iOS 14 support goes back to the 6S and original SE, so the newest unsupported phone is the iPhone 6 from September 2014. Not a lot of those still around.

Just for the anecdote : as an owner of an iphone6, i have to say this phone was perfectly functional. it made me feel extremely bad to buy a se2 just so that i could test my code on a real device.

moving from iphone6 to se2 is the first time i've felt disappointed by my new iphone. it's bulkier, the battery lasts about just as long, and the screen feels cheap.

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

#58
post #24
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…

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.

I would like to remind everyone that you can pay Apple just under $50 in order to receive direct support from a software engineer.

https://developer.apple.com/support/technical/

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

#59
post #50

Earlier quoted context omitted.

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.

The whole field of engineering is about solving real, immediate tasks that users have. What you're describing is politics.
Post reply on HN