Explore App Clips

Hello and welcome to WWDC.

Hi. My name is James, and together with my colleague Luming, I'm here to take you on a journey of discovery in exploring App Clips.

In today's session, you'll be introduced to App Clips, an exciting new technology which will help more people connect with your app. We'll go over some example App Clips to help you envision what experiences to create.

We'll cover the basics of creating an App Clip using Xcode. And wrap up with a technology overview to help you go from here.

Before we start designing or building an App Clip, it's important to understand what an App Clip is. And to do that, I want to introduce three concepts to you. The first is your app. This is important because App Clips are an additive feature, and you'll need an app before you can get started with App Clips.

Next is what we're calling App Clip Experiences. These are URLs that when opened on iOS 14 are handled by an App Clip instead of a web browser.

And finally, we need to talk about the App Clip itself. This is what enables people to use your native App experiences without ever needing to install your app. Let's cover these two new concepts in more detail now...

starting with experiences. These experiences form the basis for how people will discover and launch App Clips, and you can think of them as new entry points into your app.

Under the covers, we're using URLs to identify these experiences. And if you've adopted Universal Links previously, you should find the process for handling App Clip URLs very similar. A key difference is that App Clip URLs are not defined by your Apple-App-Site-Associations file but are registered using App Store Connect.

For everything you need to know about creating and customizing these experiences be sure to check out the session, "Configure and Link Your App Clips." Once you've registered an App Clip experience and your App Clip is live in store, it'll be surfaced anytime that URL is opened. From QR codes to NFC tags, links in Safari and Messages, to business details and Maps. No matter how someone uses their device, we'll make sure that your App Clip is given the spotlight. And the best way to discover App Clips will be with a new Apple designed App Clip code, coming later this year. When you see one, you'll know there's an App Clip waiting for you. App Clip codes combine the ease of NFC and visual codes, so you can tap them or scan them and always know that you'll get a great user experience. Next, let's talk about App Clips. As developers, I'm sure some of you are very curious about how we're gonna just run part of your apps on demand. Well, there's no magic. An App Clip requires you to create a second application target in Xcode. This App Clip target will then contain all the necessary code and assets to handle your App Clip Experiences.

While an App Clip target is built much like an app, it still requires a corresponding application, which it will then be built and submitted for review alongside. You cannot upload an App Clip or its app independently of one another.

Once your app and its App Clip are live in the App Store, they become mutually exclusive. Your App Clip is downloaded if someone encounters your App Clip experience but doesn't have your app installed. Otherwise, your app is preferred. This is important to remember, because when someone installs your app, they will expect those experiences to continue working.

And last, because App Clips are focused on providing fast and in-the-moment experiences, you should make them as small as possible so that they download and launch instantly.

Your App Clip must be less than ten megabytes after thinning. And you wanna strike a balance of including enough assets to be immediately usable after launch and download other data only as needed by the user. I've talked a lot about experiences, and I think it's time to show some examples.

Let's consider this flowchart where we have boxes representing screens in an app and lines showing how the user moves between them.

This maps to how a lot of apps are structured. On the left, we start with some high-level choices, such as a Start Page or a Tab bar. And as we move to the right, we drill in through navigation stacks towards some goal. Hierarchies like this are great because they help people navigate complex applications. But when designing experiences for App Clips, I want to challenge you to radically rethink this flow. Start by only including the pieces of your app that play to the strengths of App Clips.

App Clips are encountered in context and at the moment someone needs them. When thinking about what helps users in the moment, staple app features like directory listings or profile screens may no longer make sense.

Next, consider how the URLs you use for your App Clip Experiences can be deep links into these flows.

App Clips should generally omit top-level navigation elements, like Tab bars.

Instead, use separate URLs for any distinct experiences.

For example, you may want one experience for when someone orders a product that will be shipped to them, versus if they're at an in-store checkout. And if your business has multiple physical locations, you should use a URL that identifies the store they're at. This lets you skip showing a store-chooser and go straight to the content they care about.

At the end, what you want to have are focused user flows that guide someone to their goal. This isn't to say that an App Clip can only do one thing. Quite to the contrary, a well-designed App Clip can do many things. However, it focuses on one at a time. But that's enough theory. For a demo of putting this all together, I'd like to welcome Luming to explain how to get started with App Clips in Xcode.

Thanks, James, for your great introduction on exploring App Clips. I'm Luming, an engineer from the App Clips team. Today, I'll be demoing how to create an App Clip from your app.

