Stories by Geoff Hackworth on Medium

WWDC 2022: 10157, What’s new in SF Symbols 4

Adaptivity

Visualizing sizes, layout and margins in Adaptivity v9.5 on 12.9" iPad Pro

This is very useful to see how apps which support multitasking behave with the new Stage Manager feature on iPadOS 16.

There are also views for browsing System Colors, System Fonts and System Materials, and a view for exploring iPadOS Pointer Interactions. In iOS/iPadOS 15 you can also configure UISheetPresentationController options for modally-presented view controllers.

The app is a universal purchase and includes the Mac Catalyst version. On macOS 11 and later, this is “optimised for Mac” with native controls and does not scale content. If you are an iOS developer or designer, I’m sure you will find Adaptivity very useful. Testimonials, more screenshots and information on all the features is available on my web site.

SF Menu Bar

SF Menu Bar is a menu bar app for the Mac which is powered by the same SF Symbol data as Adaptivity. When run on macOS 13.3 beta, it will show symbols added in iOS 16.4/macOS 13.3. More information is available on my web site.

SF Menu Bar v1.9 running on macOS 13.2.1

(I’m not running macOS 13.3 beta, so this screenshot does not show the iOS 16.4 data set as being available.)

SF Symbols Changes in iOS 16.1

Geoff Hackworth — Thu, 29 Sep 2022 17:02:50 GMT

Introduction

When examining the iOS 16.1 simulator in Xcode 14.1 beta 3, I noticed that there had been changes to SF Symbols. A lot of changes! 311 symbols have been added and 22 symbols have been renamed. iOS 16.1 has now been publicly released and there were no symbol changes after beta 3.

There are now eleven different sets of symbols to consider:

SF Symbols v1.0 available in iOS/iPadOS/tvOS/Mac Catalyst 13.0, watchOS 6.0 and macOS 11.0
SF Symbols v1.1 available in iOS/iPadOS/tvOS/Mac Catalyst 13.1, watchOS 6.1 and macOS 11.0
SF Symbols v2.0 available in iOS/iPadOS/tvOS/Mac Catalyst 14.0, watchOS 7.0 and macOS 11.0
SF Symbols v2.1 available in iOS/iPadOS/tvOS/Mac Catalyst 14.2, watchOS 7.1 and macOS 11.0
SF Symbols v2.2 available in iOS/iPadOS/tvOS/Mac Catalyst 14.5, watchOS 7.4 and macOS 11.3
SF Symbols v3.0 available in iOS/iPadOS/tvOS/Mac Catalyst 15.0, watchOS 8.0 and macOS 12.0
SF Symbols v3.1 available in iOS/iPadOS/tvOS/Mac Catalyst 15.1, watchOS 8.1 and macOS 12.0
SF Symbols v3.2 available in iOS/iPadOS/tvOS/Mac Catalyst 15.2, watchOS 8.3 and macOS 12.1
SF Symbols v3.3 available in iOS/iPadOS/tvOS/Mac Catalyst 15.4, watchOS 8.5 and macOS 12.3
SF Symbols v4.0 available in iOS/iPadOS/tvOS/Mac Catalyst 16.0, watchOS 9.0 and macOS 13.0
SF Symbols v4.1 available in iOS/iPadOS/tvOS/Mac Catalyst 16.1, watchOS 9.1 and macOS 13.0

For a detailed list of symbols that were added or renamed in earlier iOS versions, see my previous articles:

SF Symbols Changes in iOS 14.0 (SF Symbols 2.0)
SF Symbols Changes in iOS 14.2 (SF Symbols 2.1)
SF Symbols Changes in iOS 14.5 (SF Symbols 2.2)
SF Symbols Changes in iOS 15.0 (SF Symbols 3.0)
SF Symbols Changes in iOS 15.1 (SF Symbols 3.1)
SF Symbols Changes in iOS 15.2 (SF Symbols 3.2)
SF Symbols Changes in iOS 15.4 (SF Symbols 3.3)
SF Symbols Changes in iOS 16.0 (SF Symbols 4.0)

The purpose of this article is to describe what has changed in SF Symbols in iOS 16.1, not how to write code to use the new features. The “Resources” section towards the end of this article has links to some WWDC videos and blog posts which explain how to use SF Symbols.

SF Symbol Browsing Apps

When this article was first written, 29th September 2022, the link to Apple’s own SF Symbols Mac app on the SF Symbols 4 page hadn’t been updated since iOS 16.0 beta 2 (version 4.0 build 76.1). That was updated on 26th October 2022 to version 4.0 build 80 and includes all 4491 symbols included in iOS 16.1 and macOS 13. As of 29th October, the link on the Design Resource page is older (version 4.0 build 78) and only includes the 4,180 symbols that were included in the released version of iOS 16.0.

Apple’s SF Symbols Mac app v4.0 (build 80) has 4,491 symbols

My own Adaptivity app is a tool for iOS developers and designers, and one of its many features is a very comprehensive view to browse SF Symbols. It can view any of the SF Symbol data sets that your device supports and will show symbol names that are valid for that data set. It will not show a newer name for any symbols that have been renamed in a later version.

I take great pride and invest a lot of time and effort in keeping Adaptivity up to date. Since SF Symbol names are just strings, v9.1.1 of Adaptivity (released on 1st October 2022), already supports viewing all 4,491 symbols on a device running iOS/iPadOS 16.1 beta 3 or later. The iPhone and iPad screenshots in this article were taken from this version. The app is a universal purchase and works on iOS/iPadOS and Mac Catalyst.

iOS 16.3b3 System Images ‘All’ category and data set chooser menu in Adaptivity v9.1.1 on 12.9" iPad Pro

If you want instant access to the symbol names and unicode characters right from the menu bar on your Mac, check out SF Menu Bar. Version 1.10.1 was released at the same time and supports all the new symbols when run on macOS 13 beta 9 or later.

Changes in SF Symbols 4.1

iOS/iPadOS 16.1 beta 3 was released on 27th September 2022. There are far too many symbol changes to list them all in detail. The changes fall into several different categories:

New symbols 311 new symbols have been added; some have restricted usage
Renamed symbols 22 existing symbols have been renamed
Localized variants 40 existing symbols have gained Arabic localizations
New category there is a new ‘Automotive’ category

New Symbols

There are 333 symbols in the ‘What’s New’ category in SF Symbols v4.1 but some of them are renamed versions of existing symbols rather than completely new symbols (see below for more information).

iOS 16.3b3 System Images ‘What’s New’ category in Adaptivity v9.1.1 on 12.9" iPad Pro

A total of 311 symbols were added in iOS 16.1 beta 3. Adaptivity’s optional ‘Availability’ annotation (selected form the Info icon in the bottom right) adds a small 16.1+ annotation to symbols which are new in iOS 16.1. The lowest version number for which annotations are shown is also configurable (this helps cut down on the visual clutter now that there are so many symbols and data sets).

Adaptivity also has an ‘Added’ smart collection which includes just the symbols that have been added in the data set you are viewing:

iOS 16.3b3 System Images ‘Added’ smart collection in Adaptivity v9.1.1 on 12.9" iPad Pro, page 1 of 4

iOS 16.3b3 System Images ‘Added’ smart collection in Adaptivity v9.1.1 on 12.9" iPad Pro, page 2 of 4

iOS 16.3b3 System Images ‘Added’ smart collection in Adaptivity v9.1.1 on 12.9" iPad Pro, page 3 of 4

iOS 16.3b3 System Images ‘Added’ smart collection in Adaptivity v9.1.1 on 12.9" iPad Pro, page 4 of 4

Renamed Symbols

22 existing symbols have been renamed in iOS 16.1 beta 1. For apps that support earlier iOS versions, the older names must be used. When running on iOS 16.1 and later, either name can be used.

Most of the renames were to replace homebutton with gen1 for iPhone and iPad symbols. Equivalent gen2 and gen3 iPhone symbols and iPad gen2 symbols have been added.

When the right sidebar is enabled, Apple’s SF Symbols Mac app shows availability information and, if applicable, the deprecated name for the selected symbol. Adaptivity is smart enough to display the latest names suitable for the data set you are viewing; it will not show the new name for any symbols which were renamed in later data sets.

Adaptivity also has a ‘Renamed’ smart collection which shows all the symbols that have been renamed in the data set you are viewing:

iOS 16.3b3 System Images ‘Renamed’ smart collection in Adaptivity v9.1.1 on 12.9" iPad Pro

A long press on a symbol shows a larger image in a context menu preview, along with the symbol name, availability, any deprecated names, and supported rendering modes. You can quickly copy the name to the clipboard (and, thanks to Universal Clipboard, this will be available for pasting into your code on another device). For symbols that have been renamed in the data set you are viewing (or earlier), choose which version to copy. The List view also shows the availability information and any deprecated names in each table cell:

iOS 16.3b3 System Images ‘Renamed’ smart collection, context menu and List view in Adaptivity v9.1.1 on iPhone 14 Pro

Restricted Symbols

The number of restricted symbols has increased from 289 in iOS 16.0 to 316 in iOS 16.1 beta 3. The vast majority of the additions are the gen2 and gen3 iPhone and gen2 iPad symbols.

In Adaptivity and Apple’s SF Symbols app, an ⓘ button indicates a symbol is restricted. Tapping the button shows an alert explaining how the symbol can be used. Adaptivity also has a ‘Restricted’ smart collection which includes just the restricted symbols. There is also an ‘Unrestricted’ smart collection which includes just the symbols that are not restricted.

iOS 16.3b3 System Images ‘Restricted’ smart collection in Adaptivity v9.1.1 on 12.9" iPad Pro

Localized Variants

As far as I can tell, the only changes to localizations were to add Arabic versions of the 0.circle, 0.circle.fill, 0.square, 0.square.fill (and similarly for 1–9) symbols. That’s 40 in total.

Long pressing a symbol with a language localization reveals a “Show Localizations” context menu action which presents another view showing the localized variants. If the ‘Availability’ annotation is enabled, each variant will show the iOS version in which it was first available.

iOS 16.3b3 System Images ‘Language Localized’ smart collection in Adaptivity v9.1.1 on 12.9" iPad Pro

New Category

Whilst updating my data files for Adaptivity and SF Menu Bar I noticed that there is a new ‘Automotive’ category with 272 symbols. A lot of the new symbols in iOS 16.1 beta 3 are in this category.

iOS 16.3b3 System Images ‘Automotive’ category in Adaptivity v9.1.1 on 12.9" iPad Pro

Resources

Apple

WWDC 2022: 10158: Adopt Variable Color in SF Symbols

WWDC 2022: 10157, What’s new in SF Symbols 4

Adaptivity

Visualizing sizes, layout and margins in Adaptivity on 12.9" iPad Pro

This is very useful to see how apps which support multitasking behave with the new Stage Manager feature on iPadOS 16.

SF Menu Bar

SF Menu Bar is a menu bar app for the Mac which is powered by the same SF Symbol data as Adaptivity. When run on macOS 13, it will show symbols added in iOS 16.0/16.1 and macOS 13. More information is available on my web site.

SF Menu Bar v1.11 running on macOS 13.0

External Display Support versus Stage Manager on iPadOS 16

Geoff Hackworth — Thu, 22 Sep 2022 08:34:32 GMT

Introduction

Apple have provided support for connecting external displays to iOS devices for many years with their Lightning Digital AV Adapter and, for modern iPads with a USB-C connector, USB-C Digital AV Multiport Adapter. A full-screen non-interactive view controller can be displayed on an external display whenever the app is running in the foreground on the main device. This feature isn’t useful for many types of apps. Even when it could be useful, few apps go to the trouble of supporting it.

This article gives a brief overview of how apps can support an external display and then discusses a possibly undesirable interaction with Stage Manager on iPadOS 16 and possible workarounds.

UIScreen Notifications

Prior to iOS 13, UIScreen notifications were used to inform the app when an external display had been connected or disconnected. The app could create a new view controller and window attached to the external screen. This mechanism should not be used unless you need to support an external display earlier than iOS 13. If you need to do that, see Jordan Morgan’s tutorial on Supporting External Displays. In an article from 2018, I also wrote about the old API and why I felt it was useful to support an external display in some of my own apps: External Display Support on iOS.

Scene Lifecycle

The scene lifecycle added in iOS 13 brought support for multiple windows on iPad. The Application Scene Manifest section of the Info.plist declares whether the app can support multiple windows. It can also list one or more window scene configurations. There are separate sessions defined for the application and an external display. The app delegate method AppDelegate.application(_:configurationForConnecting:options:) is used in conjunction with the information in the Info.plist or can programmatically create its own scene configurations. See Apple’s article Presenting content on a connected display for more details.

Stage Manager

Then came Stage Manager on iPadOS 16. This dramatically increases the functionality of an external display connected to iPad models that support it (those with an M1 or later processor). The application window(s) for an app can be open on the internal or external display, but not both at the same time.

At the time of writing, Stage Manager support is still in beta and, frankly, quite buggy. Apple have changed the terminology for the previous external display support and now refers to it as “legacy” to distinguish it from Stage Manager.

The (Potential) Problem

On iPhone and iPad before Stage Manager, an external display will mirror the device unless the foreground app has explicit support for a custom view to show on the external display. A mirrored interface will be letter-boxed or pillar-boxed to fill the display without changing the aspect ratio. For example, a portrait iPhone appears tall and thin with black borders to the left and right when mirrored on a landscape 16:9 display.

