visionOS, Swift Macros, SwiftData, Observation and Symbols frameworks: these are just some of the most important news from the Apple WWDC23. But as every year, there’re also a bounce of minor features and improvements: let’s discover 8 tidbits that could be interesting for your daily work.

1. Xcode Cloud test notes

You’ll be able to include notes for your beta distributed from Xcode Cloud through TestFlight: just create a TestFlight folder in your project’s root and add a WhatToTest.en-US.txt file with the notes.

Thanks to scripting, you can also automate what to write in the notes: in the session and related documentation, it’s explained how to include the last commit message with a post build script. But let’s say you’re defining a workflow where a new build is made for every feature pr opened and your branch naming convention includes the id of the ticket you’re working on: instead of the commit message, with git rev-parse --abbrev-ref HEAD the full branch name will be written in the test notes, so tester can reference to the pr associated ticket easily.

2. XCTest screen recording

XCTest now supports automatic screen recordings, particulary useful with UITests; it’s one of the many improvements in testing in Xcode 15, including an improved test navigator, test report and a new Test Details view.

3. New viewIsAppearing callback

This new view controller callback is a really good addition: it’s called once each time a controller’s view appears, between viewWillAppear and viewDidAppear. Unlike viewWillAppear, it’s called when controller’s view has already been added to the view hierarchy, so with updated trait collections and accurate geometry. Unlike viewDidAppear, it’s called way before animations/transitions are completed. Most importantly: it back-deploys to iOS 13 🎉. You can find the full documentation here.

4. Palette Menu

UIMenu has a new option to display menu items in a row: just use .displayAsPalette as UIMenu.Options in your menu init.

5. UIPageControl progress

By setting the new progress property of UIPageControl, the active indicator will show the page progress. UIPageControlTimerProgress has a built-in timer to set the duration and a UIPageControlTimerProgressDelegate to control the page scroll, but there’s also UIPageControlProgress to follow external timers or video playback:

let progress = UIPageControlTimerProgress(preferredDuration: 5)
progress.delegate = yourDelegate
progress.resetsToInitialPageAfterEnd = true
pageControl.progress = progress
progress.resumeTimer()

6. Widgets background handling

To better align your widgets UI with new places where it can be added, like iPad Lockscreen, iPhone StandBy mode or Apple Watch Smart Stack, it could be useful to remove its background. The new .containerBackground modifier automatically removes the background you define depending on the kind of the widget is being displayed:

struct NewsWidgetEntryView: View {
    var entry: Provider.Entry
    
    var body: some View {
        VStack() {
            ...
        }
        .containerBackground(for: .widget) {
            Color.yourBackgroundColor
        }
    }
} 

7. SwiftUI Haptic feedback

Thanks to the new .sensoryFeedback modifier, you can easily add an haptic feedback in response to an event, like a tap on a button:

struct ContentView: View {
    @State private var saved = false

    var body: some View {
        Button("Save") {
            saved = true
        }
        .sensoryFeedback(.success, trigger: saved)
    }
}

8. New Font TextStyles

There’re 2 new UIFont TextStyle: .extraLargeTitle which is 36 points bold; .extraLargeTitle2 which is 28 points bold. In SwiftUI, these new styles seem to be available only for visionOS target (probably a beta bug).

Bonus: UIStatusBar default behavior

This is great: on iOS 17, status bar using a .default style will continuously adapt to the underneath content and automatically change between light and dark, even by split style between right and left sides. You can see the effect in the UIPageControl progress GIF above.

And that’s a wrap, hope you enjoyed Dub-Dub as much as I did: there’re so many updates to dive into over the next months. Feel free to connect with me on Twitter and Mastodon; thank you for reading! ☕️

• WWDC23 | Apple Developer Documentation
• WWDC23 highlights - Discover - Apple Developer

➡️ UPDATE: read 8 Tidbits from WWDC23 ⬅️

