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
Notice anything fishy?
First off, the 2 plugins + VoyagerLibs are all shipping ArtDecoIconsResources.bundle (~8 MB). This bundle is already in the Voyager Framework, so it should be possible to share with the Plugins...but LinkedIn is still duplicating it
If you look into TodayExtension, NotificationExtension, & VoyagerLibs, they share many class names (one example in screenshot)
While we don't know for sure if they are duplicates from public build analysis, it appears like the extensions are a subset of the VoyagerLibs library
Here's something else that jumps out - in March 2023, the TodayExtension was < 400 KB. Today its ~60 MB...
Seeing as Today Extensions have been deprecated, its doubtful that they added THAT much functionality to them
It seems there's a chance that LinkedIn is statically statically linking dependencies in their Plugins rather than using the resources from VoyagerLibs
If that's the case, then the Plugins (109 MB total) have a significant amount of unnecessary size bloat
Separately, here's ~75 MB of insights that we're picking up
If you want to explore our analysis on the latest version of LinkedIn, you can check out this page emergetools.com/app/example/io…
And coincidentally, @jacobs_handle wrote a blog post for us just last week about how to avoid duplication in Plugins
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
How did the @Twitter iOS app change over the last 6 months? Why did the latest release of Google Translate Android reduce app size by 1/3rd?
We try to make these questions easier to answer, which is why we're very excited about our newest feature, AI summaries of build diffs
Jumping right in - Twitter v9.59.1 vs. v9.34.6 (iOS)
Overall size decreased by 34 MB, but how quickly can we identify what changed?
The summary is pointing to removals of plugins and bundles, which is easy to see in the X-Ray diff
T1Twitter.framework is also highlighted in the summary. Searching through the diff, we can see that many assets were modified or removed to reduce its size
What happens to an app's performance when it goes from react native -> native?
The @peacock app just made the switch on iOS & Android and had a significant change in size and startup time
🧵 Performance impact of switching to native
A quick primer
RN let's you create mobile apps for Android and iOS using js & react. 1 codebase, 2 apps. It has an active community & there are certainly reasons you'd want to use RN
That said, if performance is important, native is going to be better
A few reasons
- JS is an interpreted language vs. native (Swift & Kotlin) is compiled
- RN is *mostly* singled threaded. Concurrency is complex and not as performant
- Native has easier access to device & OS features. RN requires more libraries to achieve functionality