Late last year, Bloomberg published a rumor that Apple was working on a new cross-platform application framework. This rumor was later confirmed by Apple at WWDC, and announced to be arriving to macOS Mojave in the form of ported iOS apps such as News, Stocks, and Voice Memos.
Though initially misunderstood as a merge of the two platforms and app ecosystems, we now understand it to be a unification of the underlying frameworks used by developers to create their apps. AppKit, used to create macOS applications, has lineage running all the way back to NeXT. UIKit, used to create iOS apps, has the benefit of building off the same foundation, alongside a fresh (circa 2007) re-start and focus on touch devices. This results in situations like NSColor and UIColor, two different APIs for handling the same thing.
As a consequence, supporting the Apple ecosystem requires investment into not one, but two separate sets of technologies. Code written to support one device may require time and effort spent porting to support another. Despite Apples immense success with the Mac since the Intel transition a decade ago, it has not seen commensurate success with the Mac App Store compared to iOS. It’s not unreasonable to argue that having to support these different frameworks has helped to discourage the legions of iOS developers from bringing their products to the Mac.
The ability to deploy a single code base to multiple target platforms is one of the core value propositions of Qt. For a third party framework to support deployment of the same code base to both iOS / Mac, when such a thing is not possible with Apple’s own framework, is noteworthy. Creating a unified framework that works across the whole device ecosystem is a good and necessary next step for Apple. I suspect that the points of similarities between Qt and Apple’s new framework are about to become even more interesting. DaringFireball published some interesting “scuttlebutt”, and catching my attention in particular was the following:
"... it sounds like a declarative control API. The general idea is that rather than writing classic procedural code to, say, make a button, then configure the button, then position the button inside a view, you instead declare the button and its attributes using some other form."
Qt Quick uses a declarative markup language called QML, one better suited for collaboration with designers in a post-iPhone era of app design than the C++ / Widgets of old. While the Widgets era had it’s own design tool (singular), it still felt targetted towards programmers. The design tool would output to an XML format whose audience consisted of two: the uic (“user interface compiler”) invoked by qmake and the design tool itself, while QML is human readable and editable without a design tool. The UI design tools for Qt Quick seem better equipped to bring designers into the product development process, treating the contributions of design / UX as equal to the programmer’s. This concept of elevating the designer’s role in product development is well illustrated by a short story I came across a few years back, The Qt/QML User Story Redux.
Apple’s own tooling is currently much closer to the C++ / Widgets era of Qt, than the modern Qt Quick era. Storyboards, one of the design tools used in iOS development, outputs machine-readable resources rather than editable code. User Interfaces must either be implemented using the Objective C / Swift APIs, or using the available design tools. Indeed, many skilled developers may prefer using the Objective C / Swift APIs to skip the cognitive overload of context switching between design tool and coding. In creating a unified framework for macOS / iOS / tvOS / watchOS / etc, they need to sell developers on the value proposition of both beginning new projects, as well as porting over older code bases. The new tooling has to be better, not neutral or worse.
From a Qt development perspective, I’m fascinated to see what a declarative control API from Apple looks like. They have a history of strong guidance in both user experience (see the Human Interface Guidelines), and in the patterns used to architect apps. Qt Quick provides the fundamentals and the freedom to do whatever you want, leaving it to the developer to choose the appropriate architecture. Some architectures have been proposed by the community, but as of yet no strong consensus has emerged that I am aware of. Meanwhile, iOS developers have MVC (Model-View-Controller), know how to use Segues to power navigation and sharing of resources between screens (aka View Controllers), and generally have a shared vocabulary on how to structure their apps.
Should Apple move to a declarative control API, they have an opportunity to create tooling and development workflows that bring in UI / UX designers as equal collaborators. Their focus on Swift in education, and Playgrounds as a tool for learning shows an interest in inviting folks beyond the Computer Science crowd to create apps. I would like to see both Apple and Qt finding inspiration from each other’s efforts; creating a more accessible development environment for Apple, and suggesting new architectures and design patterns for Qt Quick.