With Stage Manager, an external display will show the Stage Manager interface whether Stage Manager is enabled or not on the internal display (but only when the iPad is docked in the Magic Keyboard at the time the external display is connected, it seems). However, when running an app on the internal display that supports the legacy external display feature, iPadOS 16 displays the full-screen non-interactive view on the external display. This keeps backward compatibility, but prevents Stage Manager from being used on the external display whenever such an app is running in the foreground on the iPad.

Apps which took advantage of the external display in the past are potentially worse citizens on iPadOS 16 because they override Stage Manager on the external display. I think it would be better if an app that supports the external display API did not prevent Stage Manager from being used on an external display.

iPadOS 16.1 disable Stage Manager support for external displays because it was not yet ready to be released. iPadOS 16.2 betas re-enabled it. On 16.2 beta 2 (and maybe beta 1), simply launching an app with an external window scene on the iPad would cause an instant Springboard crash. This seems to have been fixed in 16.2 beta 3.

Sample App

The following screenshots show the Info.plist for a sample app that accompanies this article. It uses storyboards for the window scenes, and supports multiple windows and an external display. Both the property list and the underlying XML source are shown.

Info.plist property list for a sample app which supports multiple windows and a the legacy external display API

Info.plist XML source for a sample app which supports multiple windows and a the legacy external display API

Note that the Info.plist key UIWindowSceneSessionRoleExternalDisplay is the key that was used prior to iOS/iPadOS 16. In the property list view, Xcode 14 labels this as “External Display Session Role (Legacy)”. For apps that need to keep supporting the external display prior to iOS/iPadOS 16 this older name must be used.

There is a new key UIWindowSceneSessionRoleExternalDisplayNonInteractive which Xcode 14 labels as “External Display Session Role Non-Interactive”. This can be used for an app which requires iOS 16. Apps run on iOS/iPadOS 16 will look for this new key and fall back to the old key if it is absent.

Solutions

I’m going to present a series of potential solutions to the problem of blocking Stage Manager on the external display when running an app on the internal display that supports an external display. They vary in their severity and flexibility.

Stop Supporting Legacy External Display APIs

The simplest solution to this problem is to simply stop supporting the legacy external display API by removing the Info.plist keys associated with the external display.

This is the nuclear approach and removes existing functionality from your users, including those who aren’t using or can’t use Stage Manager. They may not even using iOS/iPadOS 16.

If this approach is acceptable, the supporting code for the external display can also be removed (but it doesn’t have to be — it’s benign and unused once the Info.plist keys are removed).

Stop Supporting iOS/iPadOS 15 and Earlier

A slightly less extreme solution is to stop supporting external displays as above and also increase the minimum deployment version of your app to iOS 16. This is subtly different to the first solution as it allows users who do not upgrade to iOS/iPadOS 16 to continue using an older version of your app that does support an external display. However, users of the older version of the app are now effectively abandoned. This is probably not a viable solution for most apps.

Stop Supporting External Displays on iOS/iPadOS 16

A less extreme solution is to continue to support the legacy external display API prior to iOS/iPadOS 16 but to not support it on iOS/iPadOS 16. Since the new Info.plist key is checked first on iOS/iPadOS 16 it is possible to add an entry under the new name which contains an empty configuration.

Info.plist property list for an app which supports multiple windows and a the legacy external display API prior to iOS/iPadOS 16

Note that there needs to be an array beneath the new key otherwise a crash occurs when connecting an external display. It doesn’t matter if the array contains an empty dictionary or not. Using Xcode 14’s property list editor to remove the leaf nodes inside the first item in the array results in the following XML source (leaving an array containing an empty dictionary):

Info.plist XML source for an app which supports multiple windows and a the legacy external display API prior to iOS/iPadOS 16

The empty array of scene definitions under the new key prevents iOS/iPadOS 16 from instantiating a window when an external display is connected. This keeps Stage Manager visible on the external display when the app is open on the internal display. Older versions of iOS/iPadOS look for the old key and will continue to support the legacy external display API.

A disadvantage of this solution is that it also prevents the external display from being used on iPhone running iOS 16 and iPads running iPadOS 16 that don’t support Stage Manager.

Support External Display at Runtime

The best solution, in my opinion, is to make a runtime decision whether to support the legacy external display API or not. In my own apps that have external display support, I am adding an ‘External Support’ setting to control this. It defaults to enabled to preserve backwards compatibility except on iPadOS 16 where I think it is more desirable to not block Stage Manager on an external display. I don’t try to distinguish between iPad devices that can or cannot support Stage Manager. Since it is a setting, the user can choose to keep the old behaviour even on iPadOS 16 if they really want. It also allows the user to choose to mirror their display on older iOS versions if they don’t want the custom external display view for some reason.

How can we programmatically choose whether to support an external display? The solution lies in not providing a window for iOS/iPadOS to use on the external display.

For an app which uses a storyboard to define the external window scene, we can conditionally remove the storyboard in the App Delegate method when configuring the scene for an external display.

App Delegate code for conditional support for Legacy External Display support

This feels like even more of a hack than the empty Info.plist array, but it works on iOS 13 through 16 on iPhone and iPad.

The sample app that accompanies this article demonstrates this solution. It has a simple user interface which shows different coloured views for application and external windows. This makes it easy to distinguish between a mirrored interface and the custom external display view.

You will need to add your own Team in the Xcode project settings to run the sample app on a real device. An external display can be simulated with the iOS/iPadOS simulator but will be black unless a custom external display interface is available. The simulated display does not mirror the iPhone or iPad display. Use the I/O -> External Displays menu in the iOS simulator to add/remove a simulated external display. The release notes for Xcode 14.1 claim Stage Manager can be enabled in the simulator but I have been unable to get it to work.

The application window has a switch for toggling a UserDefaults setting that controls whether external display support should be enabled.

Main Application View for sample app on 11" iPad Pro simulator running iPadOS 16.0

Simulated External Display for sample app connected to 11" iPad Pro simulator

Due to the way that iOS/iPadOS caches scene configurations, a change to the app setting does not immediately affect the external display. The setting is only used when connecting an external display. After changing the setting, the user must disconnect and reconnect the external display to see a change in behaviour. Alternatively, killing the app from the task switcher and relaunching it will also re-create the external display scene.

If you run the sample app yourself in Xcode, be aware that changes to user defaults are not saved immediately. You need to return to the home screen before killing the debug session to ensure a change to the setting has been persisted to user defaults.

When turning the switch off, I tried to iterate over connected window scenes and destroy the one with an external role. Prior to iOS 16 this didn’t do anything (the external display remained visible). On the version of iPadOS 16.1 included with Xcode 14.1 beta 2 it just crashed Springboard (or one of the boards).

Conclusion

Adding support for external displays is reasonably straight forward, especially using the scene lifecycle introduced in iOS 13. The Stage Manager interface is a very different paradigm and isn’t really a good fit with the legacy external display API. I guess that’s why it’s called “legacy”.

I can understand why Apple chose to keep supporting the legacy mode, but I think most Stage Manager users would be surprised, perhaps even frustrated, if Stage Manager was not available on an external display when running certain apps on the iPad internal display. Apps which went the extra step to provide that support in the past are now effectively penalised and result in a worse user experience. The solutions discussed in this article explain how an app developer can remove support for the legacy external display or, with a bit more effort, allow the user to choose between the old and new worlds.

How iOS Apps Adapt to the various iPhone 14 Screen Sizes

Geoff Hackworth — Mon, 12 Sep 2022 15:26:56 GMT

Over the last few years I have written several articles showing how iOS apps built with different versions of Xcode would appear when run on iOS devices that didn’t exist when the apps were built. As a general rule, apps must build with the latest version of Xcode to opt in to seeing the native screen resolutions of new devices. Older apps would run on newer devices but appeared as letterboxed, pillar boxed and/or scaled versions of previous device sizes. This ensured that the old apps never ran at screen resolutions that didn’t exist when they were built.

In WWDC 2019: 224 Modernizing Your UI for iOS 13, the presenter discusses backward compatibility and stated:

In the past if we introduced new hardware with a new screen size, your apps were letterboxed. Well, we’re not going to be doing that anymore either. So, if you application is built against the iOS 13 SDK, then it will always be displayed at the native full-screen resolution of the screen.

This has only been true for iPad apps which support multitasking (and are expected to be able to dynamically adjust to different sizes). Full screen iPad apps and iPhone apps continue to behave differently on new devices depending on which version of Xcode was used to build them.

At their September 2022 event, Apple announced four iPhone 14 models:

iPhone 14 has the same screen resolution as iPhone 12, iPhone 12 Pro, iPhone 13 and iPhone 13 Pro: 1170×2532 pixels (390×844 points)
iPhone 14 Plus has the same screen resolution as iPhone 12 Pro Max and iPhone 13 Pro Max: 1284×2778 pixels (428×926 points)
iPhone 14 Pro has a slightly larger screen resolution compared to the iPhone 12/13 Pro: 1179×2556 pixels (393×852 points)
iPhone 14 Pro Max has a slightly larger screen resolution compared to the iPhone 12/13 Pro Max: 1290×2796 pixels (430×932 points)

Before examining the new iPhone 14 Pro and 14 Pro Max sizes, it’s worth examining the 14 and 14 Plus. As noted above, the non-Pro 14 models behave identically to earlier 12 and 13 devices with the same screen resolution. For more information on iPhone 12/13 (including the mini size) and some older devices, see my earlier article How iOS Apps Adapt to the various iPhone 12 Screen Sizes.

iPhone 14

The iPhone 14 has the same size and behaviour as the iPhone 12, 12 Pro, 13 and 13 Pro. The notch is narrower on the iPhone 13/14 than on the 12.

Standard Zoom

The iPhone 14 has a resolution of 390×844 points at its native resolution.

Xcode 14 build of Adaptivity on iPhone 14 running iOS 16.0 in portrait

Xcode 14 build of Adaptivity on iPhone 14 running iOS 16.0 in landscape

Display Zoom

When Display Zoom is enabled, the iPhone 14 shows a zoomed up resolution of 320×693 points. This is the same resolution as the iPhone 11 Pro and iPhone 12 mini with Display Zoom but the iPhone 14 has slightly different bar heights.

Xcode 14 build of Adaptivity on iPhone 14 running iOS 16.0 in portrait with Display Zoom

Xcode 14 build of Adaptivity on iPhone 14 running iOS 16.0 in landscape with Display Zoom

iPhone 14 Plus

The iPhone 14 Plus has the same size and behaviour as the iPhone 12 Pro Max and 13 Pro Max. The notch is narrower on the 14 Plus and 13 Pro Max than on the 12 Pro Max.

Standard Zoom

The iPhone 14 Plus has a resolution of 428×926 points at its native resolution.

Xcode 14 build of Adaptivity on iPhone 14 Plus running iOS 16.0 in portrait

Xcode 14 build of Adaptivity on iPhone 14 Plus running iOS 16.0 in landscape

Display Zoom

When Display Zoom is enabled, the iPhone 14 Plus shows a zoomed up iPhone 11 Pro resolution of 375×812 points but with slightly different bar heights.

Xcode 14 build of Adaptivity on iPhone 14 Plus running iOS 16.0 in portrait with Display Zoom

Xcode 14 build of Adaptivity on iPhone 14 Plus running iOS 16.0 in landscape with Display Zoom

iPhone 14 Pro

Standard Zoom

The iPhone 14 Pro has a slightly larger resolution of 393×852 points at its native resolution than the iPhone 14’s 390×844 points. Since this is a new resolution, apps must be built with Xcode 14 or later to see it. The status bar is 12 points taller than the iPhone 14 to account for the Dynamic Island. The total navigation bar height (including the status bar) is only 7 points taller. The bottom bar is unchanged.

Xcode 14 build of Adaptivity on iPhone 14 Pro running iOS 16.0 in portrait

Xcode 14 build of Adaptivity on iPhone 14 Pro running iOS 16.0 in landscape

Apps built with Xcode 13 or earlier will see a zoomed up iPhone 14 resolution of 390×844 points but with a 12pt taller status bar and navigation bar in portrait. NOTE: this extra 12pt only seems to happen on the simulator. Real iPhone 14 Pro devices report the same 143pt navigation bar and 47pt status bar as the iPhone 12 Pro and 13 Pro.

Xcode 13.4 build of Adaptivity on iPhone 14 Pro running iOS 16.0 in portrait

Xcode 13.4 build of Adaptivity on iPhone 14 Pro running iOS 16.0 in landscape

Display Zoom

When Display Zoom is enabled, the iPhone 14 Pro shows a zoomed up resolution of 320×693 points. It does not matter which version of Xcode the app is built with. This is the same resolution as the iPhone 11 Pro with Display Zoom but the iPhone 14 Pro has slightly different bar heights.

Xcode 14 build of Adaptivity on iPhone 14 Pro running iOS 16.0 in portrait with Display Zoom

Xcode 14 build of Adaptivity on iPhone 14 Pro running iOS 16.0 in landscape with Display Zoom

iPhone 14 Pro Max

Standard Zoom

The iPhone 14 Pro Max has a slightly larger resolution of 430×932 points at its native resolution than the iPhone 14 Plus’s 428×926 points. Since this is a new resolution, apps must be built with Xcode 14 or later to see it. The status bar is 7 points taller than the iPhone 14 Plus to account for the Dynamic Island. The total navigation bar height (including the status bar) is only 7 points taller. The bottom bar is unchanged.