Widgets have been one of the top features of iOS 14 during WWDC 2020, where the biggest change ever of iOS Home Screen has been unveiled. On the user point of view, they represent a new type of interaction, a new entry point for apps; on a technology point of view, they are a manifesto of the way chosen by Apple, where SwiftUI (the only way to build widget’s views) and an optimized universality (widgets are available on iOS, iPadOS and macOS) are key elements.
After experimenting with the WidgetKit framework on iOS 14 and Xcode 12, I want to share 10 interesting tips that could be useful for many use cases when coding widgets for your apps. Disclaimer: I assume you already know how to create a simple widget and basic related APIs. Let’s start! 👨🏼‍💻

1. UserDefaults Suite

Very likely, you’ll need to use UserDefaults from your widgets, in order to read user preferences or some other small amount of data. To do so, the standard container isn’t the way, because its content isn’t shared between different targets; instead, as for any other app extension, you have to rely (from the app and from widgets) to the shared “suite”, named with the App Group ID, using the dedicated api:

let userDefaults = UserDefaults(suiteName: “your-app-group-id”)

The App Group is a capability available in the “Signin & Capabilities” tab of your targets: remember to add the App Group capability both in the app’s target and in the widget’s target, otherwise it won’t work.

2. Location permission

As a general rule, widgets inherit every permission status from the parent app and it’s not allowed to prompt requests from the widget itself. Location permission represents an exception: when a widget using location is added to the home screen, the user will be automatically requested to grant permission through an alert; the choice can be changed anytime from the Settings, as a new “While Using the App or Widgets” option is available.

To get location services work properly, you have to put the boolean key NSWidgetWantsLocation in the widget extension Info.plist: you can check the status by using CLLocationManager’s authorizedForWidgetUpdates property. In addition, remember that the app must request location authorization from the user anyway, before widget can receive data.

3. Maps with MKMapSnapshotter

Talking about location, another question could come up: what is the best way to present a map view inside a widget? The recommended option is to use a MKMapSnapshotter in place of a MKMapView; in fact, the standard map view doesn't work at all. The snapshot captures the map’s contents in a simple image. To get the desired MKMapSnapshotter.Snapshot:

The closure is perfect to be used in the getTimeline(in:completion:) function of TimelineProvider protocol: once the image is loaded, you can create your entries and define the timeline. The snapshot is highly customizable and you find the full documentation here.

4. Memory limit

The map shapshot is a great example of how light should be widget’s content. Videos, animations and so on aren’t available in widgets: moreover, UIKit views wrapped in UIViewRepresentable don’t work in widgets. Related to this topic, you should take into consideration the limit on memory allocation: it’s not explicitly stated in docs, but widgets exceeding 30 Mb seems to crash, so keep in mind this.

5. Updates policy

I’m not going through different ways to update your widget and manage the associated timeline (it would request a dedicated article 😁), but another interesting point is: how often can a widget be updated? Apple updated his documentation with details, common behaviors and side cases about this and you can find everything here. As general rule: a daily budget includes 40 to 70 refreshes, which means reloads every 15 to 60 minutes depending on many factors.

6. ContainerRelativeShape

A simple UI trick is relative to views’ shape inside widgets. To be consistent with the widget corner radius (which changes across different devices), Apple suggests to use the SwiftUI ContainerRelativeShape api, instead of defining custom radius: it will automatically make shapes concentric with the widget corner radius. Here’s an example:

Image("map-placeholder")
    .clipShape(ContainerRelativeShape())

7. Link vs widgetUrl

Once the user interacts (taps) with a widget, the parent app is launched to handle the request: you can specify an url to be passed to the app, in order to do specific actions. There are 2 ways: by using widgetUrl(_:) modifier to define a unique behavior, as it will be applied to all the widget target, or by using the Link control to define different urls for different targets in the view’s hierarchy. As the small widget allows just one single tap target, it’s preferable to use the widgetUrl modifier for it. Let’s see an example:

In the case of medium or large widgets, you can use the two options together: each Link’s url is used for taps in its target view and the widgetUrl for taps anywhere else. The url is handled by the application(_:open:options:) method for apps with classic AppDelegate, or by the onOpenUrl(perform:) api for SwiftUI life cycle apps introduced with iOS 14.

8. Widgets Bundle

