By Dan Moren
June 24, 2020 7:24 AM PT
WWDC 2020 Tuesday: Session Impressions, Part 2
One of the best things about virtual WWDC is that sessions no longer feel the need to expand their talks to fit into a certain time slot—nor does the number need to reflect available physical space. So this year, Apple seems to have provided even more sessions than usual, but many are in bite-sized chunks, and more than a few are ten minutes and under. Here are a few talks that I found interesting on Tuesday of this big week.
What’s New in SiriKit and Shortcuts
The keynote spent some time talking about the refinements to Siri’s UI, and the revamp of the voice assistant ties nicely into some refinements to Shortcuts, which didn’t get much stage time this year.
Namely, Shortcuts gets the same compact UI that Siri now has in iOS 14 and iPad 14. Perhaps the best part of the experience is that shortcuts no longer need to open the Shortcuts app to continue their task now. Any Shortcuts user can tell you that its previous experience of launching the app and stepping through the various actions within it was fine, but not particularly elegant.
Apple’s also increased the capabilities in this new compact UI. So, for example, a disambiguation interface—asking the user to pick an item from a list, for example—can now also provide images and subtitles in addition to the main option. That way you can be sure you’re picking the right item, such as the soup you want.
While we know that Shortcuts get folders in iOS 14, the app also includes a couple of prebuilt Smart Folders showing which shortcuts are available in the Share Sheet or on the Apple Watch. It doesn’t look like users will necessarily be able to create their own Smart Folders, though—or at least, not yet.
There have also been improvements to the Automation abilities of Shortcuts, including more trigger types like receiving an email or text message, the battery hitting a certain level, connecting to a charger, and closing an app. Plus, more of those trigger types can run automatically, requiring no prompt from the user. And the Gallery part of shortcuts will offer suggestions for automations in addition to standard shortcuts.
iOS 14’s new Wind Down feature will also provide a lot of opportunities for shortcuts as we learn more about it.
All of these features point towards Shortcuts becoming an increasingly integral part of Apple’s iOS and iPadOS platforms, and these improvements will go a long way toward making it even more approachable for many users.
Meet Safari Web Extensions
But Apple’s approaching this in an unsurprisingly Apple-like fashion. If you want to distribute a web extension, it’s got to be wrapped in a native Mac application designed in Xcode. Installing the app from the app store will also install the web extension.
The good news is: for developers with existing web extension written for another browser like Chrome or Firefox, Apple provides a command line tool to convert the extension into an Xcode project. That handles a lot of the work for the developer, creating essentially a barebones wrapper app—little more than a window with a button to open Safari preferences. (For testing, it uses an ad-hoc signing process, meaning you have to enable unsigned extensions in Safari’s Develop menu.) This is a hugely exciting move, since Chrome and other browsers have huge libraries of powerful extensions, and in theory not only will these be open to porting to Safari, but it could help bolster future development of extensions that work on all browsers.
One thing that I started to wonder about during this talk was the platform availability. All the demos revolved around Safari web extensions available on the Mac, though the talk makes a point of not targeting user agent strings (information a browser reports about its own version and what system it’s running on), but rather asking about features that might be present. Given that other types of Safari extensions are available on iOS/iPadOS (namely content blockers), might web extensions eventually make their way to Apple’s mobile platforms as well? One can hope.
iPad and iPhone Apps on Apple Silicon Macs
There was perhaps no more surprising announcement during Monday’s keynote than the ability to run iPhone and iPad apps, unmodified, on the upcoming Apple Silicon Macs. In retrospect, given that these new Macs will run on the same processor architecture as Apple’s mobile devices, perhaps that shouldn’t have been a surprise.
But the ease of it is still kind of mind-blowing. iPad and iPhone apps will run on these Macs without even the need for recompiling. To do so, they’ll leverage the same technology that powers Mac Catalyst: the native Mac version of iOS’s UIKit.
The big question has been: if apps from iOS will run on macOS so easily, why even bother with converting an app using Mac Catalyst? Well, the latter still offers some benefits: for one thing, since iOS and iPadOS apps will run with no changes, you won’t really be able to customize their behavior on a Mac, meaning that still ultimately feel like iOS apps. For another, these apps only run on Apple Silicon Macs, so if you want to support Intel Macs—and the vast majority of Macs in existence will continue to be Intel Macs for some time yet—then Mac Catalyst is your only option.
But, if your iOS app is compatible with Apple Silicon Macs—which means it doesn’t require frameworks, functionality, or hardware that is missing on the Mac—it will automatically be available on the Mac. (However, developers can still control which of their apps are actually on the store.)
To ensure compatibility with the Mac platform, iOS app developers need to account for certain differences in hardware, UI, and system software. That includes everything from including hardware keyboard support (which will make the app a better iPadOS citizen as well) to supporting the Split View in multitasking on iPadOS, which will automatically give your app a resizable window on the Mac. (iPhone apps, however, are not resizable when run on the Mac.) It also means using the right APIs for accessing things like the file system, relying on features like Core Location (rather than specifically GPS, which Macs obviously don’t have), and not hardcoding the types of devices you expect the app to run on, i.e. detecting if this is an “iPad” or an “iPod touch.”
When it comes to distribution, making an iOS app available on the Mac is basically exactly the same as doing so on iOS, right down to the app thinning methods that deliver only the code needed for that platform. “In fact,” says Patrick Heynen of the Frameworks team, “for app thinning, a new Mac looks just like any other very capable iPad.”
The only real difference is that the Mac doesn’t support TestFlight for testing distribution…though I have to imagine that it might be on its way at some point.
There is something very important that Nahir Khan, a manager on the iOS System Experience team, needs you to know about widgets: they are not mini-apps. That means no controls or buttons or sliders. (Sorry, PCalc.)
Widgets have a very specific use case, defined by three characteristics: glanceable, relevant, and personalized. If you think that sounds familiar, you’re right—they’re the same qualities emphasized by complications on the Apple Watch, and WidgetKit even takes some of its cues from that system. And, as on the Watch, users want their information to be up-to-date and available, since, as Khan cites, people visit their iPhone home screens more than 90 times a day and seeing a bunch of loading spinners every time you go to your homescreen is definitely not a great experience.
Hence, the widget team has leveraged a similar technology from the Watch complications, building widgets using timelines. Apps can preload the widget with the information the should display at certain times. For example, if your calendar knows you have events at 9am, 9:30am, and 10am, it can give all that information to the widget, which automatically knows what information to display at the current time. If the information in the app changes—whether because it gets a background notification updating it, or a user makes a change—it can tell the widget to reload that information, so it remains up to date.
What’s cool about widgets is that they work across all different devices, are often available in a variety of sizes, and, because they’re built on the same Intents framework used for Siri and Shortcuts, they can handle configuration automatically. For example, when you go to configure the Stocks widget, it can provide a list of the symbols in the Stocks app—but, if you need to find a stock that’s not already in the Stocks app, it can let the user search and then use the Intents framework to go and search for the right symbol. Basically, this helps make it easier for app developers to add widgets without having to redo all the work they did in their app.
Even though widgets may not be mini-apps, they do support deep-linking into a certain part of an app. For example, tapping on an album in the Music widget can take you to a view of that album in the app. And is it possible that interactivity might be available in the future? I wouldn’t rule it out, though it seems as though Apple is happy to keep these as mainly readable experiences for the time being.
Widgets have, of course, been around for a long time on the Mac, where they used to live in Dashboard; more recently, they’ve provided some more minor functionality in the Today view on Apple’s platforms. But with WidgetKit and the changes in iOS 14, it seems clear that they’re about to be catapulted into prime time with their appearance on the iPhone home screen.
[Dan Moren is the official Dan of Six Colors. You can find him on Twitter at @dmoren or reach him by email at firstname.lastname@example.org. His latest novel, The Aleph Extraction, is out now and available in fine book stores everywhere, so be sure to pick up a copy.]
If you appreciate articles like this one, support us by becoming a Six Colors subscriber. Subscribers get access to an exclusive podcast, members-only stories, and a special community.