Xcode 14 build of Adaptivity on iPhone 14 Pro Max running iOS 16.0 in portrait

Xcode 14 build of Adaptivity on iPhone 14 Pro Max running iOS 16.0 in landscape

Apps built with Xcode 13 or earlier will see a zoomed up iPhone 14 Plus resolution of 428×926 points but with a 12pt taller status bar and navigation bar in portrait. NOTE: this extra 12pt only seems to happen on the simulator. Real iPhone 14 Pro Max devices report the same 143pt navigation bar and 47pt status bar as the iPhone 12 Pro Max and 13 Pro Max.

Xcode 13.4 build of Adaptivity on iPhone 14 Pro Max running iOS 16.0 in portrait

Xcode 13.4 build of Adaptivity on iPhone 14 Pro Max running iOS 16.0 in landscape

Display Zoom

When Display Zoom is enabled, the iPhone 14 Pro Max shows a zoomed up resolution of 375×812 points. It does not matter which version of Xcode the app is built with. This is the same resolution as the iPhone 11 Pro but the iPhone 14 Pro Max has slightly different bar heights.

Xcode 14 build of Adaptivity on iPhone 14 Pro Max running iOS 16.0 in portrait with Display Zoom

Xcode 14 build of Adaptivity on iPhone 14 Pro Max running iOS 16.0 in landscape with Display Zoom

Conclusion

Apple have an excellent track record of providing backward compatibility with existing apps when new devices or versions of iOS are released. The iPhone 14 Pro models are no different. Bar heights when scaling do not match the original device in the simulators but do seem to match on real devices. To see the new resolutions of the iPhone 14 Pro and 14 Pro Max, apps must be built with Xcode 14 or later.

To add more confusion, it seems that iPhone 14 Pro devices running TestFlight builds made with Xcode 14 are behaving as if they were Xcode 13 builds. That is, the iPhone 12/13 Pro layout is being scaled to fill the larger screen of the 14 Pro devices. This explains why Simon Støvring was seeing different behaviour when running through Xcode or a TestFlight build. Hopefully that will be fixed soon, but Anton Sotkov has seen it in Xcode 14.0 and 14.1 beta 2, and with iOS 16.0 and iOS 16.1 beta 2.

Adaptivity

The screenshots in this article were taken from my Adaptivity app. It is primarily a tool to visualize the different window sizes, layout margins, readable content guides, bar heights and Dynamic Type sizes that a modern, adaptive, iOS app uses when running on different devices and iPad multitasking sizes. This makes it the perfect tool to investigate the changes in appearance and behaviour of new devices. The layout views are also a great way to see how Stage Manager behaves and how apps transition between the different fixed sizes when resized and, when crossing a threshold, flip between compact- and regular-width size classes.

The app also includes views for browsing System Colors, System Images (SF Symbols), System Materials, System Fonts and more. Full information on all of Adaptivity’s features is available on my web site.

View Controller Presentation Changes in iOS and iPadOS 16

Geoff Hackworth — Sun, 14 Aug 2022 13:09:02 GMT

Introduction

At the time of writing (14th August 2022), iOS and iPadOS 16.0 are still in beta with the most recent release being beta 5. Beta 6 was released on 15th August 2022. Other than introducing new device sizes, there have been relatively few changes in view controller presentations since the iOS/iPadOS 13.0 introduced the non-full-screen sheet modal presentation appearance and the default presentation mode changed to page sheet. My article from 2019 has all the details: View Controller Presentation Changes in iOS 13.

iOS 15 brought custom sheet presentations to UIKit and iOS 16.0 increased their flexibility with custom detent sizes. iOS 16.0 brings these to SwiftUI.

In iOS/iPadOS 16.0 there have been a few minor and one significant change in behaviour when presenting modal view controllers:

when the presenting view controller is in a regular-width environment on iPad, form sheets are slightly bigger than on previous iPadOS versions. This changed in beta 4. (If the presenting view has compact width, a form sheet presentation will adapt and fill the width, just like on iPhone.)
the height of the navigation bar in a non-full-screen, non-popover, modally-presented view controller is smaller than before (12 points smaller on iPhone and 6 points smaller on iPad). This change occurred in beta 5. Many thanks to Jordan Hipwell for discovering this and bringing it to my attention. He also discovered this has not (yet?) changed in SwiftUI. Edit: and it was just reverted in beta 6 🤦‍♂️
non-full-screen modally-presented double and triple column style split view controllers have a different appearance compared to iPadOS 13 to 15.

Apple have (had?) a good track record of providing backward-compatibility for apps built with earlier Xcode versions (i.e. linked against an earlier iOS version). Apps usually have to be rebuilt with the latest tools (i.e. linked against the latest iOS version) before they adopt new behaviours. Some of the changes discussed in this article only take affect after rebuilding, however others do not. Existing apps, already live in the App Store, will behave differently when run on iOS/iPadOS 16.0 in certain circumstances.

We have learned that our apps should be flexible, use layout margins and safe areas, respond to changes in Content Size Category (also known as Dynamic Type), and fit content to whatever size they happen to find themselves in.

That said, I think the way iPadOS 16 tries to provide backward compatibility when an Xcode 13 build of an app uses a default presentation of a double or triple column split view controller has a bug. It correctly fills the full width (matching earlier behaviour), but the width of the primary view controller is 80 points narrower. This issue and a workaround is discussed in more detail later.

Adaptivity

Most of the screenshots in this article were taken from the iOS/iPadOS 15.6 and 16.0 beta 5 simulators running my Adaptivity app. It is primarily a tool to visualize the different window sizes, layout margins, readable content guides, bar heights and Dynamic Type sizes that a modern, adaptive, iOS app uses when running on different devices and iPad multitasking sizes. This makes it the perfect tool to investigate and easily see the changes to appearance and behaviour in iPadOS 16.0. The layout views are also a great way to see how Stage Manager behaves and how apps transition between the different fixed sizes when resized and, when crossing a threshold, flip between compact- and regular-width size classes.

Form Sheet Presentations

Prior to iPadOS 16.0, form sheets were 540×620 points in size:

Form Sheet presentation with large navigation bar in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 15.5

In iPadOS 16.0 beta 4, form sheets increased in size to 580×640 points. This change occurs even when running an Xcode 13.4 (iOS 15) build. It is not necessary to rebuild with Xcode 14 to see this change:

Form Sheet presentation with large navigation bar in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Navigation Bar Heights

The changes described in this section were correct for iOS 16.0 beta 5 but it appears that beta 6 has reverted back to the old behaviour! Unfortunately there’s not a corresponding new Xcode 14 beta and new simulators so I cannot make new screenshots yet.

I will leave this section here for now but will remove it when I can make my updates.

iPad

The screenshots above of a form sheet presentation also show that the navigation bar has reduced in height by 6 points in iPadOS 16.0. This change occurred in beta 5 and, again, does not require building with Xcode 14. A similar reduction in navigation bar height occurs when using a compact navigation bar (56 points prior to iPadOS 16.0 beta 5; 50 points on beta 5):

Form Sheet presentation with compact navigation bar in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 15.5

Form Sheet presentation with compact navigation bar in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

The same 6 point reduction in height occurs for page sheet presentations. The size of the page sheet itself has not changed:

Page Sheet presentation with compact navigation bar in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 15.5

Page Sheet presentation with compact navigation bar in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Note that since iPadOS 13, the width of page sheets varies with changes to the Content Size Category (also known as the Dynamic Type size). The screenshots in this article all use the default (Large) content size category.

Popovers, however, are unchanged (with one very minor difference I will discuss later). The navigation bar in a popover with a compact title is 63 points tall (it extends from the top of the arrow to the bottom of the bar), but that bar’s visible size is mostly clipped beneath the arrow. The visible height was already 50 points prior to iPadOS 16.0:

Popover presentation with compact navigation bar in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 15.5. The navigation bar height is unchanged on iPadOS 16.0 beta 5.

With a SwiftUI app, however, iPadOS 16.0 beta 5 continues to use the same navigation bar heights in non-full-screen presentations as a UIKit app does prior to iPadOS 16.0 beta 5. This is even the case when the SwiftUI app is built with Xcode 14 beta 5. In a non-full-screen presentation, a large navigation bar is 108 points tall and a compact navigation bar is 56 points tall:

Default presentation with large navigation bar in Xcode 14 beta 5 build of SwiftUI app on 11" iPad Pro running iPadOS 16.0 beta 5

Default presentation with compact navigation bar in Xcode 14 beta 5 build of SwiftUI app on 11" iPad Pro running iPadOS 16.0 beta 5

iPhone

On iPhone, the navigation bar height in a non-full-screen presentation has reduced in height by 12 points in iOS 16.0 beta 5 (from 108 points to 96 points). This change occurs even when running an Xcode 13.4 (iOS 15) build:

Default presentation with large navigation bar in Xcode 13.4 build of Adaptivity on iPhone 13 Pro running iOS 15.5 and iOS 16.0 beta 5

A similar reduction in navigation bar height occurs when using a compact navigation bar (56 points prior to iPadOS 16.0 beta 5; 44 points on beta 5):

Default presentation with compact navigation bar in Xcode 13.4 build of Adaptivity on iPhone 13 Pro running iOS 15.5 and iOS 16.0 beta 5

Just like on iPad, a SwiftUI app on iPhone running iOS 16.0 beta 5 continues to use the same navigation bar heights in non-full-screen presentations as a UIKit app does prior to iOS 16.0 beta 5. A large navigation bar is 108 points tall and a compact navigation bar is 56 points tall:

Default presentation with large and compact navigation bars in Xcode 14 beta 5 build of SwiftUI app on iPhone 13 Pro running iOS 16.0 beta 5

Split View Controller

UISplitViewController is very powerful and flexible and became even more so in iOS/iPadOS 14 with the introduction of double/triple column styles and the ability to use a custom view controller in compact-width environments (as an alternative to collapsing the view controllers into a single navigation stack). There are many properties for configuring the appearance and behaviour of split view controllers. I want to focus on default configurations in this article to highlight how the behaviour has changed in iPadOS 16.0.

Prior to iPadOS 13.0, split view controllers could only be used full screen, either as the root view controller in a window or with a full screen modal presentation. The introduction of card-like sheet presentations in iPadOS 13.0 enabled support for form sheet and page sheet presentations of split view controllers. That version also introduced an automatic modal presentation style and made that the default. Part of the header file documentation for modalPresentationStyle states (emphasis added):

By default UIViewController resolves UIModalPresentationAutomatic to UIModalPresentationPageSheet, but system-provided subclasses may resolve UIModalPresentationAutomatic to other concrete presentation styles. Participation in the resolution of UIModalPresentationAutomatic is reserved for system-provided view controllers.

To my knowledge, UISplitViewController is the only view controller whose appearance with theautomatic modal presentation style is different to pageSheet. It adapts to fill the width of the presenting view controller.

I think it is fair to say that presenting a split view controller non-full-screen is uncommon, but it has been possible since iOS/iPadOS 13.0. How it appears depends on the iPadOS version and, with the introduction of changes in iPadOS 16.0, whether the app has been rebuilt with Xcode 14 or not.

Classic Style

The classic style of split view controller was introduced in iOS 3.2. On iPad, with default configuration, a full-screen classic style split view controller shows both primary and secondary view controllers in landscape. The width of the primary view varies with the device size but is either 320 or 375 points, with the secondary view controller filling whatever width remains:

Full Screen classic style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

Since this is a full screen presentation, the change to navigation bar heights seen in iOS and iPadOS 16.0 in beta 5 does not occur and a full screen classic style split view controller on iPadOS 16.0 looks identical to earlier versions.

As noted above, since iPadOS 13.0 it has been possible to present split view controllers with non-full-screen modal presentation styles. The default presentation of a classic style split view controller adapts to fill the width and has the now familiar card-like sheet appearance where the height falls short of the full height of the screen and the presenting view controller remains partially visible and recedes behind it:

Default presentation of classic style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

On iPadOS 16.0, the default presentation of a classic style split view controller is unchanged other than the reduction in height of the navigation bars in beta 5. The adaption to full width continues to happen for the classic style no matter which version of Xcode the app is built with:

When presented as a form sheet, the classic style split view controller is 540×620 points in size prior to iPadOS 16.0 beta 4. This is compact width and only the primary view controller is visible. Showing the secondary view controller requires it to be pushed onto the navigation stack. In Adaptivity, this is achieved by tapping the “Secondary” button that is shown in the primary view controller when the split view controller is compact width.

Form Sheet presentation of classic style split view controller in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 15.5

On iPadOS 16.0, a classic style split view controller presented as a form sheet has the increased 580×640 points size since beta 4 and the reduced navigation bar height seen earlier in beta 5. These changes occur even when running an Xcode 13.4 (iOS 15) build:

Form Sheet presentation of classic style split view controller in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

When presented as a page sheet, the appearance of the classic style split view controller depends on the device size and Content Size Category (Dynamic Type size). Since iPadOS 13.0, page sheets get wider at larger content sizes and that can result in changes to the width of the primary view controller (320 or 375 points) and whether the secondary view controller is also shown. On the 11" iPad Pro, with default settings, both view controllers are shown at widths of 320 and 384 points respectively. As with all page sheet presentations, the height depends on the height (and orientation) of the device.

Page Sheet presentation of classic style split view controller in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 15.5

