Backend for Frontend for multi-platform apps with dynamic UI

When a client supports iOS, Android, and web at the same time, the same problems show up quickly: duplicated logic across form factors, inconsistent caching, too many service calls, and growing complexity in response handling.

In many of these situations, the frontend applications should not carry most of the orchestration burden. Their primary job should be to render the user experience well for the platform they serve.

The core problem

A multi-platform product often depends on several backend services. Each form factor starts calling those services in slightly different ways, and over time the same business logic gets repeated across mobile and web teams.

This creates a few predictable issues:

• Duplicate code across iOS, Android, and web
• Inconsistent caching behavior
• Too much client-side aggregation logic
• Harder testing and debugging across platforms
• Slower delivery because every form factor solves the same problem again

A better pattern: Backend for Frontend

One strong approach is to introduce a Backend for Frontend layer between the form factors and the backend services.

With this model, the clients become thinner and more focused. Their main responsibility is rendering UI and handling platform-specific interaction. The middleware handles the heavier application concerns.

That middleware can take responsibility for:

• Aggregating data from multiple services
• Hiding backend complexity from the clients
• Providing a single contract for all form factors
• Applying consistent caching rules
• Shaping responses specifically for UI needs
• Reducing the amount of repeated business logic across clients

Instead of every application figuring out how to combine five services, the middleware does it once and serves all channels in a cleaner way.

GraphQL can be one good implementation option for this layer, especially when response shaping and aggregation are important. But the broader recommendation is the Backend for Frontend pattern itself, not one specific technology choice.

Why this works well

This pattern is especially useful when the client is concerned about code duplication, caching, and service aggregation.

Backend for Frontend creates a clear separation:

• Frontends focus on rendering and interaction
• Middleware focuses on orchestration and response shaping
• Backend services continue to own domain logic and data

This usually improves maintainability, reduces duplicated effort, and gives product teams a more stable way to evolve features across platforms.

Dynamic UI for JSON-driven use cases

Some use cases need more than a fixed frontend. In these cases, the client may need to render UI based on a JSON response coming from the middleware or a configuration service.

That is where dynamic UI becomes useful.

The idea is simple:

• The backend or middleware returns structured JSON
• The web application parses that JSON
• React renders UI components based on the configuration

This is a good fit when teams want:

• Faster experimentation without hardcoding every screen
• Reusable UI patterns across workflows
• More flexibility in internal applications
• Better control over how content and forms are assembled

For web experiences, React is a strong fit for this approach because components can be mapped cleanly from configuration and rendered in a predictable way.

When WebView is a practical choice

Not every mobile use case needs a fully native screen. When page visits are low or the workflow is not performance sensitive, a WebView can be a practical option.

This can help clients:

• Avoid building the same feature separately for web, iOS, and Android
• Move faster on lower-traffic or lower-priority journeys
• Reuse web-driven UI patterns more effectively
• Keep delivery costs under better control

In those cases, the same middleware and dynamic UI approach can support both browser-based flows and mobile WebView experiences, which keeps the architecture simpler.

A practical recommendation

For clients with iOS, Android, and web form factors, a good architecture is often:

1. Keep the form factors lean
2. Add a Backend for Frontend layer for aggregation, caching, and response shaping
3. Use JSON-driven dynamic UI where screens or workflows need flexibility
4. Use WebView selectively for lower-traffic journeys where fully native implementation is unnecessary
5. Let React render the final experience for web based on structured configuration

This reduces duplication, improves consistency, and gives the platform a more scalable foundation without forcing every frontend team to solve the same architecture problem repeatedly.

Final thought

When multiple channels exist, the answer is not to make every client smarter. Very often, the better answer is to make the Backend for Frontend smarter and the clients simpler.

That shift creates a platform that is easier to maintain, easier to scale, and easier to evolve as new use cases emerge.