I'm not a fan of this type of architecture for many reasons. One of the reasons is the difficuly of organizational coordination, which is funny because a few years ago Airbnb had a blog post about how they gave up on React Native and one of the reasons they gave was the difficulty of organizing changes across teams, but with SDUI that problem is worse, you need tight coordination across many teams to push features. One way to think about it as engineers is how we prefer decoupled systems with clear interfaces and boundaries. SDUI is the opposite of that, it's tight coupling between all the clients and the backend, changes to your UI are split across a bunch of teams and systems.

There are also a bunch of other problems, off the top of my head:

  - difficulty caching resulting in bad performance

  - bad performance because you end up unnecesarily reloading entire screens just in case one small piece of UI changed

  - difficulty taking advantage of unique platform features

  - difficulty handling animations or smooth transitions

  - client engineers lose understanding of the business data model, and motivation since all the action is in the backend.
 
  - hard tracing bugs across frontend to backend
  
  - doing UI in gql schemas is awful. sdui+gql are opposite goals, sdui wants dumber clients gql wants smarter clients. When would a client ever decide not to request a gql schema field? Which is another thing, you have to request these giant schema represantation of the UI which is bad for performance, youre basically sending your entire UI layout and receiving it back filled with data.

  - complexity, difficulty hiring, not being able to use the latest best practices and architectures

  - consistency across platforms is bad as a fundemental goal, users don't care since they typically use one platform. Consistency across mobile and web is actually bad UX in many cases.