¿Una app barata y con cierto rendimiento? El framework de desarrollo multiplataforma que mejor se adapte. (Elegir sólo uno que parezca bonito, o uno que tenga buenas críticas, o uno que te guste, puede no darte un framework que pueda desarrollar la app que quieres desarrollar.)
¿Una app buena y bien desarrollada? No lo haces así. La app la desarrollas en inglés igual, así que empiezas con eso. (El desarrollo de software no es teclear código en un ordenador, es pensar cómo resolver el problema que tu app va a resolver). A continuación, la codificas para que funcione en el entorno en el que vaya a funcionar. La API, sus argumentos y su retorno son tan parte del entorno como lo es el lenguaje de programación.
Lo único que necesitas para que una aplicación se caiga de bruces es que el framework que elijas no tenga una forma de realizar una función concreta en un entorno u otro - entonces hay que volver a la mesa de dibujo para volver a desarrollar la aplicación (lo que es mucho más difícil que desarrollarla en primer lugar).
Ejemplo sencillo: diseñé un programa para que actuara como front-end (un sistema operativo primitivo antes de que hubiera sistemas operativos) en un 8080, utilizando una instrucción "compare". Luego tuve que hacerlo funcionar en un 8049. No hay instrucción de comparación en un 8049. (Tardé unos minutos en averiguar cómo evitarlo - porque entendía el funcionamiento del 8049, y porque, para entonces, tenía unos 12 años de experiencia en desarrollo.)
Otro ejemplo sencillo. Teníamos un programa que se ejecutaba en el PC de IBM (en 1985, había otros PC) que dependía del hecho de que la entrada serie estaba dirigida por interrupciones, por lo que podíamos escribir un TSR (un pequeño trozo de código que permanecía residente en la RAM) para capturar la entrada del puerto serie y mantenerla hasta que estuviéramos listos para leerla. (Era un puerto de un byte - cuando entraba el siguiente byte, se borraba el anterior). Un cliente quería comprar el programa (que era bastante caro, y se utilizaba para un equipo mucho más caro) en su Apple ][, ya que no quería gastar el dinero en un PC. (Está comprando un equipo de 30.000 dólares, pero no quiso gastar los 1.200 dólares en un PC, ni los 800 dólares en otros ordenadores de sobremesa que hubieran funcionado). Así que tuve que hacer que el programa funcionara en un Apple ][ - que no utilizaba un puerto serie con interrupciones y no tenía ningún medio para manejar un TSR. Pero el Applesoft (BASIC de punto flotante de Apple) tenía una instrucción Varptr, así que podía definir una cadena con las instrucciones de código máquina para coger la entrada en serie según llegaba, y añadirla a otra cadena - y obtener la dirección de esa primera cadena, para poder meterla en la RAM - y funcionaría como parte del programa BASIC.
Pero eso es lo que pasa con un programa de "talla única". No lo hace, tienes que volver a desarrollar el programa. Así que más vale que lo hagas desde el principio porque no tienes ni idea de lo que hace tu app en el código del framework a no ser que te pases meses aprendiendo cada byte del mismo. Y tu trabajo es escribir una aplicación, no aprender un framework, así que ¿por qué añadir trabajo?
Aprende Java/Kotlin, aprende Swift, desarrolla tu aplicación (asegurándote de que tienes un iPhone de último modelo que ejecute al menos iOS 12, y un teléfono Android de último modelo que ejecute al menos Pie - para que puedas asegurarte de que el teléfono puede hacer lo que quieres - no todos los teléfonos tienen, por ejemplo, IR Blasters), codifícalo en Java/Kotlin para Android, y luego codifícalo en Swift para iPhones.
Desarrollar la app es el gran trabajo, codificar es un par de días (una vez que hayas aprendido programación, y una vez que estés familiarizado con ambos lenguajes).
Oh - si aún no has aprendido programación - algo como Algoritmos+Destructuras de Datos=Programas de Wirth - no estás preparado para desarrollar una app. El desarrollo de una aplicación - a menos que quieras desarrollar la 138ª versión de la misma aplicación que lleva 5 años en el mercado - no es codificar y no es arrastrar componentes a formularios. Eso es aprender una parte muy pequeña del desarrollo de programas. Aprende primero a programar - serás un desarrollador mucho mejor, y una persona mucho más feliz.
Y si vas a usar una base de datos, aprende SQL, ya que la base de datos va a ser una base de datos SQL.