To cut a long story short, the UI in the new app is based on capabilities. All standard capabilities, and all community created custom capabilities, have a ‘presentation’ that describes how they should be presented in the UI in various contexts: the status of of a dashboard tile (the dashboard being an alternative name for the home screen in the mobile app); the action of the dashboard tile; whatever the extended area of the dashboard tile might be when it is at home; the details view (that’s the device page in the new app); automation conditions; and automation actions.
At a device handler level, it is possible to define which capabilities are displayed where and in what order, either by creating and/or specifying a device ‘presentation’ or leaving things to default to something sensible. I don’t know if a default device presentation file gets created or if the default stuff happens elsewhere.
The presentation is defined in pretty general terms. The dashboard status is text, the dashboard action is a broad type like ‘pushbutton’, and again the details view is something like ‘toggleSwitch’ or ‘list’.
The conversion of the presentation into what you see in the app is down to the ‘device plugin’. Newer device integrations can, if required, use custom plugins to do their own thing, but anything using the legacy Groovy DTHs is stuck with whatever the default plugin chooses to do.
You may feel my choice of ‘chooses to do’ is a little loaded. You are right. The default plugin seems perfectly happy to ignore the capability presentations for stock capabilities and/or implement completely new device types that are unknown to the API and completely outside developer/user control. It can be rather annoying.