NotSwiftUI Just Got Better — Know How to Use It to Create UI Components in iOS
Building a better future for all UIKit lovers, and why investing in it matters
About NotSwiftUI
Back in December 2021 I posted this.
Essentially created my own SwiftPackage and well.. advertised it a little. The package, which is conveniently named NotSwiftUI, was built on the core idea that all of the UI elements which are provided by UIKit are essentially UIViews. From the simplest UIView, UIButton, or a UILabel all the way up to a UITextField, UITextView, UISwitch, and even a UIStackView.
NotSwiftUI offered a unique way to declare new elements and use all those UI elements in a convenient and even, some might add — a fun way. Not only declaring and creating those elements was easier but also applying various effects and configurations such as applying a shadow, adding a border with a color, performing an animation, clipping the view to its bounds, adding a target, adding a touch gesture, setting an attributed string and more…The list really just goes on and on.
Why NotSwiftUI
Having worked with SwiftUI you are ought to find bugs or “features”. Certain parts of the framework feel at times “incomplete” and various methods to achieve the wished result might even feel “hacky”.
SwiftUI is great, and don’t get me wrong, I do see it as the future — but — it is nonetheless far from being complete and reliable. This is naturally my personal and professional opinion and some people may not agree with me. But from my experience, I just don’t yet feel fully content and committed to working on a large-scale project with SwiftUI.
Despite my harsh criticism, SwiftUI does a lot of things right, especially when creating UI. The core idea behind NotSwiftUI was to bridge this gap between UIKit and SwiftUI and to allow the developer the freedom to create UI quickly and efficiently whilst maintaining a readable and easy-to-understand code.
The bridging between SwiftUI and UIKit was meant to allow the developer to achieve rather complex tasks using a minimal amount of code while maintaining readability. It is all meant to save time. A lot of time goes on fixing views in various places, connecting actions, adding gesture recognizers, adding animations, etc.
With NotSwiftUI the main idea was to allow the developer to do all this quickly and in fewer lines of code. And as everything is a UIView, everything works on everything, and if it doesn’t then nothing happens.
It’s evolving!
Since December a lot of things have happened. I became more experienced in my field and so has NotSwiftUI. I’ve made sure to try and incorporate NotSwiftUI in my projects too. Thus adapting it for more diverse uses.
As a result, today you are able to do more with NotSwiftUI than ever. You can perform animations, add targets for buttons (or as a UITapGesture) as closures, play with attributed Strings in labels, text fields, text views and buttons, creating more UI elements and much more.
Conclusions
NotSwiftUI is evolving constantly. But as time goes on more features will be added and I as a person who still believes that SwiftUI has yet reached its mature form but still would like to have fun with its declarative nature, NotSwiftUI tries to connect the two worlds together as seamlessly as possible.
Go ahead, try it, experiment, and leave feedback (it's important!), NotSwiftUI is here for all, to make lives easier, more fun, and enjoyable!
