![]() ![]() That brings me on to two other concerns with Catalina and what we have been told about it so far: notarization and security. I’m not convinced that will lure many to upgrade early. But for most users, the major trade-off coming with Catalina is going to be whether its better security and speed outweigh the loss of all 32-bit software. If there were other compelling reasons to upgrade, as there are in Mojave’s much-improved APFS, maybe. This isn’t because Mac users are stick-in-the-muds, but because many are in complex situations which have to wait for key software and other requirements to change before they can upgrade.Īssuming that half of you here were to upgrade to Catalina by the start of 2020, which could be optimistic, would I want to invest my time and effort into building apps which the other half couldn’t run until they too had upgraded? Read the comments to articles on this blog and you’ll find that there are plenty of advanced users here, with Macs perfectly capable of running Mojave, who are still running High Sierra or Sierra, and a few who are back on El Capitan or earlier. macOS users are generally rather slower to upgrade to the latest operating system than are iOS users. The real sting comes in system requirements: the moment that you choose to use SwiftUI, your app can’t run on Mojave or earlier, it’s committed to Catalina. That’s fully supported, thankfully, but is it worth the effort of handling two very different interface class libraries with contrasting approaches? So if I were to port any of my apps to the brave new interface of SwiftUI, in pretty well every case I’d have to embed at least one scrolling text view from AppKit. 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. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |