Backend-Driven UI Architecture for Native iOS Apps
Article Summary
Andrea Scuderi from Just Eat reveals why backend-driven UI can be a double-edged sword. His team ships UI changes without app releases, but the testing complexity nearly broke their workflow.
Just Eat's iOS team adopted a hybrid backend-driven UI approach for their Help module, allowing them to update content and navigation without waiting for App Store approval. This deep dive covers four UI binding patterns (from simple value binding to full code binding) and explains why they chose component binding over alternatives like React Native.
Key Takeaways
- Four patterns explored: value, content, component, and code binding architectures
- Built custom Shock tool to auto-sync production API responses with UI test mocks
- Testing requires coordination across QA, frontend, backend, and design teams
- Component binding enables A/B testing while maintaining native iOS performance
- Backend changes risk breaking production without robust test coverage
Backend-driven UI cuts time-to-market dramatically but demands significant testing infrastructure and cross-team coordination to avoid production surprises.
About This Article
Andrea Scuderi's team had to manually copy JSON from production API responses to keep their UI test mocks up to date. Every time the backend changed, they'd have to do this work again, which was tedious and easy to mess up.
Just Eat built an automated recording tool into their open-source Shock framework. It captures real backend responses and updates the mocked responses during UI tests without anyone having to do it by hand.
The team no longer had to spend time syncing things manually. Their tests stayed accurate compared to what production actually does, and they didn't have to worry as much about UI tests getting out of sync with the real backend.