Clutch Developer
NL
Book a call

Spireworks: a phone that changes the New York skyline

Client work with L+R. An app where the output device is a skyscraper — which makes latency, turn-taking and scheduling the entire product.

Spireworks lets you pick a colour and an effect, and the crown of a Manhattan skyscraper does it. Not a simulation — the actual spire lighting on One Bryant Park and One Five One. There is a calendar of skyline moments, members get control windows, and special sessions are tied to causes and fundraising.

Client work. Clutch Developer does mobile engineering on this app as part of the team at L+R in New York. The app belongs to Spireworks LLC.

App Store

What the app does

  • Live control — choose colours and effects and see them on the building, in real time.
  • A calendar of upcoming skyline events, so people know when control opens.
  • Sessions where members and guests shape the lights together during a window.
  • Cause moments — special displays tied to fundraising and awareness dates.
  • "Control the NYC Skyline" — the effect grid over the Manhattan skyline at night
  • "Real-Time Effects" — the lit spire behind the app's controls
  • "Discover all our Installations" — the effect picker held in one hand
  • "Spread the love" — a scheduled charity lighting moment with a countdown
Schermafbeeldingen uit de App Store-vermelding.

The hard part

Almost every app you build has a private output device. This one has a shared, physical, extremely visible output device, and that inverts a lot of ordinary assumptions.

Latency stops being a performance metric and becomes the product. If the building responds a second and a half after the tap, the illusion of control is gone and the app is just a remote that does not work. There is no optimistic UI trick that fixes it, because the user is looking out of a window at the ground truth, not at your screen.

Then there is turn-taking. Many people want to drive one object at once. Somebody has to decide who has control, for how long, what happens at the handover, and what the other people see while they wait — and all of that has to feel fair rather than random. Add scheduling on top: control windows open and close against a real calendar, in a real timezone, with events that were booked weeks earlier and must fire on the minute.

The failure mode is also unusual. If a normal app breaks, one user is annoyed. If this one breaks during a scheduled charity moment, it breaks in front of a city.

What that demands

  • A persistent connection, not request/response — the app needs push from the installation, not polling.
  • Clear connection state in the UI. "Am I actually in control right now?" must never be ambiguous.
  • Scheduling that respects a real calendar and timezone, for events booked far in advance.
  • Careful concurrency around a single shared object, with a visible, fair handover.
  • A degraded mode that is honest — showing that the installation is unavailable beats pretending.

Any app that drives hardware — a light, a lock, a vehicle, a medical device — inherits this shape. The screen is not the product. The thing on the other end is, and everything you do on the client is in service of the gap between the tap and the world changing.