Funimation’s Product and Engineering Team rebuilt our app. It was much-needed. It took awhile. But it was all in service to our anime community around the world for a better fan experience!
During the height of the pandemic, Funimation committed to rebuilding the iOS app. It was even more critical that we take on this project because our millions of fans worldwide, then more than ever, relied on Funimation to connect them to the best in anime from Japan. So, we decided to take on this massive rewrite to completely redesign the app and it was clear why it was needed.
RELATED: All-New, Updated Funimation App Begins Rolling Out on iOS
The legacy codebase had seen better days. It was written by a third party many years ago using Objective-C/C++, and we could hear the far distant cries of desperation—pleading—for design patterns and architectural planning.
It’s not easy to maintain a codebase that starts compositing an API request right in the user’s tap event. When there isn’t much thought to architecture, the code becomes difficult to build upon and adding features becomes downright impossible without introducing critical bugs.
The design team meticulously crafted a mockup that was fluid, sleek and just pure eye candy. This new and beautiful vision of the re-imagined app really catered to anime fans. It was so different from what the app was before, which only justified our reasons to start anew.
So, how far down did this redesign go? From what we soon realized, it didn’t stop here. This redesign was reaching deep down into the core of our systems, from new microservices and hitting the raw bones of the company: our content pipeline. We were essentially updating this monolithic infrastructure all together and all at the same time.
We had some challenges and made some mistakes along the way, but in the end we created something we’re really proud of.
What went well
It’s so easy to become disconnected from all of the new series and great anime when we’re heads down on feature implementation. We regularly scheduled knowledge sessions with our audiences to start introducing what our fans want in an anime app and also what they want from us. We had detailed acceptance criteria (AC) without understanding where they came from until we started asking questions.
It’s not just the product manager’s responsibility to know what our fans need. We all need to understand them because tech knows the nitty gritty of the platform we’re working on. And we don’t always need an AC to implement a feature the way our fans want it.
In addition, there were three pillars that went well in the rebuild.
Documenting architectural decisions
The first set of documentation I was presented with were architectural decision records (ADR). They came in handy to understand why these decisions were made, especially with the large shift in developers.
They clearly stated the decisions that were made to the project that brought structure, organization and scalability to sustain a large scale application that we needed this to be.
Triple threat: SwiftUI, Combine and MVVM
There were a couple of ADRs to move away from UIKit and use SwiftUI with Combine and MVVM. This is a pretty big mental shift for developers, especially me. I’ve grown accustomed to storyboards and passing completion handlers everywhere.
I mean, there are rules we set within the team for updating the storyboards like breaking up the storyboard into small flows and only one dev updates it at a time. Well, there’s no more of that. These three architecture decisions made our screens responsive, reactive and a quicker turnaround from the traditional. Not to mention it made unit testing much easier.
Domain models
Late in development, our senior engineer realized we needed to incorporate domain models. Our view models were interacting with data coming from multiple API calls and caches so they were doing too much to wrangle them together.
With this design pattern and aggregating our API calls into a separate provider, we were able to reduce the amount of logic, making them easier to read and allowing the view models to focus on their primary job: binding to properties and holding state.
Where we had to improve
Technical requirements
Late in the rewrite, there were some concerns about how much work was left. Backlog grooming was filled with uncertainty. We spent most of the time talking about how we were going to implement some particular feature and what blockers we would need resolved, which isn’t the purpose of a grooming session.
We spent too long trying to understand how to achieve our acceptance criteria, which made sense because most of us were new to the team.
So, that’s when we decided to pause and start a multi-day audit. We went through three grueling days of looking through each ticket trying to connect all the dots and find the missing pieces. At the end of it, we had some sorely needed technical requirements that we didn’t have before.
From there, it was easy to get our work-in-progress in check, and finally readjust priorities by feature to get this rewrite quickly out the door. My biggest regret is that we should have done this sooner.
Organically growing architecture
We tackled our features one at a time for a couple places in the app without thinking much of it. And when we started building on top of them, we soon realized we needed a stronger architecture than just a model view.
We didn’t look at all of them holistically enough, so we started seeing spaghetti code again.
This is when we started incorporating feature leads into the team. Our biggest feature, the video player, is the crown jewel of the app and it wasn’t as responsive as it needed to be. We had to take a step back and focus on these features to plan out maintainable and scalable architecture.
Our learnings
Wrap up the feature
The accumulation of tech debt can become such a burden. It’s important to draw that architectural diagram. Wrap up the feature. Write that documentation. Write those function markdowns to not be tied to this feature for the rest of your career.
Write code in such a way that anyone can update that piece of code. Don’t be stuck on a feature because no one else understands it.
Asking ourselves why things are the way they are
When updating a feature, it’s important to know about the historical context. Knowing the answers to questions like: Are the user stories and acceptance criteria up to date? Do they work with the platform now? Were they designed with limitations that no longer exist?
We’re the ones who know the platform the best. It’s the whole team’s responsibility to speak up, not just the product manager’s. The whole team needs to work together on this.
Internal and external feedback
In agile development, it’s easy to forget about that final process. Having a short feedback loop is a critical part of the agile process, but how does that work when in the middle of a long rewrite? We had an internal beta release and had continual daily builds available, but the feedback loop coming from within the team was the most important.
Putting the app in front of our designers and product manager needed to be a part of our workflow. Tickets and mockups may not provide the full picture, so integrating everyone into the workstream becomes more important than ever.
The same went for providing feedback to the new APIs. We had these new endpoints but we had some concerns.
We found it critical to voice our concerns quickly when we found them, and then again after we had documented the individual cases to look at them from a step back. It was clear to us that we needed to revisit some problem areas and would need to spend some extra time to fine-tune requirements and dependencies.
The current state
After completing hundreds of ACs and 20+ features, we’re finally releasing the app.
It’s not bug-free and everything we wanted—it’s just the beginning. We have so much we want to make; this rewrite will allow us to get more features out quicker than ever.
I’m so proud of the team for this long journey in undertaking this massive overhaul and we can’t wait to see where we stand in the months to come among our fan base. The entire team has a tremendous commitment and dedication to ensuring a fantastic user experience.
That’s what attracted me to Funimation, and my new colleagues echo the sentiment. Now I can finally enjoy a little Fruits Basket and One Piece and connect with our fellow fans.
