It’s one of the fundamental parts of the existing class library AppKit, but – for the moment at least – doesn’t exist at all in SwiftUI. Most of my utilities feature, somewhere among their windows and views, a scrolling text view, in which results are displayed in text form. The snag with SwiftUI at present is that, as far as macOS is concerned, it’s too incomplete to do anything useful. The former are loaded in Storyboards and ‘nibs’ which Xcode creates from the windows, views, controls, etc., which you assemble graphically the latter are compiled from source code files and only come into existence when that code is running. Previously, there was a clear distinction between Interface Builder (IB) with its GUI, and interface objects created using code. In Xcode, this isn’t just implemented in code, but you can use a graphical interface designer as well. For an app which is going to run on two or more of those operating systems, that seems an excellent solution. In essence, the programmer tells the runtime what they want, and leaves frameworks to implement that as appropriate to the platform. It’s a new declarative way of building the interface to apps, whether that build is going to run on macOS or any of the other operating systems in Apple’s growing stable. What they tell us about Apple is significant. Last week this came with two of the more important announcements for macOS: notarization and SwiftUI. It’s only when the hype of events like WWDC have faded and you get the chance to look at what is really happening that a bigger picture emerges.
0 Comments
Leave a Reply. |