Wednesday, July 13, 2022 [Tweets] [Favorites]

InterfaceBuilder.swift

Maximilian Mackh (tweet):

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:

5 Comments

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.

https://github.com/dagronf/DSFAppKitBuilder

Benedict Cohen

I recently started putting together something similar. I’ve built numerous iterations since 2019.

https://github.com/benedictc/sweetui

Maximilian Mackh

@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/

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment