One Graph, Many Native Surfaces | Topogram<br>Skip to content

One Graph, Many Native Surfaces

AI may change cross-platform app development from one UI framework to one<br>product graph with native surface outputs.

Status: Current

Created: 2026-05-29

Modified: 2026-05-29

Read time: ~4 minutes

Audience: Product owners, engineering leaders, developers, designers, and agents

Use when: You need to think through how cross-platform app work might change if agents can generate and maintain native surfaces from a shared app map.

Cross-platform frameworks have always chased a hard promise: build once, reach<br>many platforms.

Frameworks like .NET MAUI, Flutter, React Native, and earlier hybrid stacks try<br>to reduce the cost of shipping web, iOS, Android, and desktop apps. They package<br>platform differences behind shared code, shared components, or shared runtime<br>layers.

That has real value.

But AI may change what needs to be shared.

If agents can produce more of the implementation, the most valuable shared<br>asset may not be one UI framework. It may be one product graph .

Shared code is not shared intent<br>Section titled “Shared code is not shared intent”

Shared code solves a real problem. It reduces duplication. It keeps business<br>logic from being rewritten four times. It can help a company ship a mobile app<br>without building separate native teams from scratch.

But shared code also creates pressure.

The app may feel less native. Platform behavior can become awkward. Navigation,<br>accessibility, gestures, offline behavior, and performance may not line up<br>cleanly across targets. The team can spend as much time working around the<br>abstraction as using it.

That doesn’t mean cross-platform frameworks are wrong.

It means shared code is not shared product intent .

The deeper question may become: what should actually be shared?

The shared layer may move up<br>Section titled “The shared layer may move up”

The useful shared layer may move above the UI framework.

Instead of asking one framework to make every platform feel right, teams may ask<br>one graph to describe what the product means:

Which capabilities exist.

Which entities and workflows matter.

Which surfaces users need.

Which widgets and states belong on each surface.

Which rules constrain behavior.

Which accessibility and localization promises apply.

Which proof says the experience works.

From there, agents or generators could produce different native outputs.

The web app could use web-native patterns. The iOS app could use iOS-native<br>navigation and controls. The Android app could use Android-native conventions.<br>The desktop app could use desktop affordances.

The shared layer would not be a lowest-common-denominator UI. It would be the<br>app map .

Agents may work better natively<br>Section titled “Agents may work better natively”

This is where the speculation gets interesting.

An agent working on an iOS app may be more effective in a native iOS environment<br>than inside a generic cross-platform abstraction. The compiler, simulator,<br>platform APIs, accessibility tools, and design conventions all give the agent<br>stronger feedback.

The same may be true on Android, desktop, and web.

The agent doesn’t have to guess whether a custom abstraction maps cleanly to the<br>platform. It can work with the platform directly. It can run platform-specific<br>tests. It can inspect native warnings. It can use native components the way a<br>human specialist would.

But that only works if the agent has a shared source of intent.

Without one, every native surface becomes its own interpretation of the product.<br>The iOS app drifts. The web app drifts. The Android app drifts. Desktop becomes<br>the odd surface nobody quite trusts.

Native output is powerful only if the team can keep the product coherent.

One graph, many native surfaces<br>Section titled “One graph, many native surfaces”

The possible shape is one graph, many native surfaces .

The graph describes the product. Each surface implements that product in the<br>right platform language.

That could mean:

One capability appears on web, iOS, Android, and desktop.

Each platform gets native layout, navigation, and interaction patterns.

Shared rules define behavior, not pixels.

Surface records describe what each platform owes the user.

Agents generate or maintain platform-specific code from the same intent.

Reviewers compare each output against the graph and proof.

This is not “write once, run everywhere.”

It is closer to spec once, realize everywhere .

The implementation can differ. The product contract should not.

What happens to .NET MAUI<br>Section titled “What happens to .NET MAUI”

Frameworks like .NET MAUI may still matter.

They solve real problems. Some teams want a unified codebase. Some apps are<br>similar enough across platforms that one framework is the right tradeoff. Some<br>organizations would rather accept platform compromises than staff multiple<br>native surfaces.

AI doesn’t erase that.

But it may create another path. A team may not...