iOS @ Over: 3 months into the iOS Platform Team
A while ago we wrote about starting an iOS platform team at Over (read it here). From the start, we decided to tackle various tasks that the iOS team doesn’t always have time to look at. We thought, now would be a perfect time to look back on the success of the platform team and what we have managed to achieve thus far.
The Platform team’s primary purpose is to facilitate the success of the entire iOS team at Over. This ranges from tasks like handling urgent bugs, assisting other squads with platform changes needed, and cleaning up technical debt. Another responsibility we take on is to ensure that non-critical company requests from outside of engineering also get attention.
These are some of the bigger tasks we completed.
🧹 Code Cleanup
During the initial planning for the Platform Team, we identified code cleanup as the biggest need in the iOS Team. 2018 was a busy year for us. It was also marked by a period of growth hacking where we shipped a lot of experimental features. We also had to sunset our Circles tab which, code-wise, was a major feature.
We started off by removing the Circles feature. The majority of the classes were now unused and simply had to be deleted. The end result was about 10 016 lines of code being removed across 80+ files 🤯.
Next up were the experimental features. We shipped around 17 of these in 2018. They where all part of our internal ABTesting service and most of them were built over several one week sprints. Many of these features were discontinued by turning off the feature flags but the code still existed in our codebase. They all varied from a few lines to several thousand lines of code. We did our best to abstract these as much as possible, but some still found their way into parts of our codebase we weren’t comfortable with them being in.
Our biggest concern with these features is that no single person in the team had the full context over all of them. Things started to go wrong when our users began reporting bugs in production on features that were part of these ABTests, but, should have been, essentially “turned off”. 🙈
The first step was identifying each experimental feature and then followed by documenting the context of its impact on the codebase. Once that was done, we started tackling them one at a time to ensure our Pull Request’s (PR’s) were manageable for the rest of the team to review. The end result was 15 PR’s removing a total of 7,474 lines code.
All in all, we removed around 17,500 lines of unused code 🎉
🚑 Continuous Integration Backup Plan
We use Buddybuild for continuous integration as well as automating our App Store submissions. This ensures everyone in the company has access to the very latest snapshot of our codebase in an Adhoc & TestFlight build.
To simplify our environment, our team members Mac’s aren’t configured to build & sign for the App Store. This becomes a problem when the CI server goes down. While this almost never happens, it has before, and on an important release day 😒.
What we wanted was something that was quick & easy to set up, with clear documentation of how to use it.
We had 2 conditions we wanted to achieve.
- It must be quick to set up on any existing dev machine. (ie. no 3rd Party software to install)
- It shouldn’t require any changes to the Xcode project.
What we ended up with was a build script able to build the Production and Beta IPA, our private key stored in an accessible but secure location and a wiki article explaining how to configure and run it. All in all, it probably takes about 10 minutes to set up.
The build script makes use of the exportOptionsPlist option introduced in Xcode 9. This lets us manually configure the build independently from what is configured in Xcode. Since we also have multiple Notification extensions, it also lets us define different Provisioning Profiles per bundle identifier.
🐛 Bug & Crash Reporting
For years the suite of services provided by Fabric have been our crash and bug reporting tools of choice. However, Fabric is being shut down very soon. This created an opportunity for us to evaluate other solutions out there for our bug and crash reporting. Our team isn’t sold on the idea of moving to Firebase. A big reason being that Crashlytics will require an extra 8 Google/Firebase libraries to be installed with it. That’s a lot.
After evaluating a few different options, we have now moved to Instabug. It’s still early days, and while it doesn’t give us as good of an overall state of the app that Crashlytics did, it’s going well. We are now also using Instabug for bug reporting and feedback on our internal builds, replacing Buddybuilds feedback feature.
💾 Removing Realm
A few years ago Realm was implemented in Over with different requirements in mind. Those requirements changed and we where left having to support a 3rd Party framework that we don’t need anymore. 3rd Party Frameworks can become a problem around the time of having to upgrade Xcode and Swift. When Xcode 10.2 and Swift 5 came out, we found ourselves in a bit of a pickle. We couldn't immediately upgrade because of an issue with Realm and we had to wait for them to resolve it. This pushed us to reevaluate the urgency of removing Realm from our codebase.
We had 2 features in Over backed by Realm. Neither of them required any complex querying but did make use of Realms object notifications. Since we don’t deal with 1000’s of database entries, it was clear we could replace Realm with a simple caching mechanism.
This meant updating all our older models to conform to Codable. We effectively replaced thousands of lines of code in Realm with a very simple caching class that is able to insert, update, delete and retrieve the objects. This new class is backed by PINCache. As of today, we no longer have Realm as a dependency. This also had a nice side effect of reducing our build times 😃.
🔨 What Else?
Besides these bigger planned tasks, we did manage to help out other departments with various requests and fix some nasty bugs like our Google users getting logged out on every app launch.
🚀 What’s Next?
There will always be more code-cleanup to do, but as we move forward this will have a lower priority now that the biggest culprits are gone. We are now focusing on improving key areas of our codebase to better help the rest of the iOS team.
We’re also looking into where the Platform team can help in Customer Success to ensure issues reported by our users go through the correct flow of being assigned & actioned by Engineering.
As the responsibilities of the Platform team grows, we may also look at expanding the team later this year.
Thanks for reading and we hope you enjoyed this article 🤓. We would love to hear your thoughts so leave some feedback down below and be sure to stay up to date by following us on Medium and Twitter @EngineeringOver
