I've worked on plenty of small to mid-size apps and that's not how we ever do it. Like I said, we build views and API requests. That's just the same MVC framework for the past decade or so. And I've done the same for streaming services albeit not at the scale of Netflix. Given how apps like Netflix and YouTube are so nicely synced between mobile, web and STBs I'd still imagine all the logic and persistence is server-side. I can only speak from my experience though, I'd love to understand how you've done it and when you need to embed a lot of non-UI code in a client.

Both Netflix and Youtube (premium) can be used completely offline. I would guess that the iOS and Android apps have a pretty encompassing local data model to keep track of everything from watched status to settings changed in the preferences. Not to say that it isn't synced with the server, but the server isn't the only representation.

most MVC apps do still have a decent amount of business logic for things like caching (either http responses, or images, or a local db), authentication etc.. In theory the goal for a lot is to have a dumb client like you said but that's rarely the case.

If you can have your apps share their data models between both android and iOS you can have the apps share the HTTP request/response handling and their DB code etc and then it truly becomes just a dumb client.

YouTube/Netflix also have complex video encoding/playback code that can be written in c++ and shared between clients.

Most social media apps liek FB/Insta/Snapchat have complex camera and photo handling code as well as async messaging code. Which if you have things like retries or photo compression/encryption you'd probably want to share between clients. etc..

Let’s say you’re creating a presentation builder app and one of the requirements is that it work in airplane mode since people are likely to use the app to put together presentations while literally on an airplane. Having all the logic server-side simply doesn’t work for that use case.