InterfaceBuilder.swift
InterfaceBuilder.swift lets you quickly build complex UIKit layout in code, speed up native app development and is completely open source.
[…]
The SwiftUI approach to layout in code is objectively fantastic and has inspired many aspects of this library. On the flip side, actual SwiftUI layout behaviour is very similar to self-sizing elements in HTML and abstracts many complexities to the underlying mystery layout engine. As with HTML, minor changes to the engine result in widely different layout behaviour. Whether this approach makes sense or not is debatable, but one thing is for certain: iOS has not (initially) been designed for, or particularly good at, self-sizing. In conjunction with several ways to cause unexpected redraws through Combine, it’s no wonder performance remains an issue.
[…]
Since SwiftUI (plus new APIs) come bundled with OS releases, this is a recipe for broad range of inconsistencies.
The name “InterfaceBuilder” is apt because it’s replacing the Interface Builder part of Xcode and also because it uses Swift result builders to set up interfaces.
I think part of the reason people like SwiftUI is that it has so many batteries included. A longtime weakness of Cocoa is that it doesn’t offer much in the way of reusable controllers or make it easy to set up interfaces in code (though that has improved somewhat). Imagine if Apple had continued iterating on NSController and made a Swift DSL for views and auto-layout. I think that could have been pretty great, and it would have been built atop a mature foundation, which you could drop down to if needed.
Apple went a different way. But this is not something only Apple can do. You can make the API/DSL that you want on top of AppKit or UIKit and then write your apps to that. You may not be able to use SwiftUI today, but you can use it as inspiration and evolve your code in that direction.
Previously:
Update (2022-10-07): Steve Troughton-Smith:
Playing with Swift Result Builders to make SwiftUI-style UIKit layout. No autolayout, no Interface Builder (and no SwiftUI). So much of what’s good about SwiftUI could have been done without the magic, the unreliability, or the upheaval.
Update (2024-02-27): Michel Fortin:
MFXUI is a collection of helpers to build user interfaces for macOS, iOS, and tvOS using in a declartive style similar to SwiftUI. It builds hierarchies of AppKit or UIKit views and has some provisions for bindings. In the most cases, MFXUI uses the system views unchanged, only adding extension methods and initializers (many of which are provided by UXKit).
5 Comments RSS · Twitter
I don't think the name “InterfaceBuilder” is apt at all, because IB is a visual tool, more like SwiftUI previews (which doesn't really work, but this thing completely lacks).
Most people I know are building UIKit/AppKit things in code for years using helper frameworks like that. I don't even think that the result builders are necessary (or even that useful) here in any way (they are to a certain part an optimization specific to SwiftUI).
One of the best things in SwiftUI is that it dropped AutoLayout IMO (in particular on macOS). Bindings (like many other must-have AppKit features like formatters in controls) never made it to iOS. Which made sense in a restricted env like the first iPhone, but now hurts iPadOS (and iOS in general) a lot.
@Helge Yeah, I haven’t found it necessary to add result builders to my system. I think auto layout is fine—at least for most stuff—once you have easier tools for using it. I’ve not been a fan of bindings, because of debuggability but mostly because the functionality is limited and half of the system of hidden. I think part of the problem with the AppKit controller classes is that they are so dependent on (and limited by) bindings.
I wrote one of these for AppKit to reduce boilerplate code in my Mac apps. While mine isn’t as polished as this it’s still makes us development much faster than coding it directly using AppKit. Yes, no visual previews like SeiftUI but still fun to work with.
@Helge The API was entirely built in Playgrounds with live preview turned on, to make it feel just right. While it does lack live feedback now, my hope for the future is that I can somehow put together a more dynamic workflow based on something like this: https://swiftjectivec.com/Using-Xcode-Previews-for-UIKit/