So here I am in my app Fruta. Fruta lets you browse an entire menu of delicious smoothies, place orders, keep track of your favorite smoothies, get reward points, and explore smoothie recipes. While all these functionalities are great for the full app, we really want to focus on providing a streamline ordering experience for our App Clip. So that is basically all the functionalities in the Menu tab.

So let's create an App Clip.

I've opened the smoothies Xcode project, and I'll create a new target. I'll choose to create a new App Clip target and click Next. I'll call it Fruta Clip. And it's automatically embedded in our full application. You'll notice that Xcode has automatically populated the name and the bundle identifier for our App Clip as well.

Let's run the Clip on device.

Momentarily, the App Clip should build and run. Our App Clip has built and run. Of course, the App Clip is just an empty boilerplate right now. So, "Hello, world!" Here we are.

Let's add some code and resources to the App Clip.

Since the Fruta app has a dependency, Nutrition Facts, I'll need to add that to our App Clip as well. I'll go to the App Clip target and choose to add a new dependency. I'll choose to add the Nutrition Facts dependency.

Next, let's create an asset catalog to share assets between the full app and the App Clip.

I'll choose to create a new file. Then I'll choose to create a new asset catalog and name it Shared Assets.

I'll add it to the Fruta Clip target membership. Now, let's view these two asset catalogs side by side.

Because we need the app icon in both the app and the App Clip, I'll drag the app icon from the asset catalog to the Shared Asset catalog. The same applies for colors, ingredient and smoothie. So I'll drag all of them over as well. Since our App Clip won't include recipes, I'll leave it as is.

Most of my code is organized into groups. So let's go through every group and only add the Swift source files we need to the App Clip target.

Model we definitely need, so I'll go to the target membership and tick the App Clip checkbox.

Store is for unlocking additional recipes, so we can leave it out. Orders, we definitely need it in our App Clip, so I'll tick it as well. But since our App Clip doesn't need a tab bar and focuses on ordering smoothie just from the first tab, which is the Main Menu of the full app, we can let go of the navigation code. Smoothies. We definitely need them, so I'll check it.

Recipes we can leave out. Ingredients. That's a must. And so is Components and Styles. I'll also include the VisualEffectView wrapper and check the Fruta Clip checkbox. I think that's all the code we need in the Clip. Let's build it. Huh. It looks like there's a build error. Why is that? Well, it turns out because OrderPlacedView.swift references Store, which we have excluded from the App Clip in the previous step, our App Clip won't build. We need to conditionally compile out the references to Store in OrderPlacedView.swift. I'll go back to the App Clip target's build settings.

There, I'll find the Swift Compiler - Custom Flags section, and I'll define a new custom condition, APPCLIP, in all caps, for both the debug scheme as well as the release scheme.

Now, we can come back to OrderPlacedView.swift and conditionally compile out references to Store.

Finally, we need to bring up Smoothie Menu in our App Clip.

In our App Clip's FrutaClip.swift file, I'll instantiate a new Fruta model as its data store object.

And pass it to the ContentView as its environment variable.

In the body of ContentView I'll remove the default placeholder, "Hello, world!" and create a new NavigationView.

In the NavigationView, I'll include a SmoothieMenu.

Then we can build and run.

Voilà. We got our App Clip running. The Clip looks and works great. I can browse the smoothie menu...

find my favorite and place an order.

It looks like my smoothie's ready. Time to enjoy my smoothie. Back to you, James.

Thanks, Luming. That was awesome. And I really like how that demo captures just how simple it can be to share code and assets using existing Xcode features.

Shared asset catalogs and source files are also great if you're developing for multiple platforms like Apple Watch and macOS. And it highlights another theme I want to touch on. And that is how we've reused existing technologies to make building App Clips a breeze.

App Clips are built using the same UI frameworks as apps. This includes support for either UIKit or the new SwiftUI app lifecycle.

When launched, your App Clip or app will receive an NSUserActivity. And if your App Clip supports multiple App Clip Experiences, you'll use the web page URL on this activity to know which experience you're handling. This should feel very familiar if your app already handles Universal Links.

And unlike extensions, an App Clip is able to use any API in the iOS SDK. This makes sharing code between your app and your App Clip so easy. However, from your App Clip, access to sensitive user data is limited. But there's nothing special you need to do here. Just be sure to check for access to data before you request it.

As an example, you can share source code that uses the HealthKit framework. But be prepared for HKHealthStore isHealthDataAvailable to always return false when running in your App Clip.

