# Every animation was one rename away from breaking a live show

DevFeed: [Every animation was one rename away from breaking a live show](<https://devfeed.tech/articles/every-animation-was-one-rename-away-from-breaking-a-live-show-23709.md>)

Original publisher: [Read original article](<https://medium.com/whatnot-engineering/every-animation-was-one-rename-away-from-breaking-a-live-show-a5139b9c6bad?source=rss----162aeca881b0---4>)

Author: Whatnot Engineering

Published: 2026-09-10T16:31:01Z

Content type: tutorial

Language: en

Sources: [Whatnot Engineering](<https://devfeed.tech/sources/whatnot-engineering.md>)

Topics: [iOS](<https://devfeed.tech/topics/ios.md>), [Swift](<https://devfeed.tech/topics/swift.md>), [Code](<https://devfeed.tech/topics/code.md>), [SwiftUI](<https://devfeed.tech/topics/swiftui.md>)

Tags: [animation](<https://devfeed.tech/tags/animation.md>), [code](<https://devfeed.tech/tags/code.md>), [ios-app-development](<https://devfeed.tech/tags/ios-app-development.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [swift](<https://devfeed.tech/tags/swift.md>), [swiftui](<https://devfeed.tech/tags/swiftui.md>)

## AI overview

This engineering post explains how a designer's property rename could silently break a production iOS animation because Swift code referenced asset properties through string literals. It describes replacing hand-written bindings with generated animation binding code from asset files so the compiler can enforce the contract and reduce reliance on tribal knowledge.

## Source excerpt

Seth Sandler There's a bug we never shipped, and it kept me up anyway. Here's how it goes: a designer renames a property from purchaseCount to purchase_count inside an animation file. Every place our Swift code references that property is a string literal. The build stays green. Code review passes; nothing in the diff even mentions animations. And the celebration animation at the heart of our live auctions silently stops firing, in production, in front of a live audience. Nothing stood between us and that outcome except everyone remembering to be careful. And the strings were only the most visible tripwire. Driving our animation runtime correctly also meant knowing things the compiler never checks: call order, load timing, which properties were designer-internal and untouchable, how not to leak memory. Every engineer touching an animation had to know all of it, and every new animation was another chance to get it wrong. If you've done animation work on iOS, some version of this unease is familiar. This post is the story of how we defused it: by generating the entire animation binding layer from the asset files themselves, so the compiler enforces the contract and the generated code encodes the nuance. The methodology isn't specific to our stack, our vendor, or our app. If your code talks to any designer-owned asset through string literals and tribal knowledge, you can build this too. Why hand-rolled animation code collapses Our first instinct, like every iOS team's, was to build the animations ourselves. SwiftUI has withAnimation. Core Animation has CAKeyframeAnimation. We'd shipped complex UI before. How hard could it be? The animation we were building wasn't a loop. It was state-driven: it needed a user's avatar, their name, a running count that ramps up the visuals, and different behavior depending on who's watching. Each input changes the intro, the escalation, the outro. In native Swift, that decomposed into: State explosion. A @State for the image, a @Binding