Most major apps phone home for a big config object (likely JSON) at the start of a run. This would contain things like car icons, etc. You can see an example of this in the 3p Uber API which has a call to get which car types are available at a given geolocation. This API returns not only the vehicle types (Uber X, Uber Black, etc) but also a jpeg icon representing the car. In this way Uber can roll out new car types in locations without a client side update.
I'm biased for this next part (since I work on the product) but if you're interested in making your app have abilities like this check out Firebase Remote Config (https://firebase.google.com/docs/remote-config/). While setting up your own config service is not rocket science, having a free one with a web UI is pretty nice.
That is for your answer. I suppose that the interesting code is on the app side rather than the server side (which basically returns a Bunch of Json)
How do you architect a view layer that's so malleable - for example even the routes in Uber were shown in rainbow during pride.
Last time I checked their iOS app pinged the backend around every 10 seconds for a big ol' payload of JSON config etc, which contained most of the A/B stuff and UI config (which car types to display, e.g., as where you are they might not have all of X/taxi/Black/Lux etc).
Most likely just a simple alerts or announcements model that they fetch from the server and display into a pre-allocated section in the ios view (whatever they call it in iOS), if any. It's actually really good thinking.
They likely already preset views and controllers to react to backend events. If they add an event like "pride" to the backend, the app just has to render the view associated with that event.
I don't think it's that simple. The distinction between "code" and "data" is somewhat arbitrary. I'm sure Uber could get away with a rules engine that supports the cases the parent comment is talking about.
I wonder what's the architecture of the app and the API for this.