First I would notice that this is a problem that has remained unsolved for 34 years, since the diffusion of PUI (GUI from PARC). At the time, we had the Mac "f

First I would notice that this is a problem that has remained unsolved for 34 years, since the diffusion of PUI (GUI from PARC). At the time, we had the Mac "framework", the Atari (Gem), MS-Windows and X11 "frameworks", and already then, people tried to design meta-frameworks allowing them to write a single PUI application and deploy it on those multiple systems. Whole books were written about the, describing by the minutiae the commonalities and differences between those frameworks, and explaining how one could write a common application, or port applications from one to another. Needless to say, not much progress or success has been made since. You have things like Delphi or the JVM that can let you develop applications that can run on all those platforms, but they still always remain somehow alien to each of the platforms where they run. Yes, indeed, there are such tools to build Android and iOS applications from a single source. If your application is not demanding on the user interface (ie. if it has a simplistic user interface) and on other features of the platforms (sensors, toolkits), then basically it will do. However in practice, and this is why you get those responses from app dev shops, your application will want to use specific features on each specific platform, or will have some UI sophistication that won't be handled satisfactorily by the meta-framework, and this is when it'll start to be a lot more work trying to build the applications with them, instead of writing two native UI applications. In addition, to do it correctly with a common meta-framework, you would need a developer who knows well both target platforms, and who is capable when developping on the meta-platform, to think ahead how his code will run on both platforms! This kind of developer are more expensive than two developers each specialized on his own platform. All is not lost however, since you should modularize your software anyways, you will have components that are generic to your application, and components that are specific to the user interface. Only those later components need to be developped in two different versions, on the target platforms. The generic core components can be developped once for all, in the form of a library that will be used by the native applications. The only downside here is that these generic core components will have to be written in a common programming language, most probably C or C++, if you don't want to fight with development environment (you could try Common Lisp, wich translators such as MoCL https://wukix.com/ https://wukix.com/, or Java which has a few compilers that you could use to target iOS such as http://j2objc.org/ http://j2objc.org/, but in all those cases, batteries are NOT included). There's a caveat: iOS and Android applications are often only user interface, they're not functional programs. Without a back-end server, in general you cannot do anything with those applications. This is both a blessing and a curse: blessing since this means that now your generic core components are implemented on the server; a curse because when there's no connectivity, the user cannot do anything. But if those generic code components are implemented on the server, then you see that there remains on the handheld computers only the user interfaces, and therefore that you don't have any common code in the Android and iOS applications. Hence the conclusion and advice given: develop two independent native applications by two specialized teams. This will be the cheapest and fastest way to do it, since the two teams can work in parallel. You have in common only the specifications, and the core components on the server, the later you can develop yet in parallel by a third team.