Proprietary vs Open Animation Formats: What Lock-In Actually Costs
Compare open and proprietary animation formats by spec access, runtime support, editability and long-term risk, with Lottie, Rive and ExodeUI examples.
Core Takeaway
An open animation format publishes a specification anyone can implement, which lowers the risk that one vendor controls your production files. A proprietary format can still be a good choice if its editor and runtimes are the best fit. The practical test is not the label: it is whether you can export, inspect, run and maintain the file without the original tool.
What open and proprietary mean
Open does not mean free, and proprietary does not mean closed off. Lottie JSON is an open format with a published schema, and the dotLottie package format has its own specification. Rive's .riv format is controlled by Rive, while its runtimes are open source. ExodeUI uses an open .exode JSON file. Each combination gives you a different level of access to the file, the player and the editor.
The four questions that matter
Evaluate a format by what happens after the first export.
- Can you inspect the file without the original editor?
- Can more than one runtime play it on your target platforms?
- Can you edit it without the vendor's cloud service?
- What happens to the file if the vendor changes direction or pricing?
Where Lottie and dotLottie stand
Lottie JSON is widely supported and easy to inspect. dotLottie adds a package for assets, themes and state machines, with a published specification. The catch is player support: a dotLottie state machine only runs in a dotLottie player. Openness at the file level does not guarantee that every runtime implements every feature.
Where Rive stands
Rive's editor and .riv runtime model are strong for interactive characters and complex state machines. The file format is proprietary, while the runtimes are open source. That means you can inspect and integrate the player, but the authoring format is still tied to Rive's tool. For many teams that trade-off is worth it because the authoring experience is the reason they chose Rive.
Where ExodeUI stands
ExodeUI stores layout, states, springs and logic in an open .exode JSON file, with runtime packages for several web frameworks plus React Native, SwiftUI and Flutter. That makes the production file inspectable and portable across runtimes. We make ExodeUI, so test the specific runtimes and features you need rather than taking the openness claim on its own.
A practical exit test
Before committing, export a representative file, open it in a second tool if possible, play it in the runtimes you ship and try to make a small edit without the original editor. If any step depends on one vendor's cloud or one proprietary player, write that down. The goal is not ideological purity. It is knowing where the lock-in is and whether you can live with it.
Key Principles to Remember
- Open means a published specification, not necessarily free or fully supported everywhere
- Check file inspection, runtime support, offline editing and vendor risk
- Lottie JSON is open; dotLottie adds a package spec and state machines with player constraints
- Rive's format is proprietary, while its runtimes are open source
- ExodeUI uses an open .exode JSON file with runtimes across frameworks and mobile
- Run an exit test before committing a production pipeline
Frequently Asked Questions
Sources
- dotLottie specification — dotLottie
- Lottie documentation — LottieFiles
- Rive runtimes — Rive
- ExodeUI documentation — ExodeUI