At WWDC20, Apple announced many exciting updates for both App developers and SDK developers. The team at OneSignal has been hard at work digging into what the features will mean for our users, as well as Apple developers in general.
With new ways for businesses to reach their users through App Clips and iOS Applications on Mac, as well as a new way for SDK developers to distribute their products through XCFrameworks in Swift Package Manager, 2020 is shaping up to be an exciting year in the world of Apple development.
iOS Applications on Apple Silicon Macs
Apple Silicon Macs use the same architecture as iOS devices meaning iOS applications will run on a Mac using the same binary as iOS. Apple is leveraging their Mac Catalyst infrastructure to make iOS applications available for Apple Silicon Macs by default and must be explicitly made unavailable by the developer. This will further unify the Apple ecosystem and simplify the App development process.
The push notification experience for these Apps will feel like any other MacOS Application, and will take advantage of the wonderful push improvements to the MacOS notification center introduced in MacOS 11 Big Sur.
Here's an example of an iOS App icon in the Mac dock with a notification badge.
Push Notifications in App Clips
Apple announced App Clips at WWDC20. App Clips allow users to quickly install a small, single workflow focused version of your Application on the fly. App Clips support push notifications and introduce the “Ephemeral” push permission.
The ephemeral push notification permission is enabled automatically without a prompt to the user, but expires after 8 hours. When the ephemeral permission is enabled, your App Clip banner will include a message that your App can send notifications and users have an option to disable the permission.
To use this permission type in the info.plist for your App Clip add NSAppClipRequestEphemeralUserNotification to the NSAppClip dictionary and set its value to true. Note that App Clips are still able to prompt for the traditional permanent push permission, but the App Clip will be uninstalled automatically after a few days of inactivity.
Supporting App Clips will require a few changes for a push server. If your Apps are using Certificate Based Authentication for APNs (using .p12 certificates), you will need a separate certificate for your App Clip since it has a different bundle identifier than the parent application.
Advanced App Clip Experiences allow you to customize the content of your App clip and are invoked with a unique URL configured in App Store Connect. If your App Clip supports multiple experiences you will want to target your push notifications to the correct experience. This can be achieved by setting your experience’s invocation URL as the value for the “target-content-id” field in the APNs payload. The Target Content ID field has been added to the OneSignal dashboard to support this feature.
App Clips create a few limitations for push functionality that users should be aware of. App Clips do not support bundled extensions, including Notification Service Extensions. Notification Service Extensions allow you to modify the contents of a remote notification before it is delivered to the user. They can be used to add categories (buttons) to your notifications on the fly, and add media attachments such as images to your remote notifications.
Hopefully Apple will allow Notification Service Extensions in the future to keep App Clip push notifications as rich as possible. Additionally, App Clips do not allow background modes which will limit the ability of your App to use silent notifications to update its content in the background.
Despite the Xcode beta being available for a few months now Apple is not currently accepting App Clips in App Store Connect so we have not been able to fully test App Clip Experiences via Test Flight or configure advanced experiences. So for the time being, we are eagerly awaiting the availability of App Clips and the release of Apple Silicon Macs later this year!
With Apple's release of Xcode 12, Swift Package Manager supports the distribution of XCFrameworks. Now, SDK developers can distribute closed source pre-built binaries natively in Xcode.
Apple announced Xcode support for Swift Package Manager at WWDC19, and since then it has quickly become one of the most popular dependency managers for iOS. However, SwiftPM had restrictions that limited its use by SDK developers such as its the inability to distribute closed source binaries, and project structure requirements for supporting mixed language libraries.
Before Xcode 12 and Swift tools 5.3, Swift Package Manager only had the ability to distribute open source libraries or executables. This meant library developers who could not open source their projects were stuck with traditional options like Cocoapods or Carthage.
Additionally, Swift Package Manager’s lack of support for mixed Swift and C-language targets, means that SDK developers might need to restructure their code base to work around the programming language restriction. This requirement conflated the build process and the distribution process of a library in a way that is not present with other distribution technologies.
XCFrameworks, which were released with Xcode 11 at WWDC19, are a distribution format that bundles code for multiple architectures, similarly to a “fat framework” created via lipo. However, XCFrameworks are even more powerful because they can contain code for separate platforms that share the same architecture. For example Mac Catalyst and iOS Simulators both want to use the x86_64 architecture. Supporting Mac Catalyst and iOS Simulators in a single fat framework was previously not possible without dropping Swift support.
By using XCFrameworks in Swift Package Manager SDK developers are able to release their package as a closed source binary making Swift Package Manager a viable distribution platform for developers who are unable to share their source code. It also separates the build and distribution process for the project allowing the project structure to be completely independent of Swift Package Manager.