On iPadOS 16.0 beta 5, the size of a classic style split view controller in a page sheet is unchanged but the navigation bars are reduced in height by 6 points:

Page Sheet presentation of classic style split view controller in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Split view controllers can even be presented in popovers. By default, a popover presentation will adapt to an automatic presentation in a compact width environment. Popevers are compact width and show just the primary view controller by default. In Adaptivity, popovers for view controllers other than the generic “Modal View Controller” view have a preferred content size of 375 points wide and 2000 points tall. The width can be honoured, but the height must be reduced to fit the available space.

Popover presentation of classic style split view controller in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 15.5

On iPadOS 16.0, a popover presentation of a classic style split view controller reveals a minor change in behaviour introduced in beta 4, but only for apps built with Xcode 14. Remember that Adaptivity is requesting a preferred content size larger than the available height. Adaptivity does not set the popover presentation controller’s permittedArrowDirections property. Earlier iPadOS versions (and Xcode 13 builds run on iPadOS 16.0) present the popover with an upwards arrow, whereas Xcode 14 builds since beta 4 present it with a rightwards arrow. This only happens when the preferred content size height is too large. I presume that iPadOS is switching to a rightwards arrow so that the popover can be slightly taller and more closely match the preferred content size (i.e. the reduction in height is smaller):

Popover presentation of classic style split view controller in Xcode 4 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Similar to how the navigation bar in a popover was 13 points taller than its visible height in order to account for the upwards arrow, with a rightwards arrow the view controller is 13 points wider than its 375 points visible size at 388 points.

Note, however, that the trailing margin has not been increased to account for this and both the primary and secondary view controllers (when pushed on the navigation stack) have layout margins and readable content guides which are 13 points wider than they should be. Content aligned with a trailing layout guide will be too close to the visible edge of the popover when the arrow points to the right. I did not test it, but I assume the reverse would happen if the arrow pointed to the left.

This might be a longstanding issue when using horizontal arrows for popovers. I didn’t want to get too distracted by this, but I did notice that the trailing safe area layout guide margin is increased by 13 points to account for a rightwards arrow. Some types of view controllers are not increasing their trailing layout guide and readable content margins in response to the change in safe area margins.

Double Column Style

The double column style introduced in iOS/iPadOS 14.0 appears similar to the classic style in its default configuration, but has some subtle differences.

Whilst the width of the primary view controller in a full screen or default presentation of the classic style split view controller was either 320 points or 375 points (depending upon the device size), a double column style always has a visible width of 320 points prior to iPadOS 16.0.

I say “visible width” because the view controller is actually 420 points wide but its leading 100 points are off the edge of the screen. This is because it is possible to swipe the primary view controller to the right (in a left-to-right language), partially revealing the off-screen content. The leading layout margin is increased by 100 points (116 instead of 16) to counteract this so that content aligned with the margins continues to appear visible. I made a few tweets and screenshots back in July 2020 which try to explain this.

Full Screen double column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

Since this is a full screen presentation, the change to navigation bar heights seen in iOS and iPadOS 16.0 beta 5 does not occur and a full screen double column style split view controller on iPadOS 16 looks identical to earlier versions.

Prior to iPadOS 16.0, the default presentation of a double column style split view controller adapts to fill the width and has the familiar card-like sheet appearance. As with a full screen presentation, the primary view controller has a fixed visible width of 320 points (actual width 420 points to allow for over-swiping):

Default presentation of double column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

On iPadOS 16.0 things get interesting. An Xcode 13 build presenting a double column style split view controller with the default presentation style continues to adapt to the full width, has a reduced navigation bar height (in beta 5), but also has a reduced primary view controller width (visible 240 points, actually 340 points due to the 100 points off screen):

Default presentation of double column style split view controller in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

I think this is a bug (reported as part of FB10586694). As will become very clear in a moment, iPadOS 16.0 is providing backward compatibility for Xcode-13-built apps with the default presentation style by adapting to fill the width, but it is not keeping the primary view controller at a visible width of 320 points.

On iPadOS 16.0, an Xcode 14 build presenting a double column style split view controller with the default presentation style no longer adapts to full width. The secondary view controller is shown at the same size as a form sheet presentation (580×640 points since beta 4) with a 240 points visible width for the primary view controller (actually 340 points due to the 100 points off screen):

Default presentation of double column style split view controller in Xcode 14 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

This changes two years of precedented behaviour (three if you include the full-width adaption for a default presentation of a classic style split view controller introduced in iPadOS 13). In a comment on my feedback report about this change, Apple said:

The new layouts for the UISplitViewController in the sheet presentations are new design for iOS 16.0 and are expected.

I think this new behaviour explains the 240 points wide primary view controller when iPadOS 16.0 is attempting to provide backward compatibility for apps built with Xcode 13 (i.e. linked against iOS 15).

When presented as a form sheet, prior to iPadOS 16.0, the double column style split view controller looks just like the classic style and is 540×620 points in size:

Form Sheet presentation of double column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

Since iPadOS 16.0 beta 4, a double column style split view controller presented as a form sheet by an app built with Xcode 13 has the increased 580×640 points size. It also has a reduced navigation bar height in beta 5:

Form Sheet presentation of double column style split view controller in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Build with Xcode 14 and the new behaviour is seen. A double column style split view controller presented as a form sheet looks identical to the default presentation:

Form Sheet presentation of double column style split view controller in Xcode 4 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

When presented as a page sheet, prior to iPadOS 16.0, the double column style split view controller has the same size as the classic style but, with default configuration, only shows the secondary view controller:

Page Sheet presentation of double column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

Tapping the “Primary” back button causes the primary view controller to slide on top of the secondary view controller:

Page Sheet presentation of double column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5 with the primary view controller overlaid on top of the secondary view controller

This appearance and behaviour can be configured using the preferredDisplayMode and preferredSplitBehaviour properties.

Other than the reduction in height of the navigation bars in beta 5, an Xcode-13-built app running on iPadOS 16.0 looks and behaves the same as earlier iOS versions with a form sheet presentation.

Build with Xcode 14 and, once again, the new behaviour is seen. A double column style split view controller presented as a page sheet has the usual 704×746 points total size for an 11" iPad Pro but both primary and secondary view controllers are visible (with default configuration):

Page Sheet presentation of double column style split view controller in Xcode 4 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Like other page sheet presentations, its width varies with changes to the Content Size Category. When both view controllers are visible, the primary remains at a visible width of 240 points and the secondary view controller varies its width.

This appearance is unusual in that a page sheet presentation is narrower than a form sheet presentation. That has never happened before: page sheets have always been at least as wide as form sheets (they will be the same width in compact width environments where they fill the width of the presenting view controller).

Prior to iPadOS 16.0 beta 4, a popover presentation of a double column style split view controller looks the same as the classic style:

Popover presentation of double column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

An Xcode 14 build of Adaptivity run on iPadOS 16.0 beta 4 or later uses a rightwards arrow because Adaptivity is requesting a preferred content size that is too tall to fit. Unlike with the classic style view controller, the trailing layout margins are increased in size by 13 points to account for the extra width that the popover occupies due to the rightwards arrow:

Popover presentation of double column style split view controller in Xcode 4 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Triple Column Style

The triple column style introduced in iOS/iPadOS 14 has primary, supplementary and secondary view controllers. There are many properties to configure its appearance and behaviour, but I will focus on default behaviour.

By default, a triple column style split view controller always seems to use a width of 375 for the supplementary view controller for all iPadOS versions, presentation styles and device sizes. The width of the primary view controller, however, depends on the presentation style and iPadOS version. The secondary view controller fills whatever width remains.

A full screen triple column split view controller shows the supplementary and secondary view controllers:

Full Screen triple column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

Tapping the back button in the supplementary view controller reveals the primary view and, with default configuration, pushes both the supplementary and secondary view controllers to the right with the secondary view dimmed and partially off the right of the screen. The primary view controller has a visible width of 320 points with an extra 100 points off screen for over-swiping:

Full Screen triple column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5 with the primary view controller visible and the secondary view controller partially off the right of the screen

Since this is a full screen presentation, the change to navigation bar heights seen in iOS and iPadOS 16.0 beta 5 does not occur and a full screen triple column style split view controller on iPadOS 16 looks almost identical to earlier versions. There is a tiny difference: the button in the supplementary view which reveals the primary view uses the sidebar icon on iPadOS 16.0 and not a back chevron:

Full Screen triple column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Prior to iPadOS 16.0, the default presentation of a triple column style split view controller adapts to fill the width and has the familiar card-like sheet appearance. As with a full screen presentation, the supplementary view controller has a fixed width of 375 points and a back button reveals the primary view controller (not shown):

Default presentation of a triple column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

As with the double column style, on iPadOS 16.0 the behaviour changes. An Xcode 13 build presenting a triple column style split view controller with the default presentation style continues to adapt to the full width, has a reduced navigation bar height in beta 5 and the supplementary view shows a sidebar icon for revealing the primary view:

Default presentation of a triple column style split view controller in Xode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

When the primary view controller is revealed, with default configuration, it pushes both the supplementary and secondary view controllers to the right with the secondary view dimmed and partially off the right of the screen. The primary view controller has a visible width of 240 points with an extra 100 points off screen for over-swiping. As with a default presentation of the double column style split view controller in an Xcode 13 build, this is 80 points narrower than a full screen view:

Default presentation of a triple column style split view controller in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 15.5 with the primary view controller visible

Once again, I claim this is a bug. If iPadOS 16.0 is going to adapt the default presentation to full width for an Xcode 13 built app then it should also keep the primary view controller with a visible width of 320 points.

On iPadOS 16.0, an Xcode 14 build presenting a triple column style split view controller with the default presentation style no longer adapts to full width. This is shown at the same height as a form sheet (640 points since beta 4) with a fixed 375 points wide supplementary view controller and a secondary view controller that is 524 points wide:

Default presentation of triple column style split view controller in Xcode 14 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Tapping the sidebar button in the supplementary view controller reveals the primary view controller with a visible width of 240 points (plus 100 points off screen for over-swiping even though it’s not possible to swipe the primary view unless the split view controller fills the width of the screen). With default configuration, the secondary view dims and is cropped:

Default presentation of triple column style split view controller in Xcode 14 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5 with the primary view controller visible

When presented as a form sheet, prior to iPadOS 16.0, the triple column style split view controller looks just like the classic and double column style and is 540×620 points in size:

Form sheet presentation of triple column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

Since iPadOS 16.0 beta 4, a triple column style split view controller presented as a form sheet by an app built with Xcode 13 has the increased 580×640 points size. It will also have a reduced navigation bar height in beta 5:

Form Sheet presentation of triple column style split view controller in Xcode 13.4 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Build with Xcode 14 and the new behaviour is seen. A triple column style split view controller presented as a form sheet looks and behaves identical to the default presentation:

Form Sheet presentation of triple column style split view controller in Xcode 4 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

When presented as a page sheet, prior to iPadOS 16.0, the triple column style split view controller has the same size as the classic and double column styles but, with default configuration, like the double column style it only shows the secondary view controller:

Page Sheet presentation of triple column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5

Tapping the “Supplementary” back button in the secondary view controller causes the supplementary view controller to slide on top of the secondary view controller:

Page Sheet presentation of triple column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5 with the supplementary view controller overlaid on top of the secondary view controller

Tapping the back button in the supplementary view controller causes the primary view controller to slide in, pushing the supplementary view controller to the right:

Page Sheet presentation of triple column style split view controller in Adaptivity on 11" iPad Pro running iPadOS 15.5 with the primary and supplementary view controllers overlaid on top of the secondary view controller

This appearance and behaviour can be configured using the preferredDisplayMode and preferredSplitBehaviour properties.

Other than the reduction in heights of the navigation bar in beta 5, an Xcode-13-built app running on iPadOS 16.0 looks and behaves the same as earlier iOS versions with a page sheet presentation.

Build with Xcode 14 and, once again, the new behaviour is seen. A triple column style split view controller presented as a page sheet has the same 704×746 points total size for an 11" iPad Pro but both supplementary and secondary view controllers are visible (with default configuration):

Page Sheet presentation of triple column style split view controller in Xcode 4 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5

Tapping the sidebar button in the supplementary view controller reveals the primary view controller and, with default configuration, pushes both the supplementary and secondary view controllers to the right with the secondary view dimmed and partially off the right of the page sheet. The primary view controller has a visible width of 320 points with an extra 100 points off screen for over-scrolling:

Page sheet presentation of triple column style split view controller in Xcode 14 beta 5 build of Adaptivity on 11" iPad Pro running iPadOS 16.0 beta 5 with the primary view controller visible

Like other page sheet presentations, its width varies with changes to the Content Size Category. The primary and supplementary view controllers are always fixed in width and the secondary view controller varies its width.

Like the double column style split view controller, the triple column style with a page sheet presentation is narrower than with a form sheet presentation.

A popover presentation of a triple column style split view controller behaves much the same as with a double column style except that there are three levels of view controllers that can be pushed on the navigation stack.

Summary

Here’s a summary of the view controller presentation changes in iOS/iPadOS 16:

