Build light and fast App Clips

♪ ♪ Hello and welcome. I’m Brian Goldberg, an engineer on the App Clips team. I can’t wait to show you some great tips and techniques to build light and fast App Clips. Let’s get started. App Clips are a great way for your customers to quickly access and experience what your app has to offer. An App Clip is a small part of your app that’s discoverable and downloaded at the moment it’s needed.

App Clips are deeply integrated into the OS. They can be invoked in Safari and Messages as well as out in the real world by scanning an App Clip Code, a QR code, or by tapping an NFC tag. App Clips are also surfaced in Maps and Siri suggestions. This session is loaded with best practices and troubleshooting tips that will help you build and deliver great experiences for your customers. I’ll show you a plan for getting your clip under the size limit.

Maybe your App Clip isn’t being surfaced on your web page or the App Clip card does not appear when you scan a code.

Perhaps you’re looking for some tips on maintaining quality in your code base, while taking on the added complexity that comes with adopting new features.

And maybe you’re curious to know what functionality you can leverage that’s specific and unique to App Clips. Whether you’re building from scratch or adding a clip target to an existing app, I’ll walk you through real-world issues developers face on a daily basis, and I’ll give you actionable next steps for building better clips and apps. Even when your users are in areas with good mobile network coverage, their download speeds can vary.

To ensure that App Clips can be provided on demand at a moment’s notice, the maximum size of an App Clip is limited.

Therefore, as a developer, it’s important to optimize your content for size. It’s good to know early on and often during development if your clip is compact enough to be delivered on-demand.

Many of you are familiar with the iterative process of profiling and optimization in software development.

I’d like to show you a process where you can use Xcode to generate a size report and export an IPA for each device variant.

Then I'll walk you through a set of basic and advanced optimizations you can perform to reduce the size of your App Clip. The goal is to avoid being surprised at app submission time if your clip is over the limit. I put together a fun example for us to look at. It’s a version of the Fruta sample that has a number of gotchas that put it over the size limit. The gotchas are simple to illustrate some key points. Your apps are undoubtedly more complicated and have tons more features, so please use my example as a starting point for further exploration. Let’s start by launching into Xcode to go through the steps to generate the size report and export the IPA files, and we’ll uncover these gotchas and learn how to fix them together.

First select the full app scheme.

Then go to the Product menu and choose Archive.

This builds the project using the configuration specified in the scheme editor.

When the organizer opens, click Distribute App. Choose Development.

Now select your App Clip.

In the App Thinning dropdown, choose all compatible device variants. Make sure that rebuild from bitcode is checked.

When the archive is done preparing, click Export.

Then select a location on the file system to export to.

Now open the Export folder in Finder...

And then open the App Thinning Size Report.txt.

There’s a section for each device variant.

The second to the last line in each section will tell us the uncompressed size for that variant. That’s what we’re interested in. Looking at the size, this tells me two things. One, I’m over the size limit. Two, I’m not seeing the effects of app thinning because all the device variants are around the same size.

Let’s close the size report and dig a bit deeper to see why that is.

Open the Apps subfolder. Rename one of the variant IPAs extension to .zip, and confirm. Double-click to uncompress. Open the Payload folder and Control-click to show the package contents.

Let’s look closely. Looks like my images are individual bundle resources. Perhaps I’ll save some space if I put these in an asset catalog.

I see a documentation zip and a README file that don’t belong here in the installable product.

There’s a framework being used by my clip. I bet that’s taking up some space too.

I see some localization folders present, and I know that sometimes these files can grow if left unchecked.

The compiled executable is relatively small... but maybe there’s a way to get it even smaller. Every little bit helps. Let’s continue on and see what can be done to fix some of these issues. That process of generating a size report and looking through the IPA was very helpful because it identified a number of steps I can take to reduce the App Clip size. Let’s start with some basic steps first, and then we’ll move on to more advanced techniques. We’ll double-check the build settings, we’ll go over the benefits of using asset catalogs, we’ll exclude any files from making their way to the final product that don’t belong, and we’ll go through our code and settings and refactor for size reduction. Keep in mind the optimizations we’ll cover apply to both your app and App Clip, so feel free to apply these tips to both types of products. Now let’s explore each topic in more detail. The compiled code portion of the App Clip package certainly wasn’t the largest contributor to the clip’s size. It was definitely the assets, which we’ll get to in a moment. But every little bit helps. By default, Xcode will build using the smallest, fastest optimization setting, but let’s double-check to make sure that’s what’s set in my project. Make sure the full app is set as the active scheme and Option-click to display the scheme settings. Our archive build should be set to release, but it looks like I changed it at some point and forgot to change it back. I was also experimenting a bit in build settings and moved the release optimization level off of the default. Let’s change it back so that we’re using the best combination of small binary size and fast runtime execution. Most of the time, as in my case, assets like images, audio, and video take up the most space. The most important step you can take to reduce the impact these assets have on your App Clip size is to use asset catalogs, and this is for two reasons. One, the media you add to asset catalogs is automatically optimized as part of the Xcode build process. And two, when customers download your app or clip, the product they download will be made small enough to only contain assets suitable for their device. This is also known as app thinning, and we should certainly take advantage of it.

In my project, I really should have put those images in an asset catalog. We can actually do even better. I’ll create a second asset catalog, and I’ll move all the images that are shared between my app and App Clip into this catalog.

Let’s bring both catalogs side by side.

We’ll move the icons and colors into the shared catalog.

Then we’ll put the ingredient and smoothie images into the shared catalog.

Since the recipe images are only needed by the full app, I’ll put those in the unshared catalog so they don’t count against the size of my App Clip. I’ll make sure to remove those images that I copied over to the asset library.

And last, I’ll use the target membership editor to exclude the unshared asset catalog from my App Clip. For a deep dive on the asset catalog, check out the sessions on optimizing storage in your app and optimizing app assets.

Earlier, we inspected the IPA on the file system, and we saw a few things that didn’t belong like a README file and a zip containing documentation. Let’s go ahead and use the target membership editor in Xcode to exclude these files from all of our build products. Ensure you’re only including code in your App Clip target that’s necessary for the task being performed.

I find it helpful to look in the build phases to get an overview of every source file that is contributing to my App Clip.