Every year, Apple promotes its Worldwide Developers Conference, which this year gathered 6000 atendees from more than 70 countries. Sice I am attending, I am using this blog to publish my completely disorganized and not-for-public-consumption notes.

What’s new in Xcode

Setting up a package in a project requires only setting a dependency up in the Dependencies section

Packages can be used to narrow down searches.

Package integration is built upon Xvodes source control

It is now possible to stash changes. How does that work? Same for cherry pick.

Design tools. Xcode supports visualizing iPad apps as they would look like on a Mac. This works for both Dark and light themes.
Symbols can also be localized. For example, a fork and knife symbol for the USA could be localized to chopsticks for Korea.

When alternating between light and dark modes, some images may become hard to see. Xcode supports setting up variants of images so that different variants can be exhibited depending on whether one uses light or dark mode. This also applies to other components, such as buttons: the tint color may be set up to be different depending on whether one uses light or dark mode. Finally, environment overrides allow developers to test out the app at runtime without having to restart the simulation. This applies to stuff such as the text size, accessibility options and light vs dark mode.

Debugging. In the devices window, it is now possible to set up environmental conditions such as different temperatures and network conditions (for example, 2G, WiFi, 5g, etc).

Testing. Test plans.

Simulator. Stand alone watch apps can be deployed directly to the watch simulator.

The Xcode simulator is now built on top of metal. This improves the performance of the simulator and the apps running on it. Simulator boots become more than twice faster and it consumes considerably less cpu (9% of what it used to be, according to Apple).

SwiftUI. Editing + Building + Running = Just Editing

What’s new in Swift

ABI stability. ABI - Application binary interface. Specifies details of a program’s representation at runtime. With ABI stability, program and framework can be built with different compilers as long as it is at least Swift 5. There is also Module Stability. The combination of ABI stability and module stability allows the construction of frameworks that can be shared with and used by others in binary format instead of only source format. Kiev believes that this supports the integration of the Swift package manager within Xcode.

In the most current versions of the Apple platforms, there is a shared Swift runtime built into the OS. In this manner, the runtime does not need to be packaged with the app. This means that downloads and installations of apps will be much faster. In addition, the RTS can be optimized as part of the OS, which means that it is potentially subject to further optimization. Launch time overhead is reduced in Swift 5 because of the shared runtime. It is not clear exactly why theis cost disappears.

The compiler and runtime bridge types such as NSStrings to String. The latter are native and the default encoding has been changed from UTF-16 to UTF-8. The goal here is to have C-like performance for string processing.

Language Search Protocol (LSP) - SourceKit-LSP

Some new features:

• single expression closures without the need for an explicit return.
• default values for initializers are now synthesized for initializers that do not assign values to all the properties of a struct. Before, there were only two synthesized initializers: the one that assigned to every field and the empty one.
• string interpolation is now faster. Interpolation can now be personalized. ExpressibleByStringInterpolation protocol is key here.
• opaque result types. This is enforced by the Swift runtime. “var body: some View {…}”. What does the “some” mean?
• property wrapper types. An annotation can associate a property wrapper to a property. A wrapper can, for example, persist the new value for a property. These wrappers are defined by means of generic properties that specify setters and getters for values of any type T.
• embedded DSLs into Swift. SwiftUI is built upon this.

SwiftUI

Defining a UI in SwiftUI involves two parts: the actual UI definition and the code to show the live preview of the UI. The preview can also pass test data to be presented. Previews can be organized in groups to show different visualization using different sets of test data.

View is a protocol. Requires only a single property: body. Collectively, the state variables in the module are the Sources of Truth for the application. Every property is either a Source of Truth or a Derived Value. Sources of truth are declared by including a @State property.

One of the greatest problems of UI programming is managing the ordering in which events happen, whether they can happen in duplicate, and how to deal with sequences that do not comprise the happy path. For example, zoomIn, enhance, completion, and zoomOut is the expected sequence of events, but maybe they happen out of order or the user it mashing the enhance button. SwiftUI solves this by encoding the expected ordering within the body property. Meta Animations within SwiftUI are interectable and interruptable.

HStack and VStack: organize items within the view horizontally or vertically. ZStack superimposes views. Looks a lot like Java’s old layout managers.

iPad Apps on a Mac

The iOS simulator has a complete copy of the iOS stack, including frameworks and services at every level.

The stacks for building Mac and iOS apps are very similar. iOS basically has UIKit instead of AppKit, Notifications where MacOS don’t have any, ARKit because it only makes sense for a mobile device, and separate blocks for photos and databases.

When to consider iPad apps for Mac? For example, as a cheap way to update an old Mac app that is not up-to-date with its iPad counterpart. Also, to replace a Mac built that is not build on native tech. iPhone-only apps, on the other hand, are not good candidates for this. This is the case for apps that are optimized for the very small screen or for apps that make use of mobile features, e.g., AR apps or watch apps that have an iOS counterpart.

.xcframework framework are multiplatform frameworks.

Mac apps differ from iPad apps in a number of ways. They have a menu bar, window management (including the three buttons on the upper left part of the window), scrollbar, preferences as an option in a menu (in the iPad, it is a setting in a Settings menu). In addition, some Mac apps use the touchbar. If the iPad uses certain components, they will be mapped to touchbar items. Location is much more limited since a Mac does not have a GPS. Some features have to be explicitly taken care of when porting for the Mac, in order to have a better user experience, such as the Mac icon, menu, touchbar support, among others.

Three kinds of APIs one has to worry about when porting: APIs that are available for both platforms, APIs that have been mapped to the Mac, and APIs that are unavailable.

Bundles for iOS are flat whereas they are multi-level on the Mac.

Creating Independent Watch Apps

Before watchOS5, the watchOS used to be embedded within the iOS app. The iOS app no longer includes the watchOS app. The latter will not impact the iOS app’s download size. watchOS apps will be downloadable from the app store. Downloads will thus be smaller and the binary size as well. This is in addition to any improvements stemming from the Swift shared runtime, not bundled with the apps anymore.

It is possible to make old apps independent of the iPhone by simply ticking a box on the general project properties. In addition, for new applications, now there are two options when creating a new watch project: regular watch project and watch + iPhone.

Debugging in the simulator is up to 10x faster. On the device, it is up to twice faster.

The watch is now a target for push notifications and can receive both user-visible and background notifications.

Swift Playgrounds 3

Swift playgrounds now supports modules, which make it possible to break a Swift playground in multiple files. Code in one module is accessible in all the others within the same project as long as it is marked as public. Swift playgrounds also supports ARKit.

Additional new features: module modes (none, which is just like old playgrounds, limited, where there is just one module which may be comprised of multiple files, but preexisting modules can be used, full, where it is possible to define multiple modules), code completion, which now works with both main and shared files, localized code comments, Swift cutscenes. For code completion, there are multiple levels at which code completion can be used. This is defined by directions in the Manifest.plist.

Localized comments are identified by the “localizable-zone” directive. Each zone is uniquely identified. The multi-language comments are store in a specific file whose name is predefined.