Changes to Xcode and SwiftUI in WWDC 2024 - Part 1
iOS 18, iPadOS 18 and MacOS 15
I’ve started watching the WWDC 2024 videos, after I watched the Keynote and Platforms State of the Union presentations. There are significant changes to programming for Apple devices, even with the lack of AI-related features yet. Since I mainly develop with SwiftUI with Xcode, I will cover some of these changes - as relevant to my own development - in this post after trying the Beta versions.
SwiftUI - Sheets
One of the announced changes to SwiftUI was the handling of sheet sizes when using the .sheet modifier in any SwiftUI View. Sheets are views that come on top of other views with the intent of performing some additional work without losing where you are in a list or within another view. Previously, the .presentationDetents modifier was introduced and this enables the developer to select the relative size of the sheet that pops up, with .medium, .large and other complex modifiers to determine how large the sheet can get and whether the user can resize the sheet etc.
Apple has now set some default values for sheet sizes stating with the new releases and suggests the following (from iOS 18 and iPadOS 18 release notes):
SwiftUI sheets presented with the .sheet modifier now use .automatic sizing by default. .automatic resolves to .form or .form.fitted(horizontal:false, vertical: true) depending on the platform (see the symbol’s documentation for more). Platforms prior to iOS 18 and aligned releases used different, non-customizable default sheet sizing. iOS 17 and earlier used what is now called .page presentation sizing. macOS 14 and earlier used what is now called .fitted sizing. visionOS 1 used .fitted sizing. When linking apps against iOS 18 and aligned SDKs, audit your sheet presentations and pick the sizing best for you. Apply a .presentationSizing modifier to sheet contentsAn example of this would be the following code. One can use .page or .form with the modifier .presentationSizing depending on how big a space they would like the sheet to occupy on the screen.
One issue I found was that when I re-compiled my book management application for iOS, my edit sheet just did not appear (apart from the buttons) on my iPad. It worked properly on the iPhone.
Once I added the presentation sizing, the sheet appeared with its designated size. I must note that this was not the case for all of the sheets I had, so I think this may be a beta issue.
Button defaults
I’ve noticed an unannounced behaviour change for SwiftUI buttons. I typically use a Save-Cancel button pair for editable views as seen in the code below:
The ‘Save’ button does some management of information on screen before saving and the ‘Cancel’ button typically dismisses without saving and does a rollback if necessary. The modifier .borderedProminent along with the button roles .destructive and .cancel makes sure that we have a prominent Save button (in red before iOS 18) and a regular Cancel button. See an example (with the buttons in Turkish corresponding to Save and Cancel shown in red and blue respectively)
However, this seems to have changed with iOS 18, as we see blue buttons for each case.
I haven’t seen an explanation for this but I’m hoping to discover the cause shortly.
TabView
TabViews can now use a sidebar for iPadOS, which can use the screen efficiently. The default for a TabView will be a tab floating on top of the view (also on iOS).
Changing this behaviour is easy. We add a modifier showing that this TabView is adatptable to the use of a sidebar. I also added a red tint, which you will observe to change most of the default UI colours to Red.
Now, this TabView can use a sidebar. The user has to tap the symbol that is leftmost on the floating menu to convert the view to use a sidebar.
This is now much more practical to use on an iPad. Note that this does work when run on an iPhone, thus the TabView stays as it is.
(to be continued…)