And because of this, you won't find any isAppClip API. Just follow the best practices for the frameworks you use.

To help you build a frictionless experience from tap to tap, we've added a new location confirmation API. Instead of prompting for the full access to someone's location, which they may not feel comfortable giving to an App Clip they've just encountered, use this API to confirm they're where you think they are while respecting their privacy.

To learn how to adopt this and other great tips, be sure to check out the "Streamline Your App Clip" session. Finally, to continue that seamless experience, we're providing API that allows you to migrate data from your App Clip if someone installs its corresponding app. This is done using a shared data container, and I'll talk about it more in a bit.

Developing an App Clip should feel instantly familiar and just like working on an app. However, when developing an App Clip, there are some special considerations to keep in mind. To start, App Clips aren't something people need to manage. An App Clip is run when needed, but if it is never used again, iOS will delete the App Clip and its data. Additionally, App Clips are not included in iOS backups.

With App Clips, we want users to feel safe running app code on demand. As such, we're putting an even higher focus on the privacy of App Clips and outright restricting access to some sensitive data such as health and fitness.

If your corresponding app makes use of these types of data, you can encourage people to install it for even more functionality.

An App Clip is focused on providing App Clip Experiences, and it cannot be launched for other reasons. Because of this, it cannot register for custom URL schemes, document types or Universal Links. This is very important if you're using a custom URL scheme as a callback for a federated sign-in service. In this case, you should instead use ASWebAuthenticationSession, which does not require you to register the URL schemes you use for callbacks.

And as you may have guessed, this also means that App Clips cannot include bundled extensions, like content blockers.

Now that you know some of the similarities and differences between apps and App Clips, I wanna cover how these two interact on a single device.

Say, for example, someone finds a QR code for an App Clip and scans it.

Because there is no app installed to handle the experience, iOS will automatically locate, download and launch an App Clip for the user.

The App Clip gets to run while in use, and then the user moves on.

After a period of time, if the App Clip has not been revisited, iOS will delete the App Clip, its data container and its Keychain data.

If the user encounters the experience again, the entire process repeats, just as before. This illustrates an important point. While App Clips can store data on the device, treat it more like a temporary cache, because it may be deleted at the system's discretion.

Now let's rewind and consider what happens when someone repeatedly uses the same App Clip experience. Perhaps this is an ordering App Clip at their favorite coffee shop, and they visit it every day.

In this case, the App Clip's lifetime will be extended, and it may never be cleaned up because iOS notices that it's used frequently.

So, if the App Clip caches the last order, it could show this as a recommendation to speed up ordering next time. Of course, if someone loves your App Clip that much, they'll probably want to install your app. When they do this, iOS will automatically migrate authorizations for camera, microphone and Bluetooth access. If your App Clip also has data to migrate, you can do so using a new type of group data container, which is automatically made available to both your App Clip and your corresponding app. For this to work, your App Clip should store data that you want to migrate in this shared data container, rather than the App Clip's standard container.

If the user then installs your app, iOS will still delete the App Clip and its data just like before. But this group container will stick around until your app has a chance to copy the data out before going away.

A great App Clip is built using the same best practices and technologies as a great app. That includes supporting Apple Pay for payments, which allows people to quickly make purchases without fumbling for their credit cards. Notifications to alert someone when their smoothie is available or their parking meter is about to expire.

SwiftUI is a great fit for App Clips because of its focus on small and reusable components, which can easily be shared between an app and its App Clip target.

And new this year is SKOverlay...

or if you're using SwiftUI, the App Store overlay modifier. This API is the best way to lead people to your full app after they've had a great experience using your App Clip. You can learn more about it by watching "What's New in In-App Purchase" from WWDC 20. Last, if your App Clip would benefit from associating users with an account, say, to keep reward points on a purchase, you should use ASAuthorizationController from authentication services. ASAuthorizationController allows users to easily sign in to their existing password-based accounts or create a new account using Sign in with Apple. For more information, check out "What's New in Authentication" from WWDC 19.

In summary, App Clips represent a new type of user experience. These experiences can be invoked on demand without someone even having your app installed via a dedicated App Clip binary. However, once your application is installed, it will take over and also handle these experiences.

These App Clip binaries are built using the same technologies as apps, so you can transfer knowledge from writing apps directly to writing App Clips. And App Clip Experiences are streamlined and linear, focused on achieving a specific task. Features such as reward programs should be presented as optional steps after someone has completed their goal. Thanks so much for watching and have a great WWDC. [chimes]