Adventures in SwiftUI
In this blog post I will share with you my adventures so far with SwiftUI. To instill you with confidence in my words, know that I am an old person. I am a very experienced programmer who has been doing iOS/Swift dev for years. I’m not some N00b. I have three apps in production that rely upon SwiftUI. One of them almost exclusively. So everything I say should be taken as gospel. Pack it into your brain and never forget it. Write it on a fucking stone tablet. Put that stone tablet in your bed where your ex used to sleep. Talk to it at night…
Forgive the sarcasm but I am already experiencing that intolerable pang of dreadful boredom that comes every time I try to write about shit like this but here we go nonetheless…
Here’s the bottom line people. This is some serious shit. As a modern-day iOS/Mac/Swift developer you should probably be building new projects in SwiftUI. I say “probably” because nobody fucking knows what Apple is really up to but all signs point to SwiftUI being THE WAY people build apps for Apple platforms.
That said, it’s impossible to build anything great TODAY without dropping to UIKit for some of the core functionality. I find this somewhat curious since one of the flagship new features in Xcode 12 is it’s ability to create projects in pure SwiftUI which at this point is a practical guarantee that your project will hit a brick wall at some point in its development.
I wonder if it will ever be possible to build something in pure SwiftUI. It is a radically different approach to development and I wonder if some of its shortcomings are due less to the fact that it is new and more to it being the wrong approach for some problems. I am reminded of the difference in paradigms between object-oriented and functional programming, both with advocates that swear by its supremacy but the truth, as with all things political and technical, is somewhere in the center.
Basically... YAWN… Although (as with any centrist point of view) it is boring, the best approach to SwiftUI is one of balance; understanding that it is no silver bullet. It is generally superior for building user interfaces BUT, some aspects of UI defy demarcation into SwiftUI’s declarative paradigm and this can only be overcome by the freedom to drop into UIKit.
And that just about wraps up my top-down view of the situation BUT please do not leave without a VERY healthy skepticism of anything new coming from Apple or any corporate monolith for that matter. The early adopter tax is very real. Look it up. Know that adopting this new tech is a risk. Let me give you an example…
My current project has a primarily SwiftUI-based front-end. It works great on iOS. It’s fast. I’m having fun. BUT, as of this posting I am unable to release that project on Big Sur because of some utterly show-stopping bugs that have inexplicably gone unacknowledged by Apple. I’d understand if these bugs were edge cases but it’s stuff like TapGestures not working, mysterious loss of focus, basic user interaction stuff. It happens consistently on both Apple sillicon and Intel-based machines. I’m baffled how such obvious bugs go seemingly unnoticed and unaknowleged.
So this leaves the developer—the early adopter—in a position where he must have faith; faith that he is not crazy, and the bugs he’s experiencing are real and Apples failure to notice or acknowledge them are just your typical corporate-bureaucratic interdepartmental negligence; faith that they’ll surely address them sooner or later and that your investment in this new tech will pay off eventually. Because I really was excited about releasing my new app on Big Sur god damn it.
