Then you would have guessed wrong.
Even though a lot of mobile app are just presentation layer for a backend service, there are indeed a few stuff that warrants carefulness.
Like any data saved offline. Any update to that offline format means a migration plan unless it’s just a cache for the online data. Then if you support something like multiple organization, you don’t want user data to jump the separation between those siloes. And finally, if you you data that are created locally, or present data that are transformed locally using some feature, you have to be sure you’re not corrupting it or open some side vulnerabilities (think about the clickable vulnerability in messaging apps).
UX and UI can be designed using a prototyping tool coupled with user feedbacks. And with the wealth of components in the mobile SDK and the UI toolkit ability to create custom widgets, it’s very easy to implement the final version of that design. Most of the delicate work is presenting the correct information and that each interaction proceeds well.
I was not talking about a backend service here.
Regarding clickable vulnerabilities in messaging apps, are you referring to the exploits that were enabled by vulnerabilities in system media parser and browser components?
This has essentially no practical relevance to app implementation.
What we are left with is not corrupting user data, particularly during migrations on app updates.
Compared to the attack surface of a backend service that handles user data, this is trivial.
We agree that the delicate work is presentation and interactions working well on device.
In my opinion this is best supported by extensive manual QA and user testing, rather than code review. This is what unlocks tremendous productivity for mobile app development with AI.