Everything about software UI is changing. Here's how UI engineers can stay ahead

There's an awful lot of talk about user interfaces (and the development thereof) being unrecognizable in the next ten years. Will magically-slick, no-code tools leave UI devs in the dust? Will AI and new paradigms involving wearables and gestures make traditional devs and designers alike unemployable once these inevitable shifts take place?


This is a companion discussion topic for the original entry at https://triplebyte.com/blog/everything-about-software-ui-is-changing-heres-how-engineers-can-keep-up

Joseph, just responding narrowly to the bit about SwiftUI. It changes everything, and nothing, for iOS development. It still requires plenty of domain smarts, and lots of coding, with lots of special cases and warts, that require a coder - especially to the degree shop designers only half-heartedly embrace the HIG, or follow it in name only, or quite openly not at all.

If SwiftUI was really as magical and codefree such that it belonged in the category of other things in this article (the overall premise of which I agree with, by the way), the numbers of books, libraries , reference guides, courses, etc. wouldn’t proliferate like they have. I can tell you that I have six years in on iOS and UIKit, and I’m excited for SwiftUI, but even after studying three books, doing tutorial exercises, writing lots of example code, I am DEAD slow in creating stuff compared to UIKit. It’s not the fact that it’s a different paradigm - I get the paradigm, it’s just…it requires code, and a lot of it, to get anything done. And the thousands of hours I’ve put into UIKit programming are a help, not a hindrance, but they alone don’t get me there.

In ten years, heck, maybe we won’t be using cell phones at all, maybe iOS will be deader than dead, but I don’t think SwiftUI, and even more specifically IB are apt examples of this trend. IB is embraced only very sporadically in professional shops, with a strong contingent of engineers rejecting it viscerally. I’m not one of those; I’m utterly Switzerland on the subject, don’t care if code is done ‘declaratively’ in IB or ‘imperatively’ in code; it’s all good to me, and in fact, I find it to be a distinction without a difference, for the most part.

The same of true of SwiftUI’s canvas. It’s an interesting technical feat, that is cute and cool, but in practice, I usually turn it off, because it continually breaks and need refreshing, and I haven’t found it to make it easier to make SwiftUI interfaces. But…I’m a tyro there, so maybe in two years, I’ll feel utterly different (and stipulated, the Xcode SwiftUI tools will probably be a lot better then).

I think your overall point is valid; I just think IB nibs and storyboards and the SwiftUI canvas; they aren’t really good exemplars to try to make your case with.

1 Like