From Lottie to Rive: Rebuilding Fetch’s Animation Platform

Company: Fetch

Role: Technology advocacy, systems design, documentation, cross-team leadership

The Challenge

Fetch is committed to bringing joy to people’s lives through rewards. It’s what helps the Fetch app stand out within the utilitarian world of fintech, loyalty programs, and rewards platforms. One of the ways we do that is through motion.

For a while, Lottie was a great and easy way to add motion to the app. As time went on and our product experience ambitions grew, we found that Lottie wouldn’t enable us to do everything we wanted with motion. It got to the point where our receipt scanning experience featured over 50 fully animated shorts, composed of frame-by-frame animated characters, music, sound effects, and haptics, all playing in sync using a complex, custom-built, and quickly aging system.

It was only a matter of time until our ambitions pushed Lottie to its limits. We needed more variety and customization: alternate endings, swapped characters, custom injected image data. These were ideas that were either unsustainable or technically impossible with our current tech stack.

The Approach

Prior to joining Fetch, I was already familiar with Rive, a design and animation tool that offers an alternative to Lottie. In my previous role as Lead UX Designer at Filament Games, I spent a lot of time working with state machines using tools and workflows very similar to working in the Rive Editor. I knew Duolingo was already using Rive extensively throughout their entire app at scale, and that it would enable us to do all the things we were already building custom solutions for, all within a single modern tool.

I set up an initial meeting between our product team and the team at Rive, and led the evaluation as our tech team began testing and integrating Rive into our stack. The first true test was an asset swap. We took our “like” button interaction (an on/off toggle with an animated transition) that was originally built in Lottie using After Effects timeline markers, and remade it in Rive using a simple state machine. Our engineering team stress-tested a scrolling list of 500 “like” button animations, replaying each one as it scrolled into view.

On iOS the difference was night and day: Lottie choked down to 11-19 FPS with heavy stuttering, while Rive held a smooth 45-55 FPS. On Android the story wasn’t as cut and dry. Rive rendered each frame faster but used noticeably more CPU and memory, with a suspected memory leak that our engineers flagged for follow-up. From there, engineering ran a deeper Instruments profiling pass on iOS that confirmed our earlier results, and tested a full-screen animation where the difference between Lottie and Rive was closer to even. It was enough to greenlight moving forward with Rive.

Once greenlit, I integrated Rive into the product design toolkit and began designing new features and experiences with our newfound capabilities in mind.

The Outcome

I authored the documentation and design standards for how we design and build Rive experiences at Fetch, including how we structure data and document asset handoffs between design and engineering. That documentation is what lets teams beyond my own build with Rive independently and correctly, and it’s why I’ve become the org’s reference point whenever a team is scoping a new Rive experience. Our animated assets are now much more flexible and respond to real user data controlled by the backend. Rive assets have taken a lot of the burden off our mobile and backend engineers, letting us ship richer, more interactive, and more personalized moments faster and without a mobile release for every change.

Rive adoption has since spread well beyond the original use case. Most product teams at Fetch now ship at least some Rive as part of their UX, whether that’s a single component on a screen or a fullscreen flow. I sit on the Growth team, where I’ve built increasingly complex, branching Rive experiences for our loyalty program (flows that change artwork, animation, and structure based on the data sent to them), but I also consult on Rive work for other teams, including post-purchase experiences.

Our tech team also built a performance discipline around Rive. Once Rive was live in production, the mobile team stood up observability (Embrace dashboards, later iOS instrumentation) and set a concrete quality bar of 350ms P95 time-to-load, aligned to the ~400ms Doherty Threshold for what feels instant. This lets us identify and fix the poorest-performing assets and set expectations for new ones.

We currently have about 12 active Rive assets live in the Fetch app, with more along the way at various stages of production. We found that directly converting our old Lottie animations resulted in large file sizes and poorly performing assets. So rather than remaking the 50+ animated shorts, we decided to sunset that specific experience in favor of designing rewards celebration more directly and purposefully into the UX, using the new capabilities Rive unlocked for us.

Rive didn’t just result in better-performing animated assets. It gave our team a far more capable and leverageable animation platform that unlocked better, more dynamic product experiences. It also raised the ceiling and the responsibility for performance, and while the gains are real, they depend on following our documentation and design standards to build well-optimized assets.