WWDC22: AppIntents framework and the future of Swift in Apple’s developer tools

With the release of the AppIntents framework @ WWDC22 for Siri Shortcuts, Apple has reached a major milestone in their transition to fully positioning Swift as an integral part of their developer ecosystem. Not only have they transitioned from Objective-C to Swift as a first class citizen in terms of programming languages and SDKs, but they are now moving their development tooling away from Xcode and Property List files, to statically analyzed Swift code. Even though Swift was released in 2014, it wasn’t until 2015 that Apple has been going all in with Swift replacing their development tooling. Let’s review the timeline of Apple’s milestones in their transition to see how Apple laid the groundwork for making AppIntents possible.

• 2015: Swift is released as open source along with the Swift Package Manager as first official dependency manager Apple has provided, supporting C, Objective-C, C++ and Swift libraries, as well as compiling on Linux. Xcode project files could be manually generated from the command line to integrate into existing projects and provide IDE support for packages. This effectively deprecated third party dependency managers like CocoaPods and Carthage.
• 2018: Create ML is released as the first Swift framework bundled with Apple’s operating systems. This new framework was not a replacement or alternative to an existing Objective-C framework, like the Swift Standard Library was for Objective-C’s Foundation. From this point forward the status quo of Objective-C being a requirement for iOS development, and Swift being optional was forever altered. Now using Swift was a requirement if one wanted to use all of Apple’s SDKs.
• 2019: Xcode adds first class support for fetching and building Swift Packages, as well as opening them without needing to manually generate an Xcode project file.
• 2019: SwiftUI is released with significant changes to the Swift compiler to support the SwiftUI DSL, replacing Interface Builder, Storyboards and XIB files, all property list based formats.
• 2021: Swift Playgrounds 4 is released with the ability to create iOS apps that can be opened with Xcode, replacing Xcode project files. The new .swiftpm bundle contains a Swift Package file that declares a .iOSApplication target exclusive to Swift Playgrounds and Xcode, instead of .executable or .library used with the open source SwiftPM version.
• 2022: Swift 5.6 package plugins and build tools replaces Xcode custom run script build phases, allowing SwiftPM based frameworks and apps to run custom command line tools and scripts without using Xcode project files.
• 2022: AppIntents is released with a Swift API that is statically analyzed by the Swift compiler to generate Siri Intents metadata, previously generated from a custom Property List file.

This new AppIntents framework and App Extension effectively replaces the Siri Intents framework. While this is not the first case of a Swift framework replacing an Objective-C one, as SwiftUI replaced UIKit and AppKit years before, it is the first time Xcode’s Property List model definition files have been replaced with Swift code that is statically analyzed at compile time. Unlike SwiftUI that replaced UIKit code and Interface Builder files, AppIntents generates metadata binary files from Swift code, similar to how the older Intents framework did with their property list definition files. Furthermore, while SwiftUI code is executed and evaluated at runtime to dynamically build the user interface, a significant portion of the AppIntents API is designed to be statically analyzed and never executed at runtime. The ExtractAppIntentsMetadata tool used with AppIntents in Xcode is effectively “compiling” Swift source files into something that is metadata and not executable code, similar to how Swift Package files were used to generate Xcode projects (themselves property list based of course) and the intermediary JSON representation used for building the packages. This major milestone in Apple’s adoption of Swift beyond just being the preferred programming language and new frameworks has significant repercussions for the future of Apple’s other custom property list definition files used in Xcode. The most widely used property list files for declaring model metadata with Xcode are CoreData’s Data Model, Siri Intents definitions, SpriteKit and SceneKit scenes, and iOS Settings bundle.



Xcode did have the ability to generate Swift code from CoreData Model and Siri Intents definitions, but the source of truth was still a property list with a custom editor in Xcode. Now with AppIntents, your Swift code is the only source of truth for your logic, model, App Extensions and UI. With the current trend I’m seeing at Apple, I would expect to see CoreData and Settings property list files converted to Swift DSL in the near future. In CoreData’s case, the compiler output would be the same proprietary binary format it currently uses. The only change required would be modifying the Core Data Model compiler to statically analyze Swift types in addition to their custom property list format. The success of AppIntents adoption will inform Apple on how to proceed with their strategy of building developer tooling with Swift. Unlike CoreData which is widely used, the Siri Intents framework has seen limited adoption as the investment in developer hours might not always justify the the perceived benefits of creating an app extension and learning a new framework. AppIntents makes it quick and simple to quickly build new functionality that would be degrees of magnitude longer with the older property list based Intents definitions. Let’s hope it sees wide adoption that motivates Apple to continue on the path its on to make Swift front and center for their SDKs and Developer tools.