form sheets got slightly bigger since iPadOS 16.0 beta 4
navigation bar heights in non-full-screen (and non-popover) modal presentations got slightly smaller in iPadOS 16.0 beta 5 for UIKit apps, but not SwiftUI apps. This change was reverted in beta 6
since iPadOS 16.0 beta 4, popover presentations will use a horizontal arrow rather than a vertical arrow if there’s not enough height to respect the popover’s preferred content size
in iPadOS 16, with an Xcode 13 build, the default presentation of double and triple column view controllers has a bug. It correctly adapts them to fill the width as in iPadOS 13 to 15 but it incorrectly reduces the width of the primary view controller by 80 points
in iPadOS 16, with an Xcode 14 build, the default presentation of double and triple column split view controllers resolve to form sheet (and not to page sheet, which happens for all other types of view controller)
in iPadOS 16, with an Xcode 14 build, the appearance and behaviour of form and page sheet presentations of double and triple column split view controllers has changed significantly

Workarounds to Keep Previous Behaviour

Form Sheet Size

I don’t think it should be necessary to keep the previous form sheet size on iPadOS 16.0 beta 4 and later. Apps ought to be flexible enough to adapt to minor changes in appearance. If you really must keep the 540×620 points size, setting the preferredContentSize for the presented view controller achieves this:

vcToBePresented.preferredContentSize = CGSize(width: 540,
                                              height: 620)

Primary View Controller Width Reduction

To work around the reduction in width of the primary view controller when an Xcode 13-built app presents a double or triple column split view controller with a default modal presentation style on iPadOS 16.0, explicitly request a width of 320 points:

splitViewController.maximumPrimaryColumnWidth = 320
splitViewController.preferredPrimaryColumnWidth = 320

I am hoping this bug will be fixed before iPadOS 16.0 is released. This workaround will no longer be required, but won’t cause problems, if it is fixed.

Full Width Split View Controller Adaptions

To keep the adaption to full width for the default presentation of double and triple column split view controllers in iPadOS 16.0, set a ridiculously-large preferredContentSize on the split view controller. This will cause it to be as wide and tall as possible. The width will be limited by the size of the screen and the height will be limited by the card-like appearance of sheet presentations:

splitViewController.preferredContentSize = CGSize(width: 100000,
                                                  height: 100000)

If you want to keep the full width appearance, it is likely that you would also want to keep the primary view controller with a visible width of 320 points. Setting the maximum and preferred primary column width properties as described above will achieve that.

Why did Split View Controller Presentations Change?

Photo Picker

We may never know for sure, but I strongly suspect the change to how double and triple column split view controllers are presented in iPadOS 16.0 is to support the new design for the system photo picker, PHPickerViewController. The older UIImagePickerController still works just fine and uses the newer appearance on iOS/iPadOS 14.0 and later (with some minor differences on iPadOS 16.0 described below).

In iPadOS 14 to 15, the system photo picker (old or new) appeared to be a single view controller. With a default presentation it has the page sheet size of 704×746 points (since default presentations resolve to page sheet):

Default presentation of system photo picker controller on 11" iPad Pro running iPadOS 15.5

On iPadOS 16.0, the photo picker now appears to be a double column split view controller. Thanks to Justin Jia on Twitter who clarified some behaviour for me.

The older UIImagePickerViewController with a default presentation resolves to a page sheet size on iPadOS 16.0 (no matter which Xcode version was used to build the app). The primary view controller has a visible width of 240 points:

Default presentation of UIImagePickerController on 11" iPad Pro running iPadOS 16.0 beta 5

The newer PHPickerViewController with a default presentation resolves to a form sheet on iPadOS 16.0 (no matter which Xcode version was used to build the app):

Default presentation of PHPickerViewController on 11" iPad Pro running iPadOS 16.0 beta 5

We can explicitly request a form sheet presentation for the older UIImagePickerController and get the wider but shorter appearance seen with PHPickerViewController:

Form sheet presentation of UIImagePickerController on 11" iPad Pro running iPadOS 16.0 beta 5

Similarly, we can explicitly request a page sheet presentation for the newer PHPickerViewController and get the taller but narrower appearance seen with UIImagePickerController:

Page sheet presentation of PHPickerViewController on 11" iPad Pro running iPadOS 16.0 beta 5

We can also explicitly request a full screen presentation for the photo picker. With both UIImagePickerController and PHPickerViewController this results in the primary view controller having a visible width of 320 points:

Full screen presentation of system photo picker controller on 11" iPad Pro running iPadOS 16.0 beta 5

Document Picker

Justin Jia’s tweet also mentioned the document picker. For completion, here’s what happens with UIDocumentPickerViewController.

Since iPadOS 14, the document picker appears to be a double column split view controller. In iPadOS 14 to 15, with a default presentation, it resolves to page sheet. The primary view controller is hidden by default and it overlays the secondary view controller when revealed. It has a width of 320 points:

Default presentation of UIDocumentPickerViewController on 11" iPad Pro running iPadOS 15.5

A default presentation resolves to a form sheet on iPadOS 16.0 (no matter which Xcode version was used to build the app). The primary view controller is always visible and has a visible width of 240 points:

Default presentation of system document picker on 11" iPad Pro running iPadOS 16.0 beta 5

Possible Better Behaviour

We have seen that the default presentation of a double or triple column split view controller resolves to a form sheet on iPadOS 16.0. PHPickerViewController also resolves to a form sheet by default. UIImagePickerController, however, is overriding the default behaviour and resolving to a page sheet.

Maybe I’m missing some important context, but given this new behaviour in the photo picker, it seems it would have been a lot less disruptive if the default presentation of double and triple column presentation continued to adapt to fill the width and had a card-like sheet appearance in iPadOS 16.0. The photo picker could continue to explicitly choose its page sheet (UIImagePickerController) of form sheeet (PHPickerViewController) presentation and look exactly the same as it does now.

Explicitly requesting a form sheet presentation for double and triple column style split view controllers would give the appearance that iPadOS 16.0 currently shows for default presentations. There would be no loss of functionality compared with iPadOS 16.0’s current behaviour but there would be fewer changes in appearance when building with Xcode 14. Of course, the bug where the primary view controller is 80 points narrower when adapting to full width would still need to be fixed.

SF Symbol Changes in iOS 16.0

Geoff Hackworth — Mon, 27 Jun 2022 08:52:27 GMT

Introduction

In WWDC 2022: What’s New in SF Symbols 4, Apple announced the latest updates to SF Symbols. There are now over 4000 symbols, the default render mode will use hierarchical for some symbols, and a new Variable Color feature progressively colors parts of some symbols to highlight changing state.

There are now ten different sets of symbols to consider:

SF Symbols v1.0 available in iOS/iPadOS/tvOS/Mac Catalyst 13.0, watchOS 6.0 and macOS 11.0
SF Symbols v1.1 available in iOS/iPadOS/tvOS/Mac Catalyst 13.1, watchOS 6.1 and macOS 11.0
SF Symbols v2.0 available in iOS/iPadOS/tvOS/Mac Catalyst 14.0, watchOS 7.0 and macOS 11.0
SF Symbols v2.1 available in iOS/iPadOS/tvOS/Mac Catalyst 14.2, watchOS 7.1 and macOS 11.0
SF Symbols v2.2 available in iOS/iPadOS/tvOS/Mac Catalyst 14.5, watchOS 7.4 and macOS 11.3
SF Symbols v3.0 available in iOS/iPadOS/tvOS/Mac Catalyst 15.0, watchOS 8.0 and macOS 12.0
SF Symbols v3.1 available in iOS/iPadOS/tvOS/Mac Catalyst 15.1, watchOS 8.1 and macOS 12.0
SF Symbols v3.2 available in iOS/iPadOS/tvOS/Mac Catalyst 15.2, watchOS 8.3 and macOS 12.1
SF Symbols v3.3 available in iOS/iPadOS/tvOS/Mac Catalyst 15.4, watchOS 8.5 and macOS 12.3
SF Symbols v4.0 available in iOS/iPadOS/tvOS/Mac Catalyst 16.0, watchOS 9.0 and macOS 13.0

For a detailed list of symbols that were added or renamed in earlier iOS versions, see my previous articles:

SF Symbols Changes in iOS 14.0 (SF Symbols 2.0)
SF Symbols Changes in iOS 14.2 (SF Symbols 2.1)
SF Symbols Changes in iOS 14.5 (SF Symbols 2.2)
SF Symbols Changes in iOS 15.0 (SF Symbols 3.0)
SF Symbols Changes in iOS 15.1 (SF Symbols 3.1)
SF Symbols Changes in iOS 15.2 (SF Symbols 3.2)
SF Symbols Changes in iOS 15.4 (SF Symbols 3.3)

The purpose of this article is to describe what has changed in SF Symbols in iOS 16.0, not how to write code to use the new features. The “Resources” section towards the end of this article has links to some WWDC videos and blog posts which explain how to use the new features.

SF Symbol Browsing Apps

Apple updated their SF Symbols Mac app to support the new symbols and Variable Color in iOS 16.0. The initial version 4.0 (build 75) included the symbols in iOS 16 beta 1. Around 8th July, version 4.0 (build 76.1) was released and included the changes in iOS 16.0 beta 2. At the time of this update (29th July), the latest iOS 16.0 version is beta 4. We are still waiting for an update to Apple’s app to include the changes in beta 3 and 4.

Apple’s SF Symbols Mac app v4.0 (build 75)

I take great pride and invest a lot of time and effort in keeping Adaptivity up to date. The iPhone and iPad screenshots in this article were taken from a pre-release version of Adaptivity v9.0 built with Xcode 14 and demonstrate the symbol changes in iOS 16.0 and new Variable Color support.

Since SF Symbol names are just strings, Adaptivity v8.12 in the App Store also supports viewing the latest symbols (as of beta 4) when on a device running iOS 16.0 beta or macOS 13 beta. The app is a universal purchase and works on iOS/iPadOS and Mac Catalyst. If you want instant access to the symbol names and unicode characters right from the menu bar on your Mac, check out SF Menu Bar.

Changes in SF Symbols 4 (Beta 1)

iOS/iPadOS 16 beta 1 was released on 6th June 2022. There are far too many changes to SF Symbols to list them all in detail. The changes fall into several different categories:

New symbols 698 new symbols have been added; some have restricted usage
Automatic render mode The default render mode now chooses monochrome or hierarchical appearance, depending on the symbol
Variable Color symbols 150 symbols have Variable Color support to highlight changing state
Renamed symbols 24 existing symbols have been renamed
Localized variants More right-to-left localized symbols, more localized versions of symbols which include letters, punctuation or numeric digits

New Symbols

There are 722 symbols in the ‘What’s New’ category in SF Symbols v4.0 (build 75) but some of them are renamed versions of existing symbols rather than completely new symbols (see below for more information).

iOS 16.0b1 System Images ‘Whats New’ category in Adaptivity v9.0 on 12.9" iPad Pro

A total of 698 symbols were added in iOS 16.0 beta 1. Adaptivity’s optional ‘Availability’ annotation (selected from the Info icon in the bottom right) adds a small 16.0+ annotation to symbols which are new in iOS 16.0. To make it easier to see which symbols are not supported in iOS 13.0, there is no annotation shown for symbols that were available in iOS 13.0 (unless they were renamed since; see below for more information).

Adaptivity also has an ‘Added’ smart collection which includes just the symbols that have been added in the data set you are viewing:

iOS 16.0b1 System Images ‘Added’ collection in Adaptivity v9.0 on 12.9" iPad Pro

Automatic Render Mode

In previous iOS versions, the default render mode for SF Symbols was monochrome. A new Automatic mode is the default on iOS 16. It uses monochrome for the vast majority of symbols but uses a hierarchical appearance for some symbols that Apple believe look better rendered that way. New API in iOS 16.0 allows monochrome rendering to be explicitly requested.

Adaptivity’s ‘Render Mode’ setting (selected from the Info button in the bottom right) allows any of the render modes supported by the data set being viewed to be selected. In the screenshot below, the various computer and iPhone symbols have lighter colors for the screens in Automatic and would be transparent in Monochrome.

iOS 16.0b1 System Images ‘Devices’ category in Adaptivity v9.0 on 12.9" iPad Pro with Automatic render mode

Variable Color Symbols

SF Symbols added support for Variable Color in iOS 16.0. There are 150 symbols in the ‘Variable’ category in iOS 16.0 beta 1:

iOS 16.0b1 System Images ‘Variable’ category in Adaptivity v9.0 on 12.9" iPad Pro

Adaptivity’s ‘Variable Color’ configuration in the toolbar allows Variable Color to be turned on or off and to configure the percentage. In my testing, some symbols aren’t rendering correctly in Variable Color in the Monochrome or Multicolor render mode, but do render correctly in Hierarchical and Palette. This was fixed in beta 3.

Apple claim that Variable Color can be used in conjunction with each of the different render modes but that seems to have been broken in beta 2 and it is no longer possible to use Variable Color with multicolor rendering. This was also fixed in beta 3.

Renamed Symbols

24 existing symbols have been renamed in iOS 16.0 beta 1. For apps that support earlier iOS versions, the older names must be used. When running on iOS 16.0 and later, either name can be used.

As in the past, there appears to be several different reasons for renames:

Naming E.g. logo.playstation is now playstationlogo (but this was renamed again in beta 2, see later)
Word order consistency E.g. phone.fill.arrow.down.left is now phone.arrow.down.left.fill
More descriptive names E.g. wrench is now wrench.adjustable

Adaptivity also makes it very easy to see renamed symbols. When the ‘Availability’ annotation is enabled, a list of iOS versions is shown for symbols that have been renamed since they were first added. For example, a 16.0+,15.0 annotation indicates that a symbol was added in iOS 15.0 but has been renamed in iOS 16.0. Some symbols have been renamed multiple times, e.g. dial.low shows a 16.0+,14.0,13.0 annotation to indicate it was available in iOS 13.0, renamed in iOS 14.0 and renamed again in iOS 16.0.