Another great feature is the ability to distribute more than a widget for the same app, using the WidgetBundle api:

After some experiments, it seems you can bundle up to 5 different widgets, each with the 3 sizes available, but in this thread there’s a way to overcome this limit.

9. WidgetPreviewContext

While coding your widget, it comes really handy to have a preview of what you’re creating in the canvas area of Xcode Previews. You achieve this by specifying a PreviewProvider; the preview is the widget’s view where the PreviewContext is set as a WidgetPreviewContext:

It’s possible to define more than a single preview, to see widgets in all available family types, as well as modify some environment’s keys: in the example, I previewed a widget in dark mode.

10. Placeholders

Placeholders are used to show a generic representation of the widget view while it loads the first time is added to the homescreen. Through betas, the way to define a placeholder has been simplified and now you just have to implement the required placeholder(in:) function of TimelineProvider, returning a normal TimelineEntry: the redacted(reason: .placeholder) view modifier will be automatically applied. 2 points about this: as now, images aren’t modified by the redacted effect. The second: you can prevent views from being redacted by using the unredacted() view modifier.

To wrap up, I strongly suggest to check Apple’s resources, including the “Widget code-along” collection and “Design great widgets” session from WWDC20. Feel free to connect with me on Twitter and Mastodon; hope to see lots of widgets ready for the fall, thanks for reading!

• Widgets code-along - WWDC20 - Apple Developer
• Design great widgets - WWDC 2020 - Videos - Apple Developer

10 Tips on Developing iOS 14 Widgets was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

➡️ UPDATE: read 8 Tidbits from WWDC23 ⬅️

The week of online WWDC 2020 has unveiled big features and exciting announcements; among with important news, there’re many other notable additions coming with new SDKs. Here’s a list of 10 code snippets will be available with the next iOS’s major release: no more than 5 lines of code each. Let’s start 🧑🏼‍💻

1. SKOverlay

The first api enables us to display an overlay to recommend another app, allowing the user to download it immediately. You can configure the position and set a delegate, in order to respond to events such as appearance, dismissal and errors.

It differs from SKStoreProductViewController because it’s tailored for apps and it’s an overlay rather than a full view. Using the dedicated configuration for clips, the SKOverlay.AppClipConfiguration, you’re able to recommend the app clip’s corresponding app, as showed in demos about App Clips.

2. Configurations

Configurations is a brand new api to specify content and appearance of views and cells. It’s very flexible, because it can be applied to any UIView, including collection and table view cells, and very simple to use at the same time. This is an example of using UIListContentConfiguration:

List content configuration comes with many default configurations. Configurations covers state, content and background specifications; in addition, it’s replacing deprecated tableview cell’s textLabel, detailTextLabel and imageView attributes. Dive into the documentation to learn about all features and use cases.

3. Lists in Collection View

Starting from iOS 14, collection views can now be configured with a list layout, which has a UITableView like appearance (someone marked this as the end of table view’s era), the simple setup is:

Lists come with different styles and list cells with swipe gestures, separators, accessories: Lists in UICollectionView session covers much of these details.

4. Location accuracy

There’re many news about Core Location, included the new accuracy permission, which allows users to choose between full and reduced accuracy when they share their location with apps. What if you need the precise location for a particular feature of your app and the user shared only the approximate one? You’re able to ask for it by using:

The temporary accuracy lasts for the running session only; the key must be added in the NSLocationTemporaryUsageDescriptionDictionary inside the app’s Info.plist and you can add as much keys as you need, to cover different use cases. If you’re interested, I suggest to watch What’s new in location and Design for location privacy sessions from WWDC20.

5. Tracking authorization (2021)

This year focus on user’s privacy didn't cover only location and web browsing, but also data used by apps. If you access the user’s IDFA and other sensible data for tracking purpose, you’re now required to ask permission to users using the new AppTrackingTrasparency framework:

You also need to specify the NSUserTrackingUsageDescription key in the Info.plist. Users can even opt-out entirely from this request, meaning that alerts from any apps will not be fired: the Build trust through better privacy session shows more about this topic.

6. Init UIControls with an action parameter

