I agree. RN has historically attracted a lot of web developers who treat mobile like a React website, and the result can be terrible. But I've seen exactly the same architectural problem in Flutter: huge widgets, mixed responsibilities, state everywhere, and very little separation of concerns. The framework doesn't protect you from bad engineering.
Ah, that's a shame to hear. I would only like to add that at least for Android apps that I've been "hanging around" (my team never really worked on them), the teaching materials that are provided have generally made them a lot more pleasant compared to the RN stuff.
No framework prevents bad engineering. If a tool is rigid enough to make messy code impossible, it becomes too limited to build anything non-trivial.
Aren't you conflating framework design with dev discipline? You can write a monolithic disaster in React, native iOS, or Flutter with equal ease. Bad architecture usually happens when devs copy-paste habits from web or imperative paradigms without adapting to a declarative model.
Flutter actually gives you great primitives for clean code. UI components are lightweight config objects, so breaking a huge screen into tiny, modular pieces has virtually zero performance penalty. Its state model naturally separates logic from rendering, making it easy to isolate business logic into testable layers. Plus, the built-in analyzer catches anti-patterns like memory leaks at compile time.
all the tools to enforce separation of concerns are there, imo
The case of RN is different: it's made from a web point of view and applied to mobile. Therefore, it's not per se about the framework, but rather a coincidence that mobile and web are two completely different worlds. Hence, it's quite normal to see abominations when you allow people who are used to the web to do mobile development.