Adaptivity also has a ‘Renamed’ smart collection which shows all the symbols that have been renamed in the data set you are viewing:

iOS 16.0b1 System Images ‘Renamed’ smart collection in Adaptivity v9.0 on 12.9" iPad Pro

iOS 16.0b1 System Images ‘Renamed’ smart collection, context menu and List view in Adaptivity v9.0 on iPhone 13 Pro

Restricted Symbols

The number of restricted symbols has increased from 269 in iOS 15.4 to 287 in iOS 16.0 beta 1. In Adaptivity and Apple’s SF Symbols app, a red ⓘ button indicates a symbol is restricted. Tapping the button shows an alert explaining how the symbol can be used. Adaptivity also has a ‘Restricted’ smart collection which includes just the restricted symbols. There is also an ‘Unrestricted’ smart collection which includes just the symbols that are not restricted.

iOS 16.0b1 System Images ‘Restricted’ collection in Adaptivity v9.0 on 12.9" iPad Pro

Localized Variants

Symbols that contain letters (e.g. textformat.size) show non-English characters in place of the “A”. Some symbols (e.g. thegoforward.5 etc. series of symbols) show the numerals in Arabic or Hindi. When the right sidebar is enabled, Apple’s SF Symbols Mac app shows localization information for the selected symbol.

Adaptivity has an optional language localization annotation (a globe icon) to identify symbols with language localizations. Adaptivity also has a ‘Language Localized’ smart collection to make them easy to find. iOS 16.0 beta 1 increases the number of symbols with language localizations to 74 (compared with iOS 15.4’s 62).

iOS 16.0b1 System Images ‘Language Localized’ smart collection in Adaptivity v9.0 on 12.9" iPad Pro

Some symbols appear partially or fully horizontally-flipped in right-to-left localizations. Adaptivity has an optional right-to-left annotation (⇄) to identify symbols that have right-to-left localizations. Adaptivity also has a ‘Right-to-Left Localized’ smart collection to make them easy to find.

iOS 16.0 beta 1 increases the number of symbols with right-to-left localizations to 394 (compared with iOS 15.4’s 338).

iOS 16.0b1 System Images ‘Right-to-Left Localized’ smart collection in Adaptivity v9.0 on 12.9" iPad Pro

Some of the symbols with right-to-left localizations are separate symbols so that a non-right-to-left localized version is also available. Apple uses words such as left and right for symbols which are not right-to-left localized and words such as leading, trailing, forward and backward for symbols which are right-to-left localized.

As with language localizations, a long press on a right-to-left localized symbol reveals a “Show Localizations” context menu action to show both left-to-right and right-to-left variants (and any language localizations if the symbol is also localized to other languages):

iOS 16.0b1 System Images ‘Right-to-Left Localized’ smart collection in Adaptivity v9.0 on 12.9" iPad Pro

Adaptivity also has an option in its Setting screen to force a right-to-left layout. This flips the entire user interface in the same way as the Right-to-Left Pseudolanguage option that can be configured in Xcode’s scheme settings when running your own app. The order in which the symbols are listed flips left-to-right (because the whole user interface flips), but only the right-to-left localized symbols actually change appearance. The “Show Localizations” context menu action is still available to also view the left-to-right variant.

iOS 16.0b1 System Images ‘Right-to-Left Localized’ smart collection in Adaptivity v9.0 on 12.9" iPad Pro in Right-to-Left layout

Changes During the iOS 16.0 beta

To help developers keep up with changes during the beta cycle, Adaptivity has smart collections to highlight the symbols which were added or renamed in later beta versions. I also update the App Store version of Adaptivity to show these collections when run on iOS/iPadOS 16.0 beta. Even though App Store builds currently have to be built with Xcode 13.x (and cannot use iOS 16 APIs), it is still possible to show the new symbols since the images are loaded via their names as strings.

These beta smart collections will be removed after iOS/iPadOS 16 is publicly released and Adaptivity’s big iOS 16.0 update is released in the App Store. Future updates to this article will highlight the changes that occurred during the iOS 16.0 beta cycle.

Symbols added in iOS 16.0 which were then renamed in a later beta will not be available under their old names; backwards compatibility only exists for renamed symbols whose original name was in a released version of iOS. Neither Adaptivity nor Apple’s SF Symbols app will show names that only existed during the beta cycle.

iOS 16.0 Beta 2

There were 137 new symbols and 5 renamed symbols in iOS 16.0 beta 2. Apple’s SF Symbols Mac app has was updated to include them around 8th July in build 76.1. Adaptivity includes the latest data and has ‘Added in Beta 2’ and ‘Renamed in Beta 2’ smart collections to highlight the changes. A great many of the new symbols are for sports or weather.

iOS 16.0b2 System Images ‘Added in Beta 2’ smart collection in Adaptivity v9.0 on 12.9" iPad Pro

Two of the symbols added in beta 2 are restricted and can only be used to refer to Apple’s Shazam:

shazam.logo
shazam.logo.fill

Two symbols that were added in iOS 15.0 and renamed in iOS 16.0 beta 1 have been renamed again in beta 2:

logo.playstation → playstationlogo → playstation.logo
logo.xbox → xboxlogo → xbox.logo

For consistency, applelogo (added in iOS 14.0) has been renamed to apple.logo in beta 2.

Two symbols added in beta 1 have been renamed in beta 2:

light.beacon → light.beacon.max
light.beacon.fill → light.beacon.max.fill

This is to make way for two new symbols in beta 2:

light.beacon.min
light.beacon.fill.min

Four symbols added in beta 1 gained Arabic localizations in beta 2:

checkmark.circle.badge.questionmark
checkmark.circle.badge.questionmark.fill
clock.badge.questionmark
clock.badge.questionmark.fill

Six symbols added in beta 1 gained right-to-left localizations in beta 2:

gear.badge
message.badge   
message.badge.filled.fill
message.badge.circle 
message.badge.circle.fill
message.badge.fill

There were also tweaks to the supported render modes for some symbols, changes to the order in which some symbols are listed, and changes to the symbols included in some categories.

iOS 16 Beta 3

There was tiny change in iOS 16.0 beta 3: moon.haze.fill now supports multicolor rendering.

iOS 16 Beta 4

There were 35 new symbols and 2 renamed symbols in iOS 16.0 beta 4. Apple’s SF Symbols Mac app has not yet been updated to include these changes (nor the change in beta 3). Adaptivity includes the latest data and has ‘Added in Beta 4’ and ‘Renamed in Beta 4’ smart collections to highlight the changes. Most of the new symbols are related to vehicles.

iOS 16.0b4 System Images ‘Added in Beta 4’ smart collection in Adaptivity v9.0 on 12.9" iPad Pro

Note that tv.and.mediabox.fill is one of the symbols which shows a hierarchical appearance in the automatic render mode.

One of the renamed symbols is face.smiling.inverse. This was known as smiley.fill in iOS 13 and was previously renamed in iOS 14 as face.smiling.fill.

The other renamed symbol is person.and.background.dotted. This was added in iOS 16 beta 2 with the name person.crop.background.dotted. Since that name was never publicly released, there is no backward compatibility and it will not be valid going forward.

Hierarchical and palette render modes are supported by 26 of the new symbols. Multicolor support is claimed for 5 of the new symbols but only 2 of them (nosign.app.fill and hand.app.fill) actually do support it. None of the new symbols support variable color.

iOS 16 Beta 5

There were no changes that I could find to SF Symbols in iOS 16 beta 5.

At the time of this update, 9th August 2022, Apple’s own SF Symbols app has not been updated since version 4.0 (build 76.1) and only includes the changes up to iOS 16.0 beta 2; the changes in beta 3 and 4 are not included.

Resources

Apple

WWDC 2022: 10158: Adopt Variable Color in SF Symbols

Adaptivity

Visualizing sizes, layout and margins in Adaptivity v9.0 on 12.9" iPad Pro

This is very useful to see how apps which support multitasking behave with the new Stage Manager feature on iPadOS 16.

SF Menu Bar

SF Menu Bar is a menu bar app for the Mac which is powered by the same SF Symbol data as Adaptivity. When run on macOS 13 beta, it will show symbols added in iOS 16/macOS 13. More information is available on my web site.

SF Menu Bar v1.5 running on macOS 12.4

(I’m not running macOS 13 beta, so this screenshot does not show the iOS 16 data set as being available.)

SF Symbol Changes in iOS 15.4

Geoff Hackworth — Sat, 29 Jan 2022 16:56:17 GMT

Introduction

When examining the iOS 15.4 simulator in the Xcode 13.3 betas, I noticed that there had been a few changes to SF Symbols. Firstly, seven new symbols have been added (unfortunately, the Face ID logo with a mask is not one of them). More interestingly, Apple have retroactively changed the availability of eighteen symbols from iOS 13.0/watchOS 6.0 to iOS 13.1/watchOS 6.1.

There are now nine different sets of symbols to consider:

SF Symbols v1.0 available in iOS/iPadOS/tvOS/Mac Catalyst 13.0, watchOS 6.0 and macOS 11.0
SF Symbols v1.1 available in iOS/iPadOS/tvOS/Mac Catalyst 13.1, watchOS 6.1 and macOS 11.0
SF Symbols v2.0 available in iOS/iPadOS/tvOS/Mac Catalyst 14.0, watchOS 7.0 and macOS 11.0
SF Symbols v2.1 available in iOS/iPadOS/tvOS/Mac Catalyst 14.2, watchOS 7.1 and macOS 11.0
SF Symbols v2.2 available in iOS/iPadOS/tvOS/Mac Catalyst 14.5, watchOS 7.4 and macOS 11.3
SF Symbols v3.0 available in iOS/iPadOS/tvOS/Mac Catalyst 15.0, watchOS 8.0 and macOS 12.0
SF Symbols v3.1 available in iOS/iPadOS/tvOS 15.1, Mac Catalyst 15.1, watchOS 8.1 and macOS 12.0
SF Symbols v3.2 available in iOS/iPadOS/tvOS 15.2, Mac Catalyst 15.2, watchOS 8.3 and macOS 12.1
SF Symbols v3.3 available in iOS/iPadOS/tvOS 15.4, Mac Catalyst 15.4, watchOS 8.5 and macOS 12.3

My own Adaptivity app is a tool for iOS developers and designers, and one of its many features is a very comprehensive view to browse SF Symbols. It can view any of the SF Symbol data sets that your device supports. The screenshots in this article were taken from version 8.7. They demonstrate the new symbols in iOS 15.4 and the moving of eighteen symbols from the iOS 13.0 data set to a new iOS 13.1 data set.

For a detailed list of symbols that were added or renamed in earlier iOS versions, see my previous articles:

SF Symbols Changes in iOS 14.0 (SF Symbols 2.0)
SF Symbols Changes in iOS 14.2 (SF Symbols 2.1)
SF Symbols Changes in iOS 14.5 (SF Symbols 2.2)
SF Symbols Changes in iOS 15.0 (SF Symbols 3.0)
SF Symbols Changes in iOS 15.1 (SF Symbols 3.1)
SF Symbols Changes in iOS 15.2 (SF Symbols 3.2)

Changes in SF Symbols 3.4

There are very few changes this time:

New symbols there are 7 new symbols
Hierarchical / Palette rendering 6 of the new symbols support the hierarchical and palette render modes

There are no renames or changes to multicolor symbols.

Added Symbols

The following 4 new symbols were added in iOS 15.4 beta 1:

person.badge.key
person.badge.key.fill
dots.and.line.vertical.and.cursorarrow.rectangle
key.viewfinder

The following 3 new symbols were added in Xcode 13.3 beta 3, which means they appeared in either iOS 15.4 beta 3 or 4. (I cannot be sure which because iOS 15.4 beta 3 did not have a separate Xcode 13.3 beta release.):

camera.macro
camera.macro.circle
camera.macro.circle.fill

Adaptivity’s ‘Availability’ annotation (selected from the Info icon in the bottom right) adds a small 15.4+ annotation to symbols which are new in iOS 15.4. To make it easier to see which symbols are not supported in iOS 13.0, there is no annotation shown for symbols that were available in iOS 13.0 (unless they have been renamed since).

Adaptivity also has a custom ‘Added’ collection which shows all the symbols that have been added in the data set you are viewing:

iOS 15.4 System Images ‘Added’ collection in Adaptivity v8.7 on iPhone 13 Pro in monochrome, hierarchical and palette render modes

Hierarchical and Palette Symbols

The screenshots above show 6 of new symbols support hierarchical and palette render modes. Here’s a closer look at them:

iOS 15.4 System Images context menu in Adaptivity v8.7 on iPhone 13 Pro in hierarchical render mode

Restricted Symbols

The data files in Xcode 13.3.1 do not list any new restricted symbols. Apple finally updated their SF Symbols Mac app at the end of April 2022 to include the symbols added in iOS 15.4 (after I prompted them!). In that app, two of the new symbols as marked as restricted and may only be used to refer to “creating or signing in with a passkey”:

person.badge.key
person.badge.key.fill

Changes in SF Symbols 1.0 and 1.1

In addition to the seven new symbols for iOS 15.4, the simulator data files in Xcode 13.3 beta 1 have changed the availability of eighteen of the original symbols from iOS 13.0/watchOS 6.0 to iOS 13.1/watchOS 6.1:

arrow.uturn.left.circle.badge.ellipsis
aspectratio
aspectratio.fill
car
circle.grid.2x2
circle.grid.2x2.fill
flashlight.off.fill
flashlight.on.fill
flip.horizontal
flip.horizontal.fill
mappin.circle
mappin.circle.fill
paperclip.circle
paperclip.circle.fill
pin.circle
pin.circle.fill
scissors.badge.ellipsis
studentdesk

Note that two of these symbols were renamed in iOS 14.0 (SF Symbols v2.0):

flip.horizontal → arrow.left.and.right.righttriangle.left.righttriangle.right

flip.horizontal.fill → arrow.left.and.right.righttriangle.left.righttriangle.right.fill

At the time of writing, the latest version of Apple’s own SF Symbols Mac app is v3.2 (build 67) and it claims these symbols have been available since SF Symbols v1.0 and iOS 13.0. By running an older version of Adaptivity on an iOS 13.0 simulator, I was able to confirm that these symbols really were not available in iOS 13.0:

Missing System Images in Adaptivity v8.5 on iPhone 11 Pro running iOS 13.0

There seems to have been some confusion over the version of SF Symbols that was included in iOS 13.0. This is perhaps down to the fact that iOS 13.1 was released just five days after iOS 13.0 and 13.1 was effectively considered the “first” version.

I expect a future version of Apple’s SF Symbols Mac app will correct this historical accident and mark these symbols as being available in SF Symbols v1.1 and iOS 13.1. Adaptivity v8.6 removed these eighteen symbols from its iOS 13.0 (SF Symbols v1.0) data set:

iOS 13.0 System Images data set in Adaptivity v8.6 on 11" iPad Pro

It also added a new iOS 13.1 (SF Symbols v1.1) data set to add the eighteen symbols. These symbols now show an availability annotation of 13.1+ (except when viewing an iOS 14.0 or later data set, where the two renamed symbols are annotated 14.0+,13.1 to indicate that they were renamed):

iOS 13.1 System Images data set in Adaptivity v8.6 on 11" iPad Pro

Resources

WWDC 2021: 10250, Create custom symbols

Adaptivity

Adaptivity has many other features in addition to browsing SF Symbols. It is primarily a tool to visualize the different window sizes, layout margins, readable content guides, bar heights and Dynamic Type sizes that a modern, adaptive, iOS app uses when running on different devices and iPad multitasking sizes. There are also views for browsing System Colors, System Fonts and System Materials, and a view for exploring iPadOS Pointer Interactions. In iOS/iPadOS 15 you can also configure UISheetPresentationController options for modally-presented view controllers.

Xcode Build Times with Custom SF Symbols

Geoff Hackworth — Wed, 29 Dec 2021 17:22:08 GMT

Introduction

In WWDC 2019: 206, Introducing SF Symbols Apple announced a great new resource for iOS developers:

SF Symbols introduces a comprehensive library of vector-based symbols that you can incorporate into your app to simplify the layout of user interface elements through automatic alignment with surrounding text, and support for multiple weights and sizes.

Since then, many more symbols and various color render modes have been added. Apple also made it possible for designers and developers to create their own SF Symbols for including in their apps.

Apple’s SF Symbols Mac app is the official browser for the symbols. It was recently updated to v3.2 (build 67) and now includes the images that were added in iOS 15.2, watchOS 8.3 and macOS 12.1. I have previously written about the SF Symbol changes in iOS 15.2. That article has links to other articles detailing changes in earlier iOS versions.

My own Adaptivity app for iOS and Mac includes a very comprehensive view to browse SF Symbols. It can view any of the different SF Symbol data sets that your device supports and has smart collections to highlight added and renamed symbols. It also has support for two custom SF Symbol data sets:

75 social media icons from Icons8: https://icons8.com/l/sf
286 icons from Niels Boey based on the open source Feather icons: https://nielsx.gumroad.com/l/sf-feathers

Icons8

The Icons8 symbols only support monochrome rendering. They take advantage of the v3 symbol format introduced alongside iOS 15 to include just three weights and a single scale. The other weights and scales can be derived from these using interpolation.

Icons 8 symbols in an Xcode asset catalog

Icons 8 symbols in Adaptivity v8.5 on 12.9" iPad Pro

In my testing, the v3 symbols can be included in an Xcode asset catalog and used prior to iOS 15, but some weights and scales do not render correctly. Importing the symbols in to the SF Symbols Mac app and exporting them in the v2 format fixes that issue but introduces another: the images are not tinted if they are shown in hierarchical or palette render modes on iOS 15. Since they are monochrome images, there’s no need to try and render them with those modes!

SF Feathers

The SF Feathers symbols support monochrome and the new hierarchical/palette rendering mode added in iOS 15. They too use the v3 symbol format but include images for all the weights and scales.

SF Feathers symbols in an Xcode asset catalog

SF Feathers symbols in Adaptivity v8.5 on 12.9" iPad Pro

Xcode Build Times

When I added the SF Feathers symbols to Adaptivity, I noticed a considerable increase in build times, especially when building for Mac Catalyst. This article summarises my investigations as to why, and has some suggestions for improving build times if you include a lot of custom symbols in your own app.

Test Environment

In order to eliminate as many other factors as possible, I created a simple test app and removed unnecessary things like storyboards, main view controller and scene delegate. I tweaked the Info.plist and build settings to remove references to them. I did, however, keep the asset catalog that Xcode created with an empty icon set and empty AccentColor. Removing those caused build issues and it seemed easier and less likely to cause problems to just keep them. They did not make a noticeable difference to asset catalog build times. I also enabled support for Mac Catalyst and selected Optimize Interface for Mac (although this didn’t seem to make any difference to the results). [EDIT: following a comment by Steve Troughton-Smith on Twitter, I also added an AppKit target to test building for a native Mac app.]

Finally, I added separate asset catalogs, each of which included varying numbers of symbols from the SF Feathers data set (16–256 in powers of two).

Test project with iOS/Mac Catalyst and AppKit targets, each including varying number of symbols from different asset catalogs

For each test run I would exclude all my custom asset catalogs from the target and do a build. I would then add just one asset catalog of the appropriate size for the test and do another build. This was to try and ensure a minimal incremental build and to try and accurately measure the time it took to build the asset catalog without other parallel build steps competing for CPU resources. I tested each asset catalog size five times and averaged the results, and tested iOS, Mac Catalyst and AppKit builds. I also measured the size of the Assets.car file that was created by the build.

All my tests were made on a 2018 Mac Mini, 3.2GHz 6-Core Intel Core i7 running macOS 12.1 and Xcode 13.2.1. I tried to minimise the impact of other processes by closing as many apps as possible, stopping cloud backups, Dropbox and (when I noticed!) skipping any Time Machine backups that would start during my testing. My timings won’t be perfect, but are good enough to show general trends.

June 2022 Update: I re-ran the tests on the same Mac mini, now running macOS 12.4, and with Xcode 14 beta 2 and have included my results below.

iOS Target Build Times

By default, when Xcode builds for an iOS target it only includes assets that it needs for that target. This, for example, will result in 3x assets not being included when building for devices that don’t have a 3x display. The Build Active Resources Only build setting controls this.

Xcode project build settings showing Build Active Resources Only defaults to Yes

When archiving for uploading to App Store Connect, this build setting seemed to be ignored. Creating different versions of the asset catalog is presumably one of the mysterious things that happens when uploads are “Processing”.

The screenshot below shows the Compile asset catalogs step took 7.9s in one particular test. I have expanded the command line and highlighted the parameters that were included due to the Build Active Resources Only setting: a 5th generation 12.9" iPad Pro simulator running iOS 15.2:

When building for iOS targets, Xcode would use a process called AssetCatalogSimulatorAgent. This would run at 100% CPU until the asset catalog had been built. Interestingly/annoyingly, aborting the build in Xcode would not kill this process and it would need to run to completion.

Test Results (Xcode 13.2.1)

As you might expect, the time taken to build the asset catalog was proportional to the number of assets. Somewhat unexpectedly, the Build Active Resources Only build setting had a significant difference on build times. For an approximately 23% reduction in Assets.car file size with the setting enabled, it took approximately ten times as long to build!

Xcode 13.2.1 Test Results for iOS Build Targets with Build Active Resources Only enabled and disabled

Test Results (Xcode 14 beta 2)

Using Xcode 14.0 beta 2, build times with theBuild Active Resources Only build setting enabled were faster (approximately 70% of the Xcode 13.2.1 build times). With the setting disabled build times were still considerably quicker than with it enabled, but about 5% slower than with Xcode 3.2.1. The Assets.car file sizes were approximately 1% larger than with Xcode 13.2.1.

Xcode 14.0 beta 2 Test Results for iOS Build Targets with Build Active Resources Only enabled and disabled

Mac Catalyst Target Build Times

The Build Active Resources Only build setting didn’t seem to make any difference when building for Mac Catalyst. No extra flags were passed on the command line when the setting was enabled. I was only able to test with one Mac and one version of macOS.

Xcode build log showing the time taken to compile the asset catalog for a Mac Catalyst target

Test Results (Xcode 13.2.1)

Unlike building for iOS targets, building for Mac Catalyst used a process called ibtoold. It too would run at 100% CPU and not be killed when aborting a build. I have no idea why a separate tool is used, nor why the build times were both considerably worse than for iOS targets, and seemingly O(n²) instead of scaling linearly with the number of symbols 😱.

Xcode 13.2.1 Test Results for Mac Catalyst Build Target

Test Results (Xcode 14 beta 2)

Using Xcode 14 beta 2, Mac Catalyst builds were about 93% of the Xcode 3.2.1 build times. They remained considerably worse than iOS and are still seemingly O(n²) instead of scaling linearly with the number of symbols. The Assets.car file sizes were about 0.01% larger than with Xcode 13.2.1.

Xcode 14.0 beta 2 Test Results for Mac Catalyst Build Target

AppKit Build

As with a Mac Catalyst build, the Build Active Resources Only build setting didn’t make any difference to build times or the command line used for compiling the asset catalog.

Xcode build log showing the time taken to compile the asset catalog for an AppKit target

Test Results (Xcode 13.2.1)

Again, similarly to Mac Catalyst builds, ibtoold was used for compiling the asset catalog and would consume 100% CPU. However, unlike Mac Catalyst, the build times scaled linearly with the number of assets. The build times were very similar to the iOS target when Build Active Resources Only was disabled.

Xcode 13.2 1 Test Results for AppKit Build Target

Comparing the command line arguments passed to actool when compiling for Mac Catalyst or AppKit the interesting (non-path-related) parameters are:

Mac Catalyst:

--ui-framework-family uikit
--target-device mac 
--minimum-deployment-target 14.0 
--platform macosx

AppKit:

--target-device mac
--minimum-deployment-target 12.1
--platform macosx

It looks like --ui-framework-family uikit parameter used for Mac Catalyst targets is the key difference. This is not documented in the man page.

Test Results (Xcode 14.0 beta 2)

Using Xcode 14 beta 2, AppKit build times were about 90% of the Xcode 3.2.1 build times (except for the 256 image case — but maybe I recorded bad data or other tasks were running in the background). The Assets.car file sizes were about 96% of the Xcode 13.2.1 sizes.

Xcode 14.0 beta 2 Test Results for AppKit Build Target

Conclusion

Something very, very strange is happening with Mac Catalyst builds!

I can believe that building for Mac Catalyst could require some different processing and produce different-sized Assets.car files compared to building for iOS. But I cannot begin to understand why it is so much slower and significantly more so as the number of symbols increases. With just 16 custom symbols, a Mac Catalyst build takes approximately four times as long as building for iOS with Build Active Resources Only disabled. For 256 symbols, it took over thirty times as long! Enabling that build setting worsened the iOS builds by a factor of about ten but at least iOS builds have the decency to scale linearly. AppKit builds behaved very similarly to iOS builds with Build Active Resources Only disabled: fast and linear.

I didn’t have enough time (or will) to test other factors such as minimum deployment versions. I did notice that targetting an iOS 14 device when Build Active Resources Only was enabled took a little over half as long as building for an iOS 15 target (i.e. only approximately six times as long as disabling the setting). I’m guessing this is because versions of the symbols suitable for hierarchical/palette rendering are not required on iOS 14.

I have raised Feedback FB9828086 with Apple.

June 2022 Update: Xcode 14.0 beta 2 build times were improved on all platforms, most significantly on iOS when Build Active Resources Only was enabled. The Mac Catalyst builds are still considerably slower than iOS and continue to look like O(n²) performance.

Suggestions

If your app has even a small number of custom SF Symbols you might want to consider one or more of the following suggestions to improve build times:

avoid switching build targets, especially between iOS and Mac Catalyst, in order to prevent Xcode re-compiling the asset catalog
disable Build Active Resources Only

How I improved Adaptivity Build Times

Re-compiling the asset catalog in Adaptivity (with all 286 SF Feathers symbols, 75 Icons8 symbols and a few other assets) for Mac Catalyst would take over 15 minutes with ibtoold eating 100% CPU all that time! During development I often switch build targets and so this was completely unacceptable. Since showing the Icons8 and SF Feathers symbols is not something I need to test often, I have implemented a more drastic approach to keep my build times sane:

in my main branch I have excluded the asset catalogs containing the custom symbols. I see no images when browsing those data sets
my app delegate has conditional code to cause a compiler error in non-debug builds. This prevents me from ever accidentally releasing a build without the custom symbols
these changes are inherited by any other branches I make during feature development. Build times are now sensible again
if I ever want to test the custom symbols, I can temporarily include them, go make a cup of tea and hope I never accidentally commit their inclusion
for releases, I have a separate release branch which was taken from main just after I excluded the assets and added my compile-time protection code. The first commit in this branch re-enabled the assets and removed that code. All future releases to the App Store will need to be made by merging to this branch so that the custom symbols are included

Resources

Adaptivity

Adaptivity v8.5 on 12.9" iPad Pro showing split screen multitasking, Popover presentation, and custom sheet presentation of System Colors

SF Symbol Changes in iOS 15.2

Geoff Hackworth — Wed, 17 Nov 2021 16:52:02 GMT

Introduction

When examining the iOS 15.2 simulator in Xcode 13.2 beta 2, I noticed that there had been a few changes to SF Symbols. [EDIT: Xcode 13.2 Release Candidate has now been released and there have been no additional changes since beta 2.]

There are now seven different sets of symbols to consider:

SF Symbols v1.1 available in iOS/iPadOS/tvOS/Mac Catalyst 13.0, watchOS 6.0 and macOS 11.0
SF Symbols v2.0 available in iOS/iPadOS/tvOS/Mac Catalyst 14.0, watchOS 7.0 and macOS 11.0
SF Symbols v2.1 available in iOS/iPadOS/tvOS/Mac Catalyst 14.2, watchOS 7.1 and macOS 11.0
SF Symbols v2.2 available in iOS/iPadOS/tvOS/Mac Catalyst 14.5, watchOS 7.4 and macOS 11.3
SF Symbols v3.0 available in iOS/iPadOS/tvOS/Mac Catalyst 15.0, watchOS 8.0 and macOS 12.0
SF Symbols v3.1 available in iOS/iPadOS/tvOS 15.1, Mac Catalyst 15.1, watchOS 8.1 and macOS 12.0
SF Symbols v3.2 available in iOS/iPadOS/tvOS 15.2, Mac Catalyst 15.2, watchOS 8.3 and macOS 12.1

At the time of writing, the latest version of Apple’s own SF Symbols Mac app is v3.1 (build 63) and has not been updated to include these latest changes. [EDIT: v3.2 (build 67) was released late December 2021 and includes the symbols added in iOS 15.2.]

My own Adaptivity app is a tool for iOS developers and designers, and one of its many features is a very comprehensive view to browse SF Symbols. It can view any of the SF Symbol data sets that your device supports. The screenshots in this article were taken from version 8.4 and demonstrate the symbol changes in iOS 15.2.

For a detailed list of symbols that were added or renamed in earlier iOS versions, see my previous articles:

SF Symbols Changes in iOS 14.0 (SF Symbols 2.0)
SF Symbols Changes in iOS 14.2 (SF Symbols 2.1)
SF Symbols Changes in iOS 14.5 (SF Symbols 2.2)
SF Symbols Changes in iOS 15.0 (SF Symbols 3.0)
SF Symbols Changes in iOS 15.1 (SF Symbols 3.1)

Changes in SF Symbols 3.2

There are relatively few changes this time:

New symbols 15 new symbols, but 2 are right-to-left localizations of existing symbols
Restricted symbols 10 new symbols are restricted
Hierarchical / Palette rendering 6 new symbols support the hierarchical and palette render modes

There are no renames or changes to multicolor symbols.

Added Symbols

These are the 15 new symbols in iOS 15.2:

airpods.gen3
airpod.gen3.right
airpod.gen3.left
airpods.gen3.chargingcase.wireless
airpods.gen3.chargingcase.wireless.fill
beats.fit.pro
beats.fit.pro.left
beats.fit.pro.right
beats.fit.pro.chargingcase
beats.fit.pro.chargingcase.fill
rectangle.leadinghalf.filled
rectangle.trailinghalf.filled
square.3.layers.3d.down.right.slash
square.3.layers.3d.down.left.slash
square.3.stack.3d.slash

Adaptivity’s ‘Availability’ annotation (selected from the Info icon in the bottom right) adds a small 15.2+ annotation to symbols which are new in iOS 15.2. To make it easier to see which symbols are not supported in iOS 13, there is no annotation shown for symbols that were available in iOS 13 (unless they were renamed since).

Adaptivity also has a custom ‘Added’ collection which shows all the symbols that have been added in the data set you are viewing:

iOS 15.2 System Images ‘Added’ collection in Adaptivity v8.4 on iPhone 13 Pro Max in monochrome, hierarchical and palette render modes

Restricted Symbols

In Adaptivity, a red ⓘ button indicates a symbol is restricted. Tapping the button shows an alert explaining how the symbol can be used. Adaptivity also has a custom ‘Restricted’ collection which shows just the restricted symbols. The 10 new restricted symbols brings the total number in iOS 15.2 to 267:

iOS 15.2 System Images ‘Restricted’ collection in Adaptivity v8.4 on 12.9" iPad Pro

Hierarchical and Palette Symbols

The screenshot above in the “Added Symbols” sections shows the 6 new symbols which support hierarchical and palette render modes. Here’s a closer look at two of them:

iOS 15.2 System Images context menu in Adaptivity v8.4 on iPhone 13 Pro Max in hierarchical render mode

Localized Variants

Apple’s naming conventions use words such as leading, trailing, forwardand backward for symbols that have right-to-left localized variants. In general (but not always), symbols with words such as left and right do not change. There are many symbols which come with both fixed left/right and localized leading/trailing versions.

The text.justify.leading andtext.justify.trailing symbols added in iOS 15.1 are named to suggest they ought to change appearance, but still do not. See SF Symbols Changes in iOS 15.1 for more information.

Adaptivity has an optional right-to-left annotation (⇄) to identify symbols that have right-to-left localizations. There is a custom ‘Right-to-Left Localized’ collection to make them easy to find. Adaptivity can also show the image variants for right-to-left and language localizations.

The new rectangle.leadinghalf.filled
and rectangle.trailinghalf.filled symbols are right-to-left localizable versions of the existing rectangle.lefthalf.filled and rectangle.righthalf.filled symbols.

iOS 15.2 System Images localized variants in Adaptivity v8.4 on iPhone 13 Pro Max

Resources

Adaptivity

SF Symbol Changes in iOS 15.1

Geoff Hackworth — Thu, 28 Oct 2021 17:43:02 GMT

Introduction

When examining the iOS 15.2 simulators in Xcode 13.2 beta 1, I noticed that there had been a few changes to SF Symbols since iOS 15.0. After testing on real devices I discovered that these had been added in iOS 15.1. There was no Xcode release that included an iOS 15.1 simulator, so I hadn’t noticed the change until iOS 15.2.

There are now six different sets of symbols to consider:

SF Symbols v1.1 available in iOS/iPadOS/tvOS/Mac Catalyst 13.0, watchOS 6.0 and macOS 11.0
SF Symbols v2.0 available in iOS/iPadOS/tvOS/Mac Catalyst 14.0, watchOS 7.0 and macOS 11.0
SF Symbols v2.1 available in iOS/iPadOS/tvOS/Mac Catalyst 14.2, watchOS 7.1 and macOS 11.0
SF Symbols v2.2 available in iOS/iPadOS/tvOS/Mac Catalyst 14.5, watchOS 7.4 and macOS 11.3
SF Symbols v3.0 available in iOS/iPadOS/tvOS/Mac Catalyst 15.1, watchOS 8.0 and macOS 12.0
SF Symbols v3.1 available in iOS/iPadOS/tvOS 15.1, Mac Catalyst 15.0, watchOS 8.1 and macOS 12.0

An app can only use symbol names that are supported by the OS version it is running on. Symbols that were renamed are still available using their earlier names for backwards compatibility. However, Jiang Jiang (who appears to work at Apple) mentioned on Twitter that:

It is worth noticing that while aliased (old) names continue to work it is definitely better to migrate to the up-to-date names for performance reasons.

The minimum iOS deployment version of your app will determine which symbols you can use and whether you must keep using the older names (or use runtime availability checks to use the new names on later versions). In my testing, a Mac Catalyst app running on macOS 12.0.1 does not pass a runtime availability check for iOS 15.1, but it does support the new symbols.

At the time of writing, the latest version of Apple’s own SF Symbols Mac app is v3.0 (build 60) and has not been updated to include these latest changes. EDIT: v3.0 (build 63) was released around November 12th 2021.

My own Adaptivity app is a tool for iOS developers and designers, and one of its many features is a very comprehensive view to browse SF Symbols. It can view any of the SF Symbol data sets that your device supports. The screenshots in this article were taken from Adaptivity v8.2 and demonstrate the symbol changes in iOS 15.1.

For a detailed list of symbols that were added or renamed in earlier iOS versions, see my previous articles:

SF Symbols Changes in iOS 14.0 (SF Symbols 2.0)
SF Symbols Changes in iOS 14.2 (SF Symbols 2.1)
SF Symbols Changes in iOS 14.5 (SF Symbols 2.2)
SF Symbols Changes in iOS 15.0 (SF Symbols 3.0)

Changes in SF Symbols 3.1

There are relatively few changes this time:

New symbols 11 new symbols, but 2 are (supposedly) right-to-left localizations of existing symbols
Renamed symbols 2 symbols have been renamed
Hierarchical / Palette rendering 9 new symbols support the hierarchical and palette render modes. 2 existing symbols with incorrect layers have been fixed
Localized variants 4 symbols are named to suggest that they support right-to-left localizations, but 2 of them don’t actually change appearance

There are no changes to multicolor or restricted symbols.

Added Symbols

There are 11 new symbols in iOS 15.1:

bolt.ring.closed
platter.filled.top.iphone
platter.filled.bottom.iphone
platter.filled.top.and.arrow.up.iphone
platter.filled.bottom.and.arrow.down.iphone
square.3.layers.3d.down.right
square.3.layers.3d.down.left
square.3.layers.3d.down.forward
square.3.layers.3d.down.backward
text.justify.leading
text.justify.trailing

Adaptivity’s ‘Availability’ annotation (selected from the Info icon in the bottom right) adds a small 15.1+ annotation to symbols which are new in iOS 15.1. To make it easier to see which symbols are not supported in iOS 13, there is no annotation shown for symbols that were available in iOS 13 (unless they were renamed since; see below for more information).

Adaptivity also has a custom ‘Added’ collection which shows all the symbols that have been added in the data set you are viewing:

iOS 15.1 System Images ‘Added’ collection in Adaptivity v8.2 on iPhone 13 Pro in monochrome, hierarchical and palette render modes

Renamed Symbols

Two symbols have been renamed: text.justifyleft is now text.justify.left and text.justifyright is now text.justify.right.

Adaptivity makes it easy to see renamed symbols. When the ‘Availability’ annotation is enabled, a list of iOS versions is shown for symbols that have been renamed since they were first added. The information shown in the context menu includes previous names when this annotation is enabled.

Adaptivity also has a custom ‘Renamed’ collection which shows all the symbols that have been renamed in the data set you are viewing. For the iOS 15.1 data set, that contains just two symbols:

iOS 15.1 System Images ‘Renamed’ collection and context menu in Adaptivity v8.2 on iPhone 13 Pro

Hierarchical and Palette Symbols

The screenshot above in the “Added Symbols” sections shows the 9 new symbols which support hierarchical and palette render modes.

In iOS 15.0, I discovered two symbols with incorrect layer assignments that led to an inconsistent appearance in hierarchical and palette render modes compared with similarly-named symbols:

iOS 15.0 System Images with layer assignment bugs in Adaptivity v8.2 on iPhone 13 Pro

These have been fixed in iOS 15.1:

iOS 15.1 System Images with layer assignment fixes in Adaptivity v8.2 on iPhone 13 Pro

Localized Variants

Apple’s naming conventions use words such as leading, trailing, forward and backward for symbols that have right-to-left localized variants. In general (but not always), symbols with words such as left and right do not change. There are many symbols which come with both fixed left/right and localized leading/trailing versions.

The new square.3.layers.3d.down.forward and square.3.layers.3d.down.backward symbols are flipped in right-to-left variants:

iOS 15.1 System Images localized variants in Adaptivity v8.2 on iPhone 13 Pro

The new text.justify.leading andtext.justify.trailing symbols are named to suggest they ought to change appearance (especially since there are text.justify.left and text.justify.right symbols that do not change). However, in my testing, they do not change appearance:

iOS 15.1 System Images localized variants in Adaptivity v8.2 on iPhone 13 Pro

This is seen more clearly using Adaptivity’s list view (so the full symbol names are visible) and the Force Right-to-Left option in the Settings screen. This flips the entire user interface in the same way as the Right-to-Left Pseudolanguage option that can be configured in Xcode’s scheme settings when running your own app:

iOS 15.1 System Images in Left-to-Right and Right-to-Left layout in Adaptivity v8.2 on iPhone 13 Pro

Note how the forward and backward versions of square.3.layers.3d.down change in right-to-left so that the forward symbol is the same as the left symbol and the backward symbol is the same as the right symbol. The leading and trailing versions of text.justify do not change.

EDIT: Apple’s SF Symbols Mac app v3.1 (build 63) does not mark these symbols as having right-to-left variants. I still suspect this is a bug, but at least the app is consistent with observed behaviour.

Resources