update from @MCrichton-WMF: https://wikimedia.slack.com/archives/C0BEMH28M60/p1785943174159439?thread_ts=1785166903.555319&cid=C0BEMH28M60

What engineering approach is needed to support Rive in the 2026 Year in Review?
We would need to add the Rive runtime and create a small platform-specific wrapper for loading files, controlling playback, handling lifecycle changes, and reporting loading errors.
For interactive or personalized animations, Design should provide us with a Rive data-binding model. Engineers would then connect application data to those properties. Business logic should remain in the app and Rive should only control how that state is presented.
We would also need to handle reduced motion, accessibility, localization, different screen sizes, and Year in Review share images. Critical text and controls should remain native rather than being embedded only inside Rive.

What is the impact on app size and performance?
On Android:
AAB (bundled package) increase: approximately 14.8 MB
Native Rive libraries: approximately 12.3 MB across four CPU architectures
Rive assets: approximately 2.7 MB (prototype only has 5 assets) year in review could have more complex assets
DEX code: approximately 350 KB
Google Play delivers only the native library matching the user’s device. Based on the measurements, the expected Play download increase for a typical ARM64 device is approximately 5–6 MB, including the current assets. Installed size would likely increase by approximately 11–12 MB.
This size will remain in the application throughout the year, even when Year in Review is unavailable. Lottie is already there in the Android app, so using Lottie would only add the new animation assets.
We cannot make a general performance claim from the prototype. Both Rive and Lottie render at runtime, and performance depends heavily on the animation. We would need to analyze this on final assets on low and mid-range devices.

What is the expected engineering effort to integrate Rive?

1. Wiring up the code (adding dependency + architecture): Medium
2. Basic static animation: Small
3. One interactive, data-bound animation: Medium
4. Multiple interactive Year in Review slides: Large
5. Accessibility, reduced motion, screenshot sharing, and performance validation: Large

The estimate also depends on Design finalizing the Rive file and data-binding contract. Changes to property names, types, state machines, or transitions may require implementation changes.

What is the effort to migrate existing Lottie experiences or support both libraries?
We currently have only one Lottie animation on Android, so migrating it should be manageable. However, it would not be an automatic conversion. Design would need to recreate the animation in Rive, and we would need to replace the current implementation and test that it still looks and behaves as expected. This would be Medium effort overall.
We could also keep both libraries, and the initial engineering work would be small. However, this would mean maintaining two animation dependencies and workflows. Since Lottie is already used in the app, choosing Rive for Year in Review means supporting both unless we recreate the existing Lottie animation in Rive and remove the Lottie dependency.

Rive is a new workflow for both Design and Engineering, so using it for one seasonal feature would mean learning and maintaining it on both platforms. Adding different libraries for individual features could also increase app size and maintenance over time. I think we should adopt Rive only if we expect to use it more broadly, rather than for one experience.

What does Engineering need from Design?
Since Rive is a new workflow for us, Design and Engineering would need to agree on the handoff requirements before implementation, because changes to the data-binding contract may also require changes in the app. At minimum, we would need the final Rive file, the expected animation behavior, and information about any values or interactions controlled by the app.

If the animation is interactive, we would also need to understand its different states and what causes it to move between them. We should agree on how it behaves across screen sizes because the animation may otherwise stretch, crop, or leave empty space.

Important text and controls should remain native for accessibility. We need to decide on whether non-critical or decorative text can remain inside Rive.

Any text inside Rive would still need to be tested for font sizes, long translations, RTL languages, and themes. My preference would be to use Rive mainly for the visual animation.

Prototype findings
For the Android prototype, I was able to load local Rive files, run interactive state machines, update strings and numbers through data binding, switch between multiple assets, and inspect the data-binding properties available in each file.
I also found that the implementation depends heavily on how the Rive file is created. Fixed-size artboards can stretch, crop, or leave empty space on different screen sizes. Some behavior, such as transition speed, is defined inside the Rive file and cannot always be changed easily from the app.
The marketplace files were also inconsistent. Some had useful data-binding properties, while others were mainly visual assets without a clear way to update their content, which highlights the need for more properly structured and functional design files.

Accessibility, reduced motion, and Year in Review screenshot sharing would need additional platform work. The prototype was only completed on Android, so the iOS integration would still need to be tested if we decide to use Rive.

To run Rive in the prototype

1. Download Apk
2. Go to developer settings and search Rive, tap on it
3. In Rive screen, tap the 3 dot menu at the top right and chose one of them to interact with the Rive designs (The rive animations are from Rive marketplace)

Demo: https://drive.google.com/file/d/1NIsQaOwym4LEbIQxDhM7-P1ZuGGJRzsK/view?usp=sharing

Recommendation
I would recommend continuing with Lottie for the 2026 Year in Review if the experience is mostly timeline-based animation with personalized text and limited interaction. Lottie is already integrated and should be simpler to implement and maintain. Since important text and controls would need to remain native for accessibility, I think we would get less benefit from Rive’s data binding while still adding significant app size.

I would reconsider this if the final design requires more interactive, state-driven animation, where Rive would provide a meaningful advantage. Rive could also make more sense if it is used by other feature such as Wikipedia Games, instead of adding the runtime only for a seasonal experience.

Update on Rive Responsive Layout
Findings

1. Rive supports responsive layouts, but rive file needs to be designed using Rive’s responsive layout system for that behavior to work. Engineers can enable this using the Fit.Layout, fit mode which resizes the artboard to match its container and applies the layout rules created by the designer. There is also an optional scale factor for fine tuning the overall size of the content. This can help prevent elements from going out of alignment when the user changes their device Display size or when the available screen space changes.

2. Rive does not automatically respond to the user’s Android system Font size. One possibility is for designers to expose the font size through Data Binding, allowing engineers to update it based on the user’s Font size setting. The Rive layout would also need to be designed so that larger text can fit, wrap or reposition correctly.

3. I also found this tutorial on Responsive Text in Rive: Scale Font Size with Range Map. It changes the font size based on the width of the Rive artboard, so it helps with different screen and container sizes but does not respond to the user’s system Font size. We could potentially use both approaches together: the Range Map for responsive screen sizing and Data Binding for the user’s accessibility Font size.

I think Rive provides the tools needed to achieve responsive layouts across different screen and Display sizes using Fit.Layout, as long as the designer builds the Rive file adaptively. Supporting the user’s system Font size also appears possible through Data Binding.

Demo

1. Increasing Display and font size on medium size phone
2. Increasing Display and font size on small size phone

Note: Changing the font size in both demos does not affect the Rive Text, while it does update the native text below.

We still need to test this properly before we can confirm these findings. It would be helpful if engineers could get a Rive file that uses responsive layouts and exposes both text and font size through Data Binding. We can then test it with different screen, Display and Font sizes, as well as longer or localized text, to see how well the layout adapts.

Perfect thank you for checking this William. We are currently awaiting approval to use Rive at a paid capacity in order to export files for testing.