¿Aplicación móvil nativa o multiplataforma?

Según Mesterséges Intelligencia Központ Kft., empresa de desarrollo de software con sede en Budapest, una app nativa hace falta cuando la aplicación usa a fondo el dispositivo; si ambas plataformas tienen las mismas funciones, una base de código común es más fácil de mantener.

En resumen: la decisión depende de las funciones, no de la moda: hasta qué punto tiene que acceder la app al dispositivo, cuánto rendimiento necesita y quién la mantendrá durante años. Si la presencia en las tiendas y el acceso profundo al dispositivo no son importantes, también puede bastar una aplicación web (PWA). Sea cual sea el camino elegido, el backend, las reglas de las tiendas y las actualizaciones periódicas de los sistemas operativos suponen una parte importante del trabajo.

¿Qué significan aplicación nativa, multiplataforma y web?

Una aplicación móvil puede desarrollarse de tres maneras: por separado para cada plataforma, con las herramientas propias de la plataforma; a partir de una base de código común que se compila para ambas plataformas; o con tecnología web, ejecutándose en el navegador. Las tres vías dan como resultado una aplicación que funciona; la diferencia está en el acceso, en el mantenimiento y en quién dicta las reglas según las cuales se actualiza la app.

Aplicación nativa

En una aplicación nativa, la versión para iOS y la versión para Android se desarrollan por separado, en el lenguaje y con las herramientas de interfaz propias de cada plataforma. En iOS, hoy esto significa normalmente el lenguaje Swift y SwiftUI: según Apple, SwiftUI permite construir la interfaz en todas las plataformas de Apple con una sintaxis declarativa y basándose en el lenguaje Swift (Apple: SwiftUI). En Android, significa Kotlin y Jetpack Compose: Google califica Jetpack Compose como el conjunto de herramientas moderno y recomendado de Android para crear interfaces nativas (Android Developers: Jetpack Compose), y recomienda empezar con Kotlin las nuevas aplicaciones para Android (Android Developers: Kotlin-first). La ventaja de la vía nativa es que cada nueva posibilidad de la plataforma está disponible directamente desde el primer día; el inconveniente, que hay que desarrollar y mantener dos bases de código.

Frameworks multiplataforma

Con los frameworks multiplataforma, la aplicación para iOS y la de Android se crean a partir de una base de código común. Cuatro enfoques habituales:

Flutter: framework basado en el lenguaje Dart. Según su documentación, Flutter implementa por sí mismo cada elemento de la interfaz en lugar de utilizar los del sistema, y para dibujarlos utiliza un motor llamado Impeller; el código propio de la plataforma puede llamarse a través del llamado canal de plataforma (platform channel) (Flutter: Architectural overview).
React Native: basado en React y JavaScript; según la formulación del propio proyecto, se escribe en JavaScript pero se representa con código nativo, porque sus componentes básicos se corresponden con los elementos nativos de interfaz de la plataforma (React Native). Desde la versión 0.76, la llamada nueva arquitectura (New Architecture) es la predeterminada, y sustituye el puente asíncrono por la JavaScript Interface (JSI) (React Native: New Architecture).
Kotlin Multiplatform: tecnología de código abierto de JetBrains con la que el código puede compartirse entre destinos Android, iOS, de escritorio, web y de servidor. Puede compartirse solo la lógica de negocio, con una interfaz nativa, o también la interfaz, con Compose Multiplatform (Kotlin: Kotlin Multiplatform). Según la documentación de Kotlin, Compose Multiplatform tiene nivel estable (Stable) también en iOS (Kotlin: stability of supported platforms, comprobado el 17 de octubre de 2026).
.NET MAUI: framework de Microsoft basado en C# y XAML, con el que se pueden desarrollar aplicaciones para Android, iOS, macOS y Windows a partir de una única base de código común; es la evolución de Xamarin.Forms. Para compilar aplicaciones para iOS y macOS se necesita un Mac (Microsoft Learn: What is .NET MAUI?).

Aplicación web progresiva (PWA)

