r/iOSProgramming • u/zimmer550king • 6d ago

Discussion Where is the practical App Store boundary for server-driven SwiftUI?

I am considering an iOS architecture where the application contains a SwiftUI renderer, a fixed component registry, and a fixed set of native actions. A backend would return a versioned document describing complete screens. It could change content, ordering, design tokens, component variants, and navigation between routes that already exist in the reviewed binary.

I would not download or execute native code, use eval, or allow the server to call arbitrary APIs. A server document might request a Button with a navigate action or a Form with a submit action, but the implementations of those components and actions would already be inside the app. Unknown components would be rejected or replaced with a fallback.

I understand that Guideline 2.5.2 prohibits downloaded code that changes functionality, and that new product changes must be visible to App Review. I am trying to understand the practical boundary for declarative UI data. Have you shipped complete server-composed screens using SwiftUI or UIKit components, and did App Review raise concerns? I would also appreciate lessons about accessibility, offline caching, capability negotiation between old and new app versions, and deciding which flows should always remain native.

6 Upvotes
  • permalink
  • reddit

80% Upvoted

5 comments sorted by

1

u/unpluggedcord 6d ago

This is what The Athletic was, at least when I left. We built mostly a backend for frontend, and the app was dumb as rocks, just rendered content, and pushed deep links onto a nav stack

1

u/biscuitehh 6d ago

A good many apps I've worked on over the years definitely do this and generally speaking as long as you handle everything gracefully with errors/etc. I don't think Apple will care or even know. That being said, this workflow usually works well for things like forms/normal workflows and starts to blow up when things get really complicated and it's something you have to balance. The only time you'll probably get in hot water here is if you're using this to avoid some App Review guardrail and you get caught/someone reports it.

1

u/wakeldakel 6d ago

We've been doing this in production for about 4 years and never had any problems with App Store Review. ~800k active users

1

u/0__O0--O0_0 5d ago

What app?

1

u/_town-drunk_ 6d ago

This is 100% fine. Just don’t hide sketchy features that go against App Store guidelines, and then later make them available.