{"id":36502,"date":"2022-07-13T15:51:52","date_gmt":"2022-07-13T19:51:52","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=36502"},"modified":"2024-02-27T10:41:49","modified_gmt":"2024-02-27T15:41:49","slug":"interfacebuilder-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/07\/13\/interfacebuilder-swift\/","title":{"rendered":"InterfaceBuilder.swift"},"content":{"rendered":"

Maximilian Mackh<\/a> (tweet<\/a>):<\/p>\n

\n

InterfaceBuilder.swift lets you quickly build complex UIKit layout in code, speed up native app development and is completely open source.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

Since SwiftUI (plus new APIs) come bundled with OS releases, this is a recipe for broad range of inconsistencies.<\/p>\n<\/blockquote>\n\n

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.<\/p>\n\n

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<\/code> 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.<\/p>\n\n

Apple went a different way. But this is not<\/a> 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.<\/p>\n\n

Previously:<\/p>\n