UIControls can now be instantiated with a handy primary action as parameter using a closure (no more selectors 🎉), like:

Same for UIBarButtonItem or UISegmentedControl (with an array of actions in this case); segmented controls get some other useful methods, like the ability to insert a segment with an action at a specified index.

7. Menu from buttons

Menus can now be shown from any buttons and the Human Interface Guidelines encourages this for many use cases: a good example is the “history menu” showed with a long tap on the back button in a navigation bar. Showing a UIMenu from a button is really easy thanks to the new initializer:

8. UIColorPickerViewController

Yes, an easy to use controller to manage the selection of a color from a UIColorWell 🎨 using colorPickerViewControllerDidFinish(_:) and colorPickerViewControllerDidSelectColor(_:) delegate’s methods:

9. UIPageControl and UIDatePicker additions

UIPageControl has new nice features, included the ability to set images as custom page indicators. UIDatePicker comes with a brand new UI, a pop-up menu and the new .inline style:

10. Mac Idiom

Thanks to the new mac user interface idiom, it’s now more convenient to optimize UIs and behaviors for Catalyst apps (well, not only Catalyst apps, as any apps will potentially be able to run on Macs powered by Apple Silicon):

if UIDevice.current.userInterfaceIdiom == .mac { //Your code }

And that's all! Hope you enjoyed Dub-Dub as me, we have big features and small improvements to dive in during next months. Feel free to connect with me on Twitter and Mastodon; thanks for reading and catch up on the next article ☕️

10 Code Snippets from WWDC20 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

“An amazing platform to learn coding, a great developer tool” is a good definition for Swift Playgrounds, because it summarises two main use cases the platform gives us: on one hand, a way to learn coding (in Swift) with a challenge based approach, where learners are guided in the learning process with incremental steps, concepts and tools, tailored to get programming to more people. On the other hand, a great developer tool to run Swift code on iPad or outside a classic Xcode project/workspace, giving developers the chance to prototype features, easily test interactions which require device capabilities (like accelerometer), isolate issues from large codebase, create learning experiences: in few words, it’s the fastest way to code with Apple’s APIs.

I enjoy using Swift Playgrounds in my developer life and since I won a WWDC Scholarship back in 2018. In this article, I want to dive into the evolution of playgrounds and point to some interesting features, use cases and ways to craft a good playground.

From the Introduction to the Mac app

Playgrounds were first introduced in 2014: Xcode > New Playground was the easier way to start experimenting with the brand new Swift language. One year later, Playground in Xcode 7 was updated with inline results, pages, markup. In 2016, the Swift Playgrounds iPad app was launched, with code challenges designed by Apple to learn coding and the new playgroundbook format. From there, the app has gained new features every year: ARKit and camera access, Playground Support and Bluetooth frameworks, most of iOS SDK frameworks, 3rd-party subscriptions, just to mention some of them.

With the 3.0 version, modules arrived in Swift Playgrounds: folder of Swift files shared across the book with multiple access control levels available, enabling modularization, scalable and reusable code. While Xcode Playground remains a great developer tool, the Swift Playgrounds app has covered during time not only the learn coding side, but even many developers use cases, as mentioned in the introduction, with a important issue: playground books were running only on iPad. Until March 2020, when Swift Playgrounds for Mac was released.

.playground vs .playgroundbook

As you may already know, a playground usually comes with an editor view on the left, which contains code and (eventually) prose with markup and annotation features; and the live view on the right (if setted). The result sidebar shows a representation of values on corresponding line, customizable using the CustomPlaygroundDisplayConvertible protocol. But, as I wrote above, when we talk about playgrounds, there are two available formats: the .playground and the .playgroundbook. What are the differences?

The .playground is available from the very beginning: it’s the only format compatible between Swift Playgrounds apps and Xcode, enabling seamless workflow. In fact, you can create a .playground right on the iPad, using the “Playground Xcode” template, and then open the file on the Mac, both on Xcode or from the app. With a standard playground you can create multiple pages, write prose with markup, but modules are missing (even if there are shared and page relative sources). It’s the right choice if you need to switch between Xcode and iPad frequently, with full compatibility, having an immediate on-device feedback while implementing features. Some other powerful features of .playground come from the integration with Xcode: you can read more about them in the last section.

On the other hand, there’s .playgroundbook: the default format when you create a new document from standalone apps, it has a package-based structure defined by folders and plist files.

It comes with exclusive features, including already mentioned modules, to organize and modularize code; chapters, to group playground pages with the same topic, and cutscenes, which are fullscreen pages (in HTML or Swift) to show introductions or explanations; a key-value persistent storage, to save data and load it across multiple sessions; a glossary, to define terms cited in the page’s prose; and a system of hints, spoilers and solutions to help learners progress through page’s challenges.

With the exception of modules, these features are focused on learning experiences. For this reason, the book format is the right choice if you want to create rich learning experiences and tutorials; but it’s a powerful tool to code and prototype without Xcode as well. As now, Xcode can’t even run a .playgroundbook, even if it’s possible to open a book, navigate and modify its structure and files.

PlaygroundSupport Framework

In order to take advantage of all playground’s features, you should use the PlaygroundSupport framework, which enables you, according Apple’s documentation, to:

Access a playground page and manage its execution, as well as manage live views; access and share persistent data; assess the progress of the learner, update hints, and show success text

First, setting the live view: by doing so, playground is able to render your UI stuffs. Live view can be any UIView, a controller, or even SwiftUI View:

PlaygroundPage.current.setLiveView(Text("🤓"))

Playground runs in a synchronous way, so it terminates once the last line of code has been executed: this is a problem if you want to work with asynchronous code. To run playground asynchronously, you either set a live view or use the dedicated api:

PlaygroundPage.current.needsIndefiniteExecution = true

You can import files in playgrounds and use the Bundle.main api to access them. As said, books are able to persist data across sessions, by get or set:

PlaygroundKeyValueStore.current["your-key"]

By default, live views run in the same process of playgroundpage’s code: the good is you can access them directly, the bad is that run command reset everything. Playground book offers the feature to run an always-on live view in a dedicated process: this means it persists through different runs, enabling you to edit and run code on the editor. How to communicate between an always-on live view and the playground page? Let’s see an example: we want to send our mood to an always-on view responsible to display it. To configure an always-on live view, we have to put a Live.swift file inside the playgroundpage, where we call the setLiveView function: unfortunately, we can’t do this on standalone apps, so we need to edit the structure of the book from the Mac or use the Xcode template (see next section for more details). After that, we can send our Mood from the playground page using:

The full list of types you can send as messagges is available here. To handle messages, just adopt the PlaygroundLiveViewMessageHandler protocol on the object set as live view, in our case a UIViewController:

And we did it! Use Messenger.send(.happy) from the page, run it and the live view will be updated. Similarly, to send messages from the live view to the page, there’s the PlaygroundRemoteLiveViewProxyDelegate protocol: you can find full framework doc here; the Moods book is at the end of this article.

Standalone apps, Authoring Books, Xcode Playground

Other than formats, the tool you decide to use makes the difference in the playground world. With standalone apps, you’re able to create complex books; code from iPad and then continue on Xcode using the .playground format; more in general, to handle many use cases other than learn coding. And of course, it’s the only way to run books.

When talking about authoring books with rich learning experiences, you can’t rely just to the app. First, you can’t edit the prose in the editor; well, you can, for example, type /*:This is a sentence*/, close the book, open it again and the sentence will be rendered as prose but… you can’t modify/delete it anymore 🤯. Same happens to annotations like editable regions or hiding: there’s not a rendered-raw markup switch. Moreover, from the apps you can’t create chapter, cutscenes, glossary, hints, handle messages between always-on live view and editor (as we saw above).

For these purposes, you have to edit the book by modifying its structure, plists, sources and resources on a code editor. If you want to start a new book from scratch, Apple provides an Author Template: it’s a Xcode project where you create the entire book’s structure and contents. When you build the project, a .playgroundbook is created, ready to be exported. Being integrated in Xcode, the template offers many benefits: for example, an easier way to use storyboards (compiled stoyboards are packaged in the book) and test the UI.

Before the conclusion, Playground in Xcode deserves few more words, because it covers some other powerful use cases for developers. First, before the introduction of CreateML, playground in Xcode was the easier way to train a CoreML model right on the Mac. The editor is able to show formatted or raw markup: a unique feature to create prose and check it immediately. In addition, there’s dedicated api to customize TouchBar contents; and the step by step execution (using the tool on the left of the editor) allows to run single lines of code, having the chance to respond to live data. Playground in Xcode can even import 3rd-party frameworks as showed in a WWDC18 session, in order to show or test framework’s api: having a framework target, drag the framework project into the playground’s window and it will be converted in a workspace, build the framework and you can import it into the playground.

Someone pointed to Swift Playgrounds app as a sort of “light Xcode for the iPad”; the release of Swift Playgrounds for Mac (and the rumoured Xcode porting for the iPad?) clarifies one more time they are two different products, with different use cases. But what about next steps? I would love to see an easier way for authoring playground books; a better integration with Swift Package Manager; or some brand new APIs in the PlaygroundSupport framework.

Here’s some useful resources, including the link to download the playgroundbook sample, full Apple’s documentation and a playlist of WWDC videos about playgrounds. Thanks for reading! ☕️

• francesc-o/PlaygroundBookSample
• Swift Playgrounds
• All Videos

The Evolution of Swift Playgrounds was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

It has been a while since the introduction of the Dark Mode with iOS 13 and a lot has been written about dynamic colors, color sets, dynamic images/materials and other tools to support this new style.

After facing some challenges, I want to dive in with some UIKit tools which may be useful for particular needs. Let’s start! 🧑🏼‍💻💡

The basics: custom dynamic color

As you may already know, dynamic colors are available through 3 different ways: by using system-defined semantic colors (like systemBackground, label, systemRed and so on), by defining custom UIColor sets in the Assets.xcassets or by coding your dynamic colors like:

User Interface Level and Traits

Think about Apple’s apps, like Messages, in Dark Mode: the same backgroundColor looks black on the main view, but dark gray on a controller presented with the new .automatic modal style. It’s a little detail that gives to users (combined with the animation) the sense of modality. By defining in code your custom dynamic colors, you’re able to achieve the same result, just use the userInterfaceLevel property along with the already known userInterfaceStyle of UITraitCollection:

case .dark: return traits.userInterfaceLevel == .elevated ? elevatedDark : dark

These kinds of customizations are available not only for colors, but for other UI elements, like images, that you may want to adapt to different styles.

More in general, the style and level of the user interface are just the most common traits you may use to adapt your UI to Dark Mode, but UITraitCollection offers a complete set of tools to fine-tune our UI, based on many different environment conditions: you can find more about it in the official documentation.

Resolve dynamic color/image

There are some use cases where you may need to know the current RGB value of a dynamic color, for particular needs; in some other use cases, like working with CALayer, you have to know the current value of a dynamic color. In these situations, we can resolve dynamic colors (as well as images) using the system defined API:

Let the user choose (overriding)

Following the system defined style is the main (and always good) way to adapt our app’s style; but let’s say we want to give our users the freedom to choose which style the app should adopt among light, dark and system, because of the particular type of the app or just as a customization option. The UIUserInterfaceStyle key of Info.plist doesn't help us, because it locks the UI to a single style. The overrideUserInterfaceStyle method overrides style on screen, windows, views and controllers (and their descendants), but how would we use it efficiently? Let’s see this reeeally simple implementation:

• the user can choose among light, dark and system styles: the last one refers to the UIScreen’s userInterfaceStyle, which is always the system level style;
• when the user switch style, we override the keyWindow’s style by calling the updateTheme function, so the change automatically spreads across the app and we store the user’s preference;
• NB: if you’re using the new UISceneDelegate to manage multiple windows, you should rely on that API instead of keyWindow.

And that’s all, thanks for reading! ☕️ You can find some official resources about Dark Mode at these links:

• Apple Developer Documentation
• Dark Mode - Visual Design - iOS - Human Interface Guidelines - Apple Developer

Dark Mode Tips for iOS was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.