Both cross-platform frameworks (Flutter, React Native) and server-driven UI claim to speed up mobile development. But they approach the problem from completely different angles.
Cross-platform speeds up building — write code once, deploy to iOS and Android.
Server-Driven UI speeds up releasing — deploy changes without app store review.
Let's break down when each makes sense.
The Quick Comparison
What Cross-Platform Actually Solves
Cross-platform frameworks solve the development cost problem:
- One codebase — Stop writing everything twice
- Smaller team — Don't need separate iOS and Android specialists
- Faster initial development — Ship your MVP faster
- Feature parity — Both platforms get features simultaneously
This is real value. Companies like Shopify, Nubank, and (briefly) Airbnb adopted cross-platform for these reasons.
But Cross-Platform Doesn't Solve Release Speed
Here's the thing: you still need app store review.
Whether you write in Dart, JavaScript, Swift, or Kotlin — every UI change still requires:
- Building a new version
- Going through QA
- Submitting to app stores
- Waiting 24-48 hours for review
- Hoping users actually update
"We were bound by a weekly release cadence. The server-driven UI architecture allows us to launch experiments whenever we deem necessary."
— Shopify Engineering (who uses both React Native AND SDUI)
What Server-Driven UI Actually Solves
SDUI solves the release velocity problem:
- No app store wait — Changes go live in seconds
- A/B testing — Experiment without shipping builds
- Old version updates — Reach users who never update
- Emergency fixes — Fix UI bugs instantly
The trade-off? You still write native code for each platform (unless you combine SDUI with cross-platform).
Why Not Just Use CodePush / Hot Updates?
React Native has CodePush. Flutter has Shorebird. These let you push JavaScript/Dart updates without app store review.
The limitations:
- Apple restrictions — Only "bug fixes" allowed, not new features
- Still code changes — Requires engineering, QA, deployment
- Binary dependency — Can't update users on old app versions
- Risk of rejection — Apple has banned apps for misusing hot updates
SDUI is architecturally different. The client renders whatever the server sends — it's not pushing code, it's fetching UI definitions. This is why Airbnb, Netflix, and Lyft chose SDUI over hot update hacks.
Can You Combine Them?
Yes. Many companies use both:
- Shopify — React Native + SDUI for specific screens
- Some startups — Flutter for the app, SDUI for dynamic content
This gives you:
- Single codebase (cross-platform)
- Fast releases for specific screens (SDUI)
The downside: more architectural complexity. You're maintaining two paradigms.
Decision Framework
Choose Cross-Platform (Flutter/RN) if:
- You're a small team building a new app
- Development cost is your main constraint
- Your UI doesn't change frequently after launch
- You can live with weekly/biweekly releases
Choose SDUI if:
- Release velocity is killing you
- You run frequent A/B experiments
- You have users stuck on old app versions
- You already have native expertise
- You need screens that change frequently (onboarding, checkout, promos)
Choose Both if:
- You want cross-platform efficiency AND release speed
- You have the engineering bandwidth to maintain complexity
- Specific flows (experiments, onboarding) need SDUI, but most of the app is stable
The Real Question
Cross-platform vs native is a build-time decision.
SDUI vs hardcoded is a release-time decision.
They're orthogonal. You can be native + SDUI. You can be Flutter + SDUI. You can be native + hardcoded.
The question is: what's actually slowing you down?
- If it's writing code twice → cross-platform helps
- If it's waiting for app store review → SDUI helps
- If it's both → you might need both
Ready to Ship Faster?
Pyramid gives you server-driven UI with native SwiftUI and Jetpack Compose — keep your native codebase, lose the app store wait.
Get Early Access →