La PWA es una aplicación web que se ejecuta en el navegador, puede instalarse en la pantalla de inicio y, gracias a funciones que se amplían de forma progresiva (progressive enhancement), ofrece una experiencia más fiable. Según el resumen de web.dev, las aplicaciones de plataforma destacan por sus capacidades, y las aplicaciones web, por su alcance: una única base de código llega a cualquier persona, en cualquier dispositivo (web.dev: Progressive Web Apps). En iOS y iPadOS, desde la versión 16.4, una aplicación web añadida a la pantalla de inicio también puede solicitar permiso para enviar notificaciones push (WebKit: Web Push for Web Apps). Un límite importante: según el punto 4.2 de las directrices del App Store, la aplicación debe ofrecer algo más que un sitio web reempaquetado, por lo que no conviene llevar a la tienda un sitio web simplemente empaquetado como app (Apple: App Store Review Guidelines).

Comparación en una tabla

Criterio	Nativa (Swift, Kotlin)	Multiplataforma (Flutter, React Native, KMP, .NET MAUI)	PWA
Rendimiento	optimizable directamente con las herramientas de la plataforma	las partes de cálculo intensivo pueden llevarse a código nativo	lo determinan el navegador y la tecnología web
Acceso al dispositivo	todas las funciones de la plataforma, desde el primer día	a través del framework o de un complemento; una función nueva llega más tarde o requiere código nativo adicional	limitado a las interfaces web que admite el navegador
Aspecto y sensación de uso	exactamente los elementos propios de la plataforma	en Flutter, elementos dibujados por el propio framework; en React Native, elementos nativos	similar a un sitio web, depende del navegador
Código compartido	ninguno, dos bases de código separadas	la lógica y, por lo general, también la interfaz son comunes	una base de código para todos los dispositivos
Equipo	conocimientos de iOS y de Android por separado	un solo equipo, pero también hacen falta conocimientos de las capas nativas	un equipo de desarrollo web
Mantenimiento	dos bases de código siguen los cambios periódicos de las plataformas	una base de código, más las actualizaciones propias del framework	sin publicaciones en las tiendas; hay que seguir los cambios de los navegadores
Tamaño de la aplicación	se basa en las bibliotecas propias del sistema	el motor del framework también se incluye en la aplicación	sin paquete de instalación; el navegador almacena en caché
Presencia en las tiendas	sí	sí	no es necesaria; si se empaqueta para la tienda, rige el límite del punto 4.2

