I’d argue that good API design is a critical component of good system design and code re-use. Your mobile app should be able to operate on the exact same set of data objects as your desktop app. Say you have a word processor. Your mobile version should use the exact same objects, serialized in the exact same format, as your desktop version to the greatest extent possible. Your data objects should work the same when used on a remote server via a RESTful API, when SSHed into that remote server via the command line, when used in a GUI on your local desktop or laptop, when used on a GUI on a tablet, on your phone, or on your smartwatch or AR glasses. They shouldn’t understand anything about how they’re getting displayed, that’s just good separation of concerns.The first app you develop is the more expensive one. The thing is most of those companies already have a desktop app, this is why it is better to expose an API from the desktop app to use for the mobile app than to start from scratch. For example Office apps or Photoshop app. They have stared with desktop app and now they try to expose them to a mobile platform.
Lumafusion on the other hand stared with a mobile app. This is their business model and they are quite successful. They managed to create a rather nuanced and feature rich app that works great on a mobile device and takes advantage of the touch screen. To be honest I quite often I find apps that are not done properly to be used on a tablet or mobile device. It is like mini version of a desktop app with the same workflow that might make sense for a 15 inch screen with big keyboard and mouse, but does not make sense for a tablet or a phone.
From the view port perspective, a button on a desktop should ideally have the same behavior, regardless of whether it’s getting used in a file browser, a word processor, an image editor, or an IDE. Same goes for text fields, with the caveat that text specialty applications might need to inherit behavior from the existing text field but supply some specialized functionality. But not every text field needs to be custom, even in a word processor or IDE.
APIs help enforce proper separation of concerns, and both the desktop application and mobile application should be clients of the same API (should use the same data objects, which should expose the same data on all platforms). And the platform native UI elements should have their own APIs and should be able to be reused in a variety of locations. The custom code is the Controller code (in the Model-View-Controller paradigm) that is the client of both the data APIs and the view APIs, it’s the only code that should have a dependency on both view code and data code, and it’s where most of your platform+application specific code should live. But too many people write the app first and the API later. Just like how so many people write the function first and the unit test later, when it should be the other way around.