Live data from Hacker News

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

triplebyte.com

61–70 of 76 posts

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

#61
post #58
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.

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/

I really shouldn't need to pay for support from a software engineer for something that should be in basic documentation.

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

#62
post #58
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.

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/

True, but if everyone did that, there wouldn’t be any Apple engineers left to fix the damn software itself, because they’d all be running 24/7 support for millions of angry users, answering the same damn questions and complaints again and again and again.

If that is their intended process, then it is such a false economy that it warrants firings all the way up to the board.

This is why we write documentation—good documentation, that explains the product and how to use it, and anticipates the common problems that users run into and guides them through those as well. So that users can handle the day-to-day stuff and only need to interrupt its developers for the exceptional cases that no-one has anticipated—which is as much about the developers learning what more they need to fix as about getting users over that hump in the meantime.

.

Apple is absolutely, notoriously, abominable at documentation, in part I think because Apple really absolutely hates to admit that its shit ever smells too. But if you can’t own your own mistakes, then you’re never going to fix them and get rid of that stink.

Honestly, I really miss their old NeXt-derived docs from back in the early days of OS X, both in their content and their presentation and navigability. I mean, they weren’t brilliant—good on the Whats but not asogreat on the Hows—but compared to the slop they’ve been serving users these last 10 years those docs were an absolute masterclass. Or even look at Microsoft, who * and* accept their APIs are complex and difficult, and so document the tar out of them so their users can mostly get by for themselves.

.

The other problem is, the health of the developer platform today isn’t immediately, directly reflected in the size of the next quarter’s results. So when the company’s run by and for the beancounters and shareholders, without regard for what the engineers are telling them, they don’t see the need for greater long-term investment. I mean: everything works great now, just look at the size of those revenues!

It not till years later that the knockon effects of those poor upstream processes and resources reach the surface, at which point the damage is far more severe than it ever should have been had they nipped it at the start. Just ask the formerly engineer-led Boeing how that whole McDonnell-Douglas pennycounting culture is working out for them now. Yup.

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

#63

For a new app, it is a no brainer. I've been coding up an interface in SwiftUI in the last week that would have taken me ages with UIKit. And the resulting interface is so much better, because tuning a small detail corresponds to a single line or two instead of the agony of spinning up a new UIViewController ...

If you want your new app to be more than just a simple view, have polish, have acceptable performance in simple use cases, then it is quite the “yes brainer”. SwiftUI has considerable shortcomings, very real and unfathomable limitations, and many, many performance issues. You might be fooled by how quickly you can come up with a skeleton interface, but that doesn’t make an app. Especially for people who are coming from “React” as many have said here, once they hit those limitations, they would be fish out of water, just like React Native “developers” are dumbfounded what to do once their app doesn’t work as expected, or slows down seemingly inexplicable.

SwiftUI is a nice experiment, but it’s not a serious UI framework, and won’t be for a very long time.

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

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

While I agree about the non-native sentiment, I feel like your comment describes SwiftUI exactly right on both UIKit and AppKit.

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

#65
post #58
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.

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/

Actually, if you have a paid developer account, you have two free ones per year.

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

#66

Where it works , SwiftUI is indisputably the most compact and maintainable form of data bindings and auto-layout that you have. It should be used immediately for those working cases. It is therefore critical to also learn the bridges (e.g. how to get a platform-specific view or controller out of SwiftUI) because you will also want those somewhere . Note, I have seen Herculean attempts on blogs, etc. to shoehorn ungod…

What I don’t understand is why Apple made accessing the underlying UIKit/AppKit elements such a fight in the first place. They knew they couldn’t encompass the full breadth of these frameworks in many years to come, so why not allow easy access to underlying implementation details, to allow fine tuning for those that want/need it. Really dumb decision making, but that seems to be a lot of what Apple is doing in the last few years.

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

#67

Earlier quoted context omitted.

You mean make every platform a second-class citizen?

While I agree about the non-native sentiment, I feel like your comment describes SwiftUI exactly right on both UIKit and AppKit.

For now. It’s still a first class citizen receiving the full attention & buy in of the platform to a level even Swift itself didn’t receive this early on AFAICT (iOS 14 widgets can only be written with SwiftUI).

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

#68

Earlier quoted context omitted.

While I agree about the non-native sentiment, I feel like your comment describes SwiftUI exactly right on both UIKit and AppKit.

For now. It’s still a first class citizen receiving the full attention & buy in of the platform to a level even Swift itself didn’t receive this early on AFAICT (iOS 14 widgets can only be written with SwiftUI).

That's an arbitrary limitation. Some of Apple's widgets are not written using SwiftUI.

Just like Swift, I foresee SwiftUI being a black sheep for a very long time.

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

#69
post #58
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.

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/

I had no idea this was a thing, thanks! Could have done with it recently when tracking down some nasty internal bugs in CoreMIDI. Ah well, the investigation was interesting at least...

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

#70

For a new app, it is a no brainer. I've been coding up an interface in SwiftUI in the last week that would have taken me ages with UIKit. And the resulting interface is so much better, because tuning a small detail corresponds to a single line or two instead of the agony of spinning up a new UIViewController ...

If you want your new app to be more than just a simple view, have polish, have acceptable performance in simple use cases, then it is quite the “yes brainer”. SwiftUI has considerable shortcomings, very real and unfathomable limitations, and many, many performance issues. You might be fooled by how quickly you can come up with a skeleton interface, but that doesn’t make an app. Especially for people who are coming fr…

It is a very serious UI framework. People from React (I am not one of them) just understand this better, because they know that the reactive approach is superior for UI. People who have not experienced that have often a problem grasping this simple fact.

SwiftUI has annoying bugs. I haven't hit performance issues yet. But if you encounter these issues you can always escape to UIKit. I already did several times, I have my little set of SwiftUI components already which replace the original ones. For example, Image is a buggy component which doesn't display SVG assets properly. I made an XImage component which fixes that.

On the other hand, doing everything in UIKit from the start is just a waste of developers resources. My time is too precious for that.

Post reply on HN