La documentación de Flutter lo dice expresamente: el paquete de una aplicación Flutter es autónomo y contiene todo el código y los recursos necesarios para su ejecución, por lo que su tamaño puede ser un factor a tener en cuenta (Flutter: Measuring your app's size). En la práctica, la diferencia rara vez es decisiva, pero conviene conocerla si el público objetivo utiliza la app en dispositivos más antiguos o con una conexión débil.

¿Cuándo encaja cada una?

Nativa, si

la aplicación usa a fondo el dispositivo: cámara, sensores, Bluetooth, tareas en segundo plano;
tiene grandes exigencias de rendimiento, por ejemplo, procesamiento de imagen o de sonido en tiempo real, o animaciones complejas;
hay que aprovechar de inmediato las posibilidades más recientes de la plataforma;
solo se necesita la aplicación para una de las plataformas, o las dos versiones difieren sustancialmente.

Multiplataforma, si

las dos plataformas tienen las mismas funciones y es importante que los cambios aparezcan a la vez;
la aplicación consta sobre todo de formularios, listas, visualización de datos y notificaciones, como la mayoría de las aplicaciones empresariales;
un solo equipo mantendrá la aplicación a largo plazo;
la empresa ya utiliza el lenguaje del framework; por ejemplo, los conocimientos de React para la web apuntan a React Native, y una base en .NET, a .NET MAUI.

PWA o aplicación web, si

los usuarios no buscan la aplicación en la tienda, sino que llegan desde un enlace o desde el sitio web;
no se necesita un acceso profundo al dispositivo;
la aplicación tiene que funcionar igual en el ordenador de escritorio y en el teléfono;
las actualizaciones rápidas, sin revisión de las tiendas, importan más que las funciones de la plataforma.

Tampoco aquí los límites son nítidos. Con Kotlin Multiplatform, por ejemplo, la lógica de negocio puede ser común y la interfaz seguir siendo nativa; en Flutter y React Native, una parte crítica también puede escribirse en código nativo. El juego de nuestro propio sitio web funciona como aplicación web: se ejecuta en el navegador sin instalación, igual en equipos de escritorio que en teléfonos. Sobre la vía web escribimos en la página Desarrollo de sitios web y aplicaciones web.

El backend y el panel de administración

Una aplicación móvil rara vez se sostiene por sí sola. En cuanto tiene cuentas de usuario, datos compartidos o notificaciones, necesita un servidor detrás: allí residen las cuentas, los datos y los permisos, y desde allí se envían las notificaciones. El backend suele enviar las notificaciones push a través de un servicio dedicado a ello; Firebase Cloud Messaging, por ejemplo, es una solución de mensajería multiplataforma en la que un entorno de servidor de confianza compone y envía los mensajes a las aplicaciones de Apple, de Android y web (Firebase: Cloud Messaging).

El panel de administración es el centro de control del backend: desde el navegador se edita el contenido y se gestionan los usuarios y los ajustes, para que los cambios del día a día no requieran un desarrollador. Ahí conectamos también los sistemas existentes de la empresa, como un sistema de gestión de clientes, un registro de inventario o un programa de facturación, para que la aplicación trabaje con los mismos datos que el resto de la empresa. Si todavía no existe un sistema así, también lo construimos como software a medida. La decisión entre nativa y multiplataforma no afecta al backend: el mismo servidor puede dar servicio a una aplicación nativa y a una desarrollada con Flutter.

Publicación en las tiendas de aplicaciones: ¿qué tener en cuenta en octubre de 2026?

Las reglas de las tiendas cambian a menudo, por lo que los puntos siguientes llevan fecha (comprobado el 17 de octubre de 2026).

App Store (Apple)

Directrices de revisión: las App Store Review Guidelines se actualizaron por última vez el 16 de octubre de 2026. Según el punto 2.1, hay que enviar una versión completa y lista para la revisión; si la app tiene inicio de sesión, hay que facilitar una cuenta de demostración, y el backend debe funcionar también durante la revisión. Según el punto 5.1.1, todas las aplicaciones deben enlazar a su política de privacidad y, si la app permite crear una cuenta, también debe ofrecer la eliminación de la cuenta dentro de la aplicación (Apple: App Store Review Guidelines).
Ficha de privacidad: en App Store Connect hay que declarar las prácticas de tratamiento de datos de la aplicación, incluidas las de los componentes de terceros integrados (por ejemplo, los SDK de analítica); esto es necesario para enviar tanto aplicaciones nuevas como actualizaciones (Apple: App privacy details).
Requisito de herramientas de desarrollo: desde el 28 de abril de 2026, las aplicaciones que se suben a App Store Connect deben compilarse con Xcode 26 o una versión posterior, con el SDK de iOS 26, y desde el 9 de septiembre de 2026 las aplicaciones para iOS y iPadOS deben tener como destino al menos iOS 13 (Apple: Upcoming requirements).
Cuenta de empresa: para registrarse como organización, la empresa debe ser una persona jurídica y disponer de un número D-U-N-S, y la persona que realiza el registro debe estar facultada para obligar legalmente a la empresa (Apple: Enrollment).
Condición de comerciante en la UE: Apple pide a los desarrolladores que declaren si tienen la condición de comerciante según el Derecho de la Unión; en la UE, los datos de contacto de los comerciantes se muestran en la página de la aplicación en la tienda (Apple: Digital Services Act trader requirements).

Google Play

Nivel de API de destino: desde el 31 de agosto de 2026, las aplicaciones nuevas y las actualizaciones para teléfonos deben tener como destino al menos Android 16 (nivel de API 36); las aplicaciones existentes deben tener como destino al menos Android 15 (nivel de API 35) para seguir estando disponibles para los nuevos usuarios en los dispositivos con versiones más recientes de Android. Con una prórroga solicitada en Play Console, el plazo es el 1 de noviembre de 2026 (Android Developers: Target API level).
Pruebas con cuentas personales: en las cuentas de desarrollador personales creadas después del 13 de noviembre de 2023, antes de la publicación en producción hay que realizar una prueba cerrada con al menos 12 testers que participen en ella de forma ininterrumpida desde hace al menos 14 días (Play Console Help: testing requirements).
Cuenta de organización: no se puede crear una cuenta de desarrollador de organización sin número D-U-N-S (Play Console Help: creating an account).
Formulario de seguridad de los datos: debe completarse para todas las aplicaciones publicadas en Google Play, aunque la app no recopile datos de usuarios (Play Console Help: Data safety).
Eliminación de la cuenta: si en la aplicación se puede crear una cuenta, la eliminación de la cuenta y de los datos asociados debe poder solicitarse tanto dentro de la aplicación como a través de un enlace web (Play Console Help: account deletion requirements).

Estas reglas se aplican con independencia de la tecnología: una aplicación desarrollada con Flutter o React Native tiene que cumplir los mismos requisitos de API de destino y de SDK que una nativa, y las actualizaciones del framework tienen que seguirlos. Recomendamos que la cuenta de desarrollador pertenezca a la empresa del cliente: así la aplicación aparece con el nombre de su empresa, y la ficha de la tienda también sigue siendo de la empresa.

Accesibilidad

Ambas plataformas incluyen un lector de pantalla integrado (VoiceOver en iOS y TalkBack en Android) y ofrecen interfaces para que las aplicaciones colaboren con estas tecnologías de apoyo (React Native: Accessibility). La documentación de Flutter, por ejemplo, recomienda que el lector de pantalla describa de forma comprensible cada control, que la relación de contraste entre el texto y el fondo sea de al menos 4,5:1 y que cada elemento táctil mida al menos 48×48 píxeles (Flutter: Accessibility). La documentación de Android recomienda las directrices de Material Design, la herramienta Accessibility Scanner y las comprobaciones automáticas para detectar los problemas (Android Developers: Accessibility).

No es solo una buena práctica: según la Directiva (UE) 2019/882, los Estados miembros deben aplicar a partir del 28 de junio de 2025 los requisitos de accesibilidad relativos a los servicios de comercio electrónico prestados a los consumidores, también los prestados a través de aplicaciones móviles (las normas húngaras se basan en la transposición de la directiva); las microempresas que prestan servicios deben quedar exentas (EUR-Lex: Directiva (UE) 2019/882). Los detalles relativos a las tiendas online se tratan en el artículo Tienda online: ¿plataforma alojada o desarrollo a medida?.

Inteligencia artificial: ¿en el dispositivo o en la nube?

En una aplicación móvil, la función de IA puede ejecutarse en dos lugares: en el propio teléfono o en un gran modelo de lenguaje en la nube, a través del backend.

En el dispositivo (Apple): a partir de iOS 26, el framework Foundation Models de Apple da acceso a los modelos diseñados para Apple Intelligence que se ejecutan en el dispositivo y en Private Cloud Compute; puede utilizarse para generar texto, obtener salidas estructuradas y llamar a herramientas propias, pero solo en los dispositivos compatibles con Apple Intelligence (Apple: Foundation Models).
En el dispositivo (Android): Gemini Nano se ejecuta en el servicio del sistema AICore de Android y está disponible a través de las API de ML Kit GenAI, por ejemplo, para resumir, corregir textos, reformularlos y describir imágenes. Según Google, funciona también sin conexión a la red y los datos sensibles permanecen en el dispositivo, pero el modelo está limitado por el límite de tokens y por el hardware del dispositivo (Android Developers: Gemini Nano).
En la nube: los grandes modelos de lenguaje de OpenAI (ChatGPT), Anthropic (Claude) y Google (Gemini), para tareas más complejas: un asistente que responde a partir del material propio de la empresa, procesamiento de documentos e imágenes, resúmenes. La clave de acceso al servicio de IA se queda en el backend, no en el teléfono: así no puede extraerse de la aplicación, y el uso puede controlarse en el servidor.

Un modelo que se ejecuta en el dispositivo resulta atractivo por la protección de datos y el funcionamiento sin conexión, pero no está disponible en los dispositivos de todos los usuarios, por lo que normalmente conviene diseñarlo junto con una alternativa en la nube. Sobre la conexión de los modelos trata la página Integración de IA.

¿De qué depende el mantenimiento?

Una aplicación móvil no está terminada ni siquiera tras la entrega: su entorno cambia continuamente. El trabajo de mantenimiento lo determinan principalmente estos factores:

Los requisitos de los sistemas operativos y de las tiendas: Apple exige versiones más recientes de Xcode y del SDK para las subidas, y Google Play, un nivel de API de destino más reciente; las fechas anteriores muestran que estos requisitos suben periódicamente.
Los cambios en las directrices de las tiendas: nuevas declaraciones de privacidad, normas sobre la eliminación de cuentas o sobre las pruebas.
Las actualizaciones del framework: en una app multiplataforma, un cambio de versión importante de Flutter, React Native o .NET MAUI puede suponer trabajo en el código propio y en los complementos utilizados.
Los componentes de terceros: SDK de pagos, de mapas y de analítica, que también tienen sus propios requisitos de actualización.
El backend y las integraciones: los cambios en las interfaces de los sistemas empresariales conectados y de los servicios de IA.
El número de bases de código: dos aplicaciones nativas requieren modificaciones en dos sitios.

Errores frecuentes

La tecnología la deciden las costumbres del equipo, no las funciones de la aplicación.
No se tienen en cuenta el backend ni el panel de administración, solo las pantallas.
Se empaqueta un sitio web sin más como app, y la tienda la rechaza.
La cuenta de desarrollador está a nombre de la empresa de desarrollo, y la ficha de la tienda no puede transferirse después.
La eliminación de la cuenta, la ficha de privacidad o la cuenta de demostración se añaden el mismo día del envío.
Nadie se encarga de las actualizaciones después de la entrega, y tras un cambio de normas la app deja de estar visible para los nuevos usuarios.

Preguntas frecuentes

¿Nativa o Flutter/React Native?

Si la aplicación usa a fondo el dispositivo (cámara, sensores, procesos en segundo plano) o tiene grandes exigencias de rendimiento, el desarrollo nativo es el camino más seguro. Si las dos plataformas tienen las mismas funciones, una aplicación con una base de código común desarrollada con Flutter o React Native es más fácil de mantener. Con Kotlin Multiplatform también es posible una vía intermedia: lógica de negocio común e interfaz nativa. En la primera consulta le hacemos una recomendación basada en las funciones concretas.

¿Cuándo basta una aplicación web (PWA)?

Cuando los usuarios llegan desde un enlace o desde el sitio web, no se necesita un acceso profundo al dispositivo y es importante que funcione igual en el ordenador de escritorio y en el teléfono. Puede instalarse en la pantalla de inicio y también puede enviar notificaciones push en iOS, pero no ofrece presencia en las tiendas, y el abanico de funciones del dispositivo depende del navegador.

¿Hace falta un backend?

Casi siempre: en cuanto la aplicación tiene cuentas de usuario, datos compartidos o notificaciones, necesita un servidor detrás. La excepción es la aplicación que solo almacena datos en el dispositivo. También construimos el backend y el panel de administración, y los conectamos con los sistemas existentes de la empresa.

¿Quién publica la aplicación en las tiendas?

De la publicación nos encargamos nosotros: preparamos los materiales de la ficha de la tienda y las declaraciones de privacidad, enviamos la aplicación y la acompañamos durante toda la revisión. Recomendamos que la cuenta de desarrollador sea de su empresa; para una cuenta de organización, ambas tiendas piden un número D-U-N-S, por lo que conviene obtenerlo con tiempo.

¿De qué depende el coste del mantenimiento?

De cuántas bases de código hay que mantener, de con qué frecuencia cambian los sistemas operativos y los requisitos de las tiendas, de cuántos componentes de terceros e integraciones utiliza la app y de cuánta evolución se prevé. El precio del desarrollo lo calculamos a partir del tamaño funcional; el método se describe en la página Precios.

¿Cómo podemos ayudarle?

Desarrollamos aplicaciones para iOS y Android: construimos detrás de ellas el backend y el panel de administración, integramos la inteligencia artificial y las llevamos hasta su publicación en las tiendas. La decisión entre nativa y multiplataforma la tomamos juntos, en función de las funciones. Los detalles del servicio se describen en la página Desarrollo de aplicaciones móviles.

Medimos el tamaño funcional del desarrollo en puntos de función COSMIC (ISO/IEC 19761), y a partir de él se elaboran la oferta y el calendario. La primera consulta es gratuita, si lo solicita firmamos un acuerdo de confidencialidad (NDA) y, tras la entrega, también nos encargamos de la operación y el mantenimiento. El código fuente y los derechos de uso se rigen por el contrato. Descríbanos su idea en unas frases y póngase en contacto con nosotros.