115 MB of Plugins
109 MB main app target binary
34 MB sqlite file 👀 (more on this later)
23 MB Dynamic Frameworks
The rest is assets, localizations, misc. Let's start with the Plugins 🔌
115 MB for two app extensions is a lot 🫨
We see two Plugins that look almost identical (58 MB vs. 57 MB) with many of the same modules in each.
They can likely use a Dynamic Framework to share code between these two app extensions to help reduce total Plugins size
In total, we see 25 MB of duplicate files, mainly coming from the SGPKitPackage_Mocks.bundle
Additionally, Trainline could cut 18 MB from removing binary symbol metadata and 11 MB from optimizing images
That's 54 MB of low-hanging fruit to reduce app size by 15.8% 😮💨
Back to that .sqlite file, this accounts for 10% of install size (34 MB)
Looking into it, this looks like data about all the cities and stations in the Trainline app— data like names, latitude, longitude, timezone, etc.
This probably lets people use Trainline features even in unreliable network conditions (like when you're traveling on a train through mountains), so that's pretty cool!
You know what else is cool? Making your app smaller & easy to download in poor network conditions 😏
And lastly, we found various images regarding Trainline + sustainability ♻️
It's great to see that a company like Trainline is putting sustainability front and center 👏
Friendly reminder that app size does have a tangible impact on CO2 emissions— there's a cost of every byte transferred 🌱
For an app the scale of Trainline, low-hanging size optimizations can actually make a big impact! We have a blog post about this too👇 emergetools.com/blog/posts/Cos…
It's always fun taking a deeper look into these apps— feel free to continue tagging @emergetools for any of your app size questions! 🫡
Let's take a look at why the @SantanderUK iOS app is at a whopping 613.3 MB and how 35% of it does nothing for the user 🧐
Right off the bat, it looks like most of the app (587.6 MB) is dynamic frameworks
Dylibs let you share code between targets, but are larger than static frameworks b/c static let's the compiler strip dead code. It's likely that Santander doesn't need ALL of those to be dynamically linked
Also, note the "String Tables" in the dynamic frameworks— these are unnecessary binary symbols that can be stripped out and save 215.5 MB (35% of install size) for Santander UK 🤓
Another day, another "How is this app so big tweet" 🤓
This time its the @DJIGlobal iOS app, which comes in at 1 GB
A lot of the comments speculated that the app was large due to assets & while there are 155 MB of .mp4 video files, the bulk of the size is coming from ML models
There's 264 MB of .mlmodelc files - these are compile Core ML Models which are designed to run on Apple devices. Some of the biggest models 👇
Here's a top level view of the latest version of LinkedIn
300 MB for just dynamically linked frameworks & Plugins is...a lot. In fact, just the Dylibs & Plugins today are bigger than the entire app was back in November 2022 🫠
And the Plugins and Frameworks seems to be where the greatest inefficiencies lie. Here is a more detailed look at the LinkedIn Plugins + the dynamically linked VoyagerLibs.framework
Finding accessibility issues in an app is an incredibly manual task that can take hours depending on the size. Which seems like a perfect place for ✨AI ✨
🧵Surfacing accessibility issues in the @Drizly app w/ AI 🧠
A quick background - our Snapshots product turns Previews into snapshots. A recent feature gives the ability to use AccessibilitySnapshot w/ one line
You don't need to write test code to get snapshot tests or to snapshot VoiceOver elements
We can take snapshots for any app leaking Previews into production, which @Drizly (and many other apps) are. We were able to generate 86 snapshots for Drizly
We then fed these images into an AI we're working on to detect accessibility errors. Here's what we found