During our most recent Lab Day we experimented with App Clips. This new iOS feature, discussed in detail in this earlier blog post, allows potential users of your app to easily discover it and try out a single part of your app, where and when they need it most. In this post I will go into detail on the size limit for an App Clip.
An App Clip should be small, such that it can be downloaded quickly and shown to the user almost instantaneously. To facilitate this, Apple requires an App Clip to not exceed 10 MB, which is not much. At least, it seems so.
To get a better idea of how much this is, I performed a number of small experiments. As a starting point, I followed the Apple guide on creating an App Clip, and created a blank app with a single View Controller (Swift using Storyboards). In its view there was only a single UILabel. The App Clip target shared this View Controller, and based on “Active Compilation Conditions” the label text was set to either “App” or “App Clip”, so that we could determine that the same label yielded different results when shown in either the app or the App Clip.
The size of the App Clip can be determined through archiving the app and then exporting the App Clip, enabling “App Thinning” and “Rebuild from Bitcode”. The result of this almost blank App Clip was only 115 KB. This shows that of the 10 MB pretty much all of it is available for the developer to spend on code and assets.
So let’s pull in Firebase!
We have a number of mobile applications that are backed by this Cloud platform from Google. It provides solutions for authentication, (realtime) databases, storage, serverless functions, analytics, crashlytics and more. The most common and basic dependencies included in a project are Auth and Firestore (database). Without adding any code, I went ahead and archived the and, then exported the App Clip again. Unfortunately this resulted in a very nondescript error message which, despite following various possible solutions, kept popping up.
To avoid spending the entire Lab Day on identifying and properly addressing this issue, I disabled “Rebuild from Bitcode” and finally got the result: 5.2MB! More than half of the budget was spent, and I didn’t do anything yet.
Disabling “Rebuild from Bitcode” could have given an unfair picture of the size taken, so I threw out Firebase and went through the archive/export dance again, disabling “Rebuild from Bitcode”. The original App Clip was still 115 KB, so it might be safe to assume that the App Clip that included Firebase, when rebuilt from Bitcode would not yield a very different result from the 5.2MB.
The exercise of adding Firebase to the project was driven from a need to get some Elevate company data from the Firestore database. That can of course also be made accessible to the app by means of a Firebase Cloud Function called via a HTTP request.
Finally, adding a handful of images and embellishing the UI with some more labels and colors added just a few kilobytes, raising the total size of my first App Clip to a mere 152 KB. Ain’t it a beauty? (disclaimer: this is not the result of an entire day coding 😁)
We just got our feet wet with App Clips and now have some idea of what the 10 MB size limit means. It is very likely that creating an App Clip for one of our apps will not be as easy as Apple’s WWDC videos make it look (it never is) but at least 10 MB is not as limiting as it initially seemed. That is: for native apps. Touchwonders maintains several apps that are built using Flutter, Google’s cross-platform UI framework. As we’ve seen with including Firebase in an App Clip, Flutter too is a framework that claims a considerable amount of space before you’ve even written any code yourself. So much so that Flutter’s current statement is the following:
“This experimental preview currently exceeds the 10MB uncompressed IPA payload size limit and cannot be used in production.”
Let us hope that they find a solution, and one that still leaves some space for our own code.