When Rappi started, App size wasn’t really a concern, but it became chaotic when the growth became exponential, and new features were added release after release. That’s when we faced the issue of almost hitting the app size limit.
Hitting the App size limit means that you can’t download the app using mobile data. Even though Apple removed the app size limit in iOS 13, the user receives an alert if the app is bigger than 200 MB.
We conducted a lot of research, and we concluded that we were losing a bunch of money for every MB the app gained because applications with smaller sizes have the biggest user retention rate.
First, we needed to stop the application size from growing in every release, so we added constraints to the development cycle. Some examples are:
- Big assets must be delivered through the server and must not be added to the project.
- The teams had to delete unused code and dependencies constantly.
Now that we prevented the app from growing, how do we get the app size down? First, we set a starting point: a Size Report that measures the app download and installation sizes.
As Apple tells us here, none of the binaries you create for debugging or uploading to the App Store from within Xcode are suitable for measuring our app size.
App Size Report
First, we measured the app size through App Store Connect in the App metadata section. This is the most reliable number because Apple performs additional processing on your App’s binaries, adding DRM to prevent App piracy and then recompresses the binaries, which affects the final size of the App.
This was very helpful at first, but it was far from being the optimal solution. We needed something that was automated and with very little to no time invested.
We came up with the idea of building an automated workflow that ran size reports on our biggest (iPhone 8+) and the lowest (iPhone 12) app size. Then the size reports were saved on a database and shared with the team responsible for the App Size through Slack daily. The Slack message also contains the size differences from the last report.
How did we do this? Well, in summary, we followed these steps:
1. Archive the App.
2. Export the archived App 2 times using an Ad-Hoc certificate, one for iPhone 8+ and one for iPhone 12.
3. With a swift executable, parse the reports, save them in our database.
4. Send the report results to Slack.
These reports can’t tell us the final size of the App because of the additional processing to the App’s binaries, but it’s the closest estimate that we can get.
This daily report has helped us prevent unwanted size changes, therefore keeping the App size stable.
Now how do we get the App Size down? What if something made the app size go up significantly? How do we know the cause? Well, with an app size analysis.
Size Analysis
To know why our App was so big, remove unnecessary files, and identify our largest dependencies, we needed an IPA file and performed an analysis following these steps:
1. Change the extension of the IPA file to ZIP.
2. Unzip the file to show the App’s bundle inside the Payloads directory. You can either open the ZIP file in Finder or run unzip -lv /path/to/your/app.zip in the command line.
3. Right-click the App’s bundle, and choose Show Package Contents.
4. Look throughout all the files and ensure that you are not adding unwanted files to your target, such as your App’s README.md file, and remove unused files like images or assets from the target/project.
NOTE: An IPA file is just a ZIP archive that has a particular structure when unzipped.
But with such a large codebase as Rappi’s, it’s close to impossible to review file by file and would take a lot of valuable time from our developers. So as with the size report, we needed to automate this process.
Instead of looking through the files, we obtained the verbose output of the unzip command and parsed it with a swift executable. And then analyzed these values to create the following info:
1. The number of files that were added, modified, or deleted.
2. How much size difference was between the versions of the files.
3. What were the files that added the most amount of KB.
4. The size and percentage that each of these categories meant to the total App size.
- Code
- Resources
- UI
- Others
- Dynamic library
- Localization
- Code signing
5. The size of every internal and external dependency.
Then we saved this info in our DB and used it to compare it with the subsequent analysis. We also created some charts to be more readable by any person.
Conclusion
The size report and size analysis are very helpful tools, but with such a large codebase and the number of features our app has, there’s so much that we can do to get the app size down code-wise. This is just part of the great effort we are putting in getting the App size down. We are also working on other things, such as implementing the Uber compilation pipeline.
