Spireworks is a connected app that lets anyone control the lights of iconic New York skyscrapers in real time. Tap a color on your phone, and the LED lighting on a participating tower changes to match, instantly. It's a partnership between Spireworks and building owners, with revenue tied to charitable giving through the Change platform. Users pick a building, pick a color, and the skyline responds.
Situation
L+R had been Spireworks' long-term partner across digital strategy, UX, brand, and engineering. The product is unusual. An app that lets anyone change the color of real LED lighting on iconic New York skyscrapers in real time, with revenue tied to charitable giving. The original app was native iOS, built on top of an earlier web application. That choice was deliberate. The product had two non-negotiable technical demands: tight, low-latency control of a physical lighting system, and a level of visual polish that matched the spectacle of the skyline itself. Analytics also showed the existing user base was overwhelmingly on iPhone, so a single-platform launch was defensible. As the product matured, the roadmap expanded. More participating buildings across the NYC skyline, richer per-building visuals, deeper philanthropic integrations via the Change platform, and eventually Android.
Task
The brief on paper was straightforward: ship Android. The harder question underneath it was architectural. Maintaining two native codebases (Swift on iOS, Kotlin on Android) for a product whose differentiator is real-time visual fidelity meant every new building, every interaction tweak, every lighting protocol change would need to be implemented and QA'd twice. With a lean team shipping frequently, that's where parity bugs and feature drift live. We proposed Flutter. The client was hesitant, reasonably so. Spireworks had a working, well-loved iOS app, and rewriting it on a framework the team hadn't shipped before is a real risk. The agreed path forward was a structured pilot. Build the Android app on Flutter first, put it through user testing and stress testing against the same scenarios the iOS app handled, and let the results decide whether iOS would follow.
Action
Spireworks needed animated lighting states, smooth color transitions, and a UI that felt as polished as the skyline it controls. Flutter renders through its own rendering engine, Impeller, rather than mapping to platform widgets, which meant gradients, motion, and typography looked pixel-identical across devices. For a brand where the visual is the product, this removed an entire class of "it looks different on Android" bugs that cross-platform teams usually spend cycles on. Video content for participating buildings was handled through the native video pipeline behind a Flutter interface, so playback stayed smooth without us reinventing it.
Flutter is not a religion. Push notifications, deep links into specific buildings, share sheets, and the Change platform integration for donations all run through platform channels and well-maintained plugins. The donation flow is wrapped behind a single Dart interface so the rest of the app doesn't care which platform it's running on.
The latency requirement, tap a color and see it on a 50-story building, is the part that makes or breaks the experience. We built the control layer in Dart over a WebSocket connection to the lighting backend, with isolates handling message serialization off the UI thread so the interface never stuttered during rapid color changes. Stress testing simulated concurrent users hammering the same building, and the Flutter client held frame rate and message throughput at parity with the native iOS implementation.
Widget tests covered the UI layer, integration tests covered the WebSocket and donation flows end-to-end, and we ran the same test suite against both platforms. One test pass, two platforms green. Once the Android build passed user testing and stress testing, the case for moving iOS onto the same Flutter codebase made itself. We brought iOS onto Flutter and shipped both platforms from a single repo.
Spireworks uses GPS to surface which buildings a user is near, prioritize them in the interface, and unlock proximity-based interactions. We wrapped the platform location APIs behind a single Dart service so the rest of the app didn't care whether it was reading from Core Location or Android's Fused Location Provider. Same pattern for sensor data and other platform-specific signals. One interface, two implementations underneath.
Hot reload genuinely changed how we iterated on the color picker, transition curves, and haptic feedback on color commits. Designers sat with engineers and tuned details in minutes rather than build cycles. This is the unglamorous Flutter benefit that compounds across a project.
Result
Spireworks launched on iOS and Android from a unified Flutter codebase. To date, the platform has powered over 33 million lighting interactions and 16 million instantaneous color changes on real buildings. Multiple TikToks with millions of views each drove a wave of new users, and the app led to collaborations with MrBeast, Amazon Prime, and The New School. It won a Red Dot Award and was named a Webby Honoree.
The codebase outcomes are the part most relevant to other Flutter teams. One team now ships to two platforms, with feature parity by default rather than by effort. New buildings onboard once. The asset pipeline, color command schema, location logic, and donation flow are written in one place. iOS users got an upgrade, not a downgrade. The transition off native Swift did not cost performance or polish, and that was independently verified by user testing before the iOS move was even approved. The client's initial hesitation turned into a roadmap unlock, with Spireworks now able to expand across the NYC skyline without doubling engineering cost per platform.
From The Client
Flutter was a strategic choice, not just a technical one. With L+R, we built one app that runs beautifully everywhere, opening doors to more people, more buildings, and more impact.”
Mark Domino
CEO, Spireworks • Spireworks
Mark Domino
CEO, Spireworks • Spireworks
The strongest argument for Flutter isn't "write once, run anywhere." That's the marketing line. The stronger argument is visual consistency on products where the visual is the brand, paired with a single source of truth for product logic when you're shipping frequently. Spireworks is both. If a client is hesitant, propose what we did. Build the second platform on Flutter first as a parallel evaluation, with explicit pass criteria around performance, fidelity, and user reception. It de-risks the decision and gives you real data instead of a slide deck. Don't avoid native integrations, embrace platform channels. Flutter handles the 90% that should look and behave identically. The platform handles the 10% that genuinely should differ. And measure the things skeptics will ask about: frame times under load, cold start, memory, battery during sustained sessions. Have those numbers ready before the conversation about moving the other platform even starts.
