Performance issues aren't fun, especially if they occur in a release you just did, and you won't notice until the release is live.
Every now and then, I like to share a story of my day to day job at WeTransfer. Many of you might be beginners and stories from "in the wild" will definitely help you grow your learnings.
Last week, we released 5.5.1: an update in which we moved to SPM and improved launch time performance. We did this by setting a batchSizeLimit to often performed fetch request in Core Data besides several other improvements. (read my
tips on launch performance).
The mistake I made was only to look at the numbers. Our DYLD statistics showed an improvement and (too quick) testing didn't bring any performance issues. Our QA team did find the scrolling hitches but reported it as a "Severity 3" which at this point doesn't have priority in our roadmap.
Soon after the release, we got reports from our Support team telling us several users had performance issues. Some couldn't even open the app anymore! At this point, we stop all regular work and we jump on the hotfix train. After finding out the cause, we did the minimum thing to fix the issue and submitted a hotfix. Our app got rejected (bad timing, haha!) but luckily enough, we could ask Apple to release this as a bugfix.
Long story short; be conscious when improving performance. Even though a fetch batch size is often described as performance increasing it might result in decreases for your app. Create a release with the minimum required changes to lower the risk of introducing new bugs with your hotfix. Once the hotfix is live, you can start working on a proper fix.
Hopefully, this story was inspiring and educational. Let me know if you like it and I'll think about sharing more stories in the future.
Enjoy this week's SwiftLee Weekly!
