Rompiendo la Barrera del Navegador (Con Expo)

Entonces, mi nombre es Cedric van Poethe, trabajo en el equipo de DevTooling en Expo, y hoy quiero hablar sobre cómo romper la barrera del navegador. Antes de comenzar, me doy cuenta de que estamos en React Advanced, que es principalmente una conferencia web de React, y estoy aquí hablando sobre React Native.

Así que, aunque podría intentar convencerte de usar Nativo en lugar de web con las estadísticas de uso de móvil vs escritorio, se ha mencionado demasiadas veces ya. Y francamente, las estadísticas pueden ser aburridas. Así que, en su lugar, déjame contarte la historia de Rosebud.

No hace mucho, Chris Bader, cofundador y CEO de Rosebud, escribió una publicación en nuestro blog, explicando todo el proceso de por qué y cómo pasaron de web a Nativo usando Expo. Ahora, la aplicación en sí es solo una aplicación de diario. Está construida para apoyar tu salud mental. Construyeron una aplicación web progresiva en aproximadamente un año. ¿Estoy un poco? Ahí vamos. Ahí vamos. Construyeron una aplicación web progresiva en aproximadamente un año y tuvieron un éxito moderado con más de 100 millones de palabras registradas.

Ahora, después del lanzamiento inicial solo web, se encontraron con algunos puntos problemáticos. La falta de distribución, como una tienda de aplicaciones donde la gente busca Rosebud, pero como no estaban presentes en la tienda de aplicaciones, en realidad estaban perdiendo clientes potenciales. Era difícil volver a involucrar a los clientes debido a la falta de notificaciones push. Y aunque crecieron, el crecimiento fue de alguna manera inferior al esperado, lo que resultó en que su pista se agotara en aproximadamente un año. Y además de eso, el comentario más común que recibieron fue, usaría esto si fuera una aplicación.

Ahora, aunque Chris dudaba en apostar el futuro de la empresa en una aplicación Nativa, afortunadamente se convenció después de hablar con algunos asesores. Así que se fijaron un objetivo, entrar en la aplicación Nativa lo más rápido posible. Ahora, la aplicación web original fue escrita en React. Así que el equipo ya estaba familiarizado con React. Tienen lógica de negocio relacionada con React, como hooks y otra gestión de datos. Así que eligieron Expo como la mejor opción tanto para su objetivo como para lo que ya tenían. Así que se pusieron a trabajar y una aplicación construyeron. La aplicación actualmente tiene una calificación de 4.9 en la tienda de aplicaciones. Así que definitivamente está bien recibida. Pero, ¿qué pasa con el impacto comercial aquí? En solo 14 días desde el lanzamiento, la aplicación por sí sola recaudó más de $20,000 en ingresos. Añadió aproximadamente $6,000 en ingresos recurrentes mensuales. Y tanto la retención de usuarios del día 7 como la conversión de actualización se duplicaron en comparación con su PWA, lo que significa que extendieron su pista para desarrollar su aplicación. Ahora, puedes leer la historia completa de Rosebud en el blog de Expo.

Aquí, Chris Bader explica por qué cambiaron de web a Nativo, qué frameworks estaban bajo consideración, por qué eligieron Expo y, por supuesto, cómo lo hicieron. Ahora, esto es algo que me gusta llamar la barrera del navegador, donde la barrera refleja estar limitado en el crecimiento al ir solo web. Como si te estuvieras perdiendo algunas características Nativas realmente geniales como las notificaciones de deseos y otras cosas.

Aunque esta barrera es diferente para cada negocio, hay equipos superpuestos. Como, tienes que acercarte lo más posible a tus usuarios, como justo en su bolsillo. Y, por supuesto, tienes que mantener a los usuarios comprometidos para construir hábitos de uso de tu aplicación. Ahora, la historia de Rosebud no es única. Y en Expo, pensamos en cómo mejorar todo este camino de brownfield de pasar de web a Nativo. Y creo que encontramos algo genial. Así que pasemos por este proceso juntos.

Conoce Music Finder. Nuestro proyecto de ejemplo para hoy es un catálogo de música súper simple donde puedes encontrar artistas de música, puedes ver algunos audiolibros. Está basado en el ejemplo de música de ShadCN. Así que tal vez ya sea algo familiar. Y por simplicidad para nuestra demo, ya estoy usando Expo Router, solo cosas de web por ahora. Ahora, nuestra aplicación es bastante simple. Tenemos la página de artistas, que es nuestra página predeterminada, por lo que el índice principal. Tenemos nuestra página de libros, que por supuesto contiene los audiolibros. Y tenemos el inicio de sesión. Ahora, cada uno de ellos contiene HTML básico súper simple y algo de Tailwind, todo copiado de ShadCN.

Así que de arriba a abajo, tenemos un elemento contenedor simple. Tenemos algo de navegación de barra de herramientas para el menú y la barra de inicio de sesión. Tenemos un encabezado para decirle al usuario en qué página están. Y, por supuesto, en este caso, tenemos un área de desplazamiento para el álbum. Bueno, en realidad tenemos otro, pero por simplicidad, solo mostré uno. Luego, nuestros libros son casi idénticos, excepto que no estamos usando un área desplazable, estamos usando la cuadrícula de libros. Y el inicio de sesión es ligeramente diferente, pero está usando, por supuesto, un formulario en su lugar. Ahora, si ejecutáramos esto directamente en nativo, se bloquearía de inmediato. Y eso es porque, bueno, React Native no conoce los elementos HTML en absoluto.

Ahora, si realmente queremos hacer que esto funcione en nativos, tenemos que comprometernos a intercambiar todos los elementos HTML por elementos de React Native o alguna otra biblioteca de UI que funcione con ambos React Native y React. Es un compromiso bastante grande si solo quieres probar cosas, ¿verdad? Entonces, en su lugar, podemos usar algo nuevo que llamamos componentes DOM. Y los componentes DOM en realidad ya fueron lanzados en una versión Canary por Evan Bacon. Tanto Evan Bacon como Kudo Chen realmente trabajaron en esto en Expo. Y puede ayudarnos a llegar a una aplicación nativa funcional usando solo esfuerzos mínimos.

Así que, probemos esto en Music Finder. Entonces, volviendo a nuestra página de artistas, lo único que tenemos que hacer para habilitar los componentes DOM aquí es usar el director DOM. Eso es todo. Esto permitirá que todo el componente se renderice de manera algo diferente. Um, ahora, el nombre ya implica que solo se aplica a componentes, ¿verdad? Así que, cambiemos nuestra ruta a un componente real. Así que, aquí, simplemente movimos todo al componente Screen Artist. Y luego actualizamos nuestra ruta para simplemente renderizar ese en su lugar. Volveré a esto sobre por qué es importante. Pero, sí, verás.

Ahora, haciendo lo mismo para los Books y nuestro componente de Login, en realidad tenemos nuestra aplicación web funcionando de manera nativa. Ahora, lo bueno aquí es que la aplicación funciona. Lo malo es que, como puedes ver en la parte superior, el menú y el botón de Login se están renderizando debajo de los elementos de la UI del sistema. Y, por supuesto, eso es navegación no estándar. Así que, iteremos sobre esto. Para solucionar eso, implementemos un patrón de navegación realmente básico, bueno, un patrón de navegación estándar incluido en Expo desde el principio. En este caso, vamos a usar la pantalla de tabs, o el tabs navigator. Ahora, solo queremos renderizar esto en nativo, ya que las tabs también funcionan en web, pero no es estándar en web. Así que, en la parte superior, puedes ver que excluimos todo el material de tabs solo en web. Pero, sí, en nativo, simplemente renderizamos lo que sea.

Ahora, yendo aquí, no queremos renderizar tanto el bottom navigator como el menú en la parte superior. Así que, simplemente lo ocultamos. Podríamos cambiar un poco la detección aquí porque es un poco brusca, pero entiendes el punto ahí abajo. Si no se está ejecutando como un componente DOM, renderiza el top navigator, y si no se está ejecutando como un componente DOM, también muestra el encabezado. Ahora, volviendo a nuestra aplicación, esto se ve mucho mejor. Tenemos navegación nativa, lo que significa que realmente adoptamos los comportamientos específicos de la plataforma.

Como dije, en la parte inferior, podemos cambiar entre las tabs. En el encabezado, en realidad tenemos el título de la pantalla. Ahora, acabas de ver que en realidad tenemos un modal overlay login, que muestra todo el login como un overlay sobre la aplicación, lo cual también es estándar en iOS. Pero no hemos cambiado nada de nuestro código web de React. Entonces, ¿cómo funciona esto? Bueno, para eso, vamos a echar un vistazo bajo el capó. Para entender esto mejor, es más fácil simplemente verlo. Así que, vamos a usar Expo Atlas. Es una herramienta simple que lanzamos a principios de este año, donde puedes realmente echar un vistazo a tu propio bundle. Ahora, en React Native, los bundles son grandes, y se convierten en una especie de caja negra, y Atlas intenta eliminar eso. Así que, buscando nuestro componente de artista, podemos simplemente buscarlo, hacer clic en él, y ahí vamos. En el lado izquierdo, en realidad podemos ver... Bueno, espero que puedas verlo, pero en el lado izquierdo, en realidad puedes ver nuestros elementos HTML, nuestro chat-cn, y a la derecha, puedes ver cómo se está empaquetando dentro de tu aplicación. Ahora, como puedes ver, este no es nuestro código en absoluto. Y puedes notar otra cosa. En realidad está usando un WebView. Ahora, ¿por qué un WebView? Como, ¿no se supone que Native es completamente nativo? Bueno, en algunos casos, en realidad tiene sentido usar un WebView. Pero antes de profundizar en esa parte, revisemos la parte web de ese WebView. Así que, al igual que Metro, Atlas en realidad puede inspeccionar los diferentes objetivos de plataforma. Así que, ahora mismo, solo estamos construyendo para iOS, pero también tenemos tres bundles web diferentes. Ahora, cada uno de ellos es en realidad el componente DOM. Así que, si cambiamos a ese, podemos ver nuestro código siendo renderizado correctamente. En realidad tenemos nuestro código chat-cn y el código web correctamente transpilado a la derecha.

Ahora, ¿podemos usar esto para todo? Es como, ¿podemos usar esto para, no sé, todas nuestras páginas, todas nuestras pantallas? En realidad, sí, pero no lo recomendaría. Así que, acabo de mostrarte cómo puedes, como, ejecutar la parte web en Native con esfuerzos mínimos. Así que, es perfecto en un camino de migración. Pero hay una gran compensación importante, y esa es el rendimiento. Perderás algo del rendimiento. Así que, en una aplicación tradicional de React Native, tenemos algo llamado Hermes, el motor, ¿verdad? Y en realidad no está ejecutando JavaScript en producción. En su lugar, está usando alguna forma de código de instrucción de JavaScript, que se llama bytecode de Hermes. Y ayuda a que la aplicación sea, como, incluso si tiene 10 MB, 20 MB, arrancar casi instantáneamente y ejecutarse casi instantáneamente, lo cual es importante en las aplicaciones de React Native.

Pero las colas web no están ejecutando Hermes. Entonces, ¿qué tipo de efecto tenemos allí? Así que, a la izquierda, puedes ver nuestra aplicación de Componente DOM. Funciona, pero cuando cambiamos de página o cuando cargamos una página por primera vez, puedes ver un poco de, bueno, contenido estilizado amplio, contenido no estilizado amplio. Aunque puedes ocultar algo de eso aplicando, como, alguna cara o precargando las pantallas, realmente no puedes eliminarlo. Por eso, como, una de las cosas de los Componentes DOM es que no deberías usarlos para todo. Ahora, si comparamos esto con nuestra aplicación completamente convertida de React Native, puedes ver que nuestra aplicación de React Native es prácticamente instantánea. Concedido, no incluye ninguna obtención de datos, pero incluso sin eso, querrás que la parte de la interfaz de usuario de tu aplicación pueda ejecutarse instantáneamente. Y, por supuesto, como, si acabas de notar, si vas completamente nativo, también puedes implementar características de plataforma muy específicas, como la pulsación larga. Siempre que mantienes presionada cualquiera de las imágenes, en realidad obtienes un menú contextual. Esto se hace con Zego, y es súper fácil de implementar si usas React Native. Ahora, esto no es posible en la web. Y si los miras uno al lado del otro, puedes ver cuál es más rápido y cuál no. Ahora, es importante entender dónde y cómo puedes usar los Componentes DOM. Puedes comenzar solo con Componentes DOM para todo para comenzar lo más rápido posible, pero intenta iterar y, bueno, mejorar la aplicación a medida que avanzas.

Ahora, como dije, los Componentes DOM en realidad ya se han lanzado como una característica canaria. Y afortunadamente, algunos de nuestros usuarios fueron lo suficientemente aventureros como para probar una versión canaria. Ahora, por ejemplo, Thor de Superbase en realidad creó algo súper ingenioso. Creó una guía completa sobre cómo usar Componentes DOM para autoalojar tus propios mapas usando Map Libre, ProtoMaps y Superbase. Ahora, de nuevo, es súper difícil comparar en términos de mapas en comparación con Apple y Google porque es un concepto tan complejo. Pero en realidad hizo un gran trabajo aquí. Y el hecho de que en realidad esté usando la API Web o el SDK Web para Map Libre y que en realidad funcione en una aplicación nativa es bastante impresionante para mí. Ahora, otra característica realmente genial es esta, o ejemplo, donde Devloop en realidad creó una aplicación usando React Swappy.

Algunos de ustedes podrían saberlo. Pero esto demuestra claramente que tienes la capacidad de, bueno, usar cualquiera de las bibliotecas web de React en nativo como una primera implementación. E incluso los gestos aquí funcionan bastante bien para una vista web.

Ahora, este es el que más me gusta porque aquí, Raphael Moreau nos mostró cómo usar React Photosware viewer en nativo. Ahora, renderizar en nativo es realmente posible implementarlo de forma nativa con WebGPU de William Cantillon y muchas otras bibliotecas. Pero si vas a nativo, generalmente significa que tienes que implementar algo mucho más complejo. Mientras que en este caso, es literalmente solo esto, donde puedes simplemente usar cualquiera de las bibliotecas web, simplemente insertarlo en un componente DOM y luego probarlo. Y como puedes ver aquí, él está pasando datos de props hacia el componente DOM.

Ahora, puedes hacer eso, pero asegúrate de usar solo datos serializables porque en realidad estamos conectando dos entornos diferentes. Estamos conectando el contexto nativo y el contexto web. Así que para resumir, con componentes DOM, puedes realmente comenzar a usar todo el ecosistema, incluso en nativo. Así que no solo React Native, también bibliotecas de React. Puede usarse como un camino de migración incremental de pasar de web a nativo. Y como dije, puedes interactuar a través de props, pero ten cuidado con esto porque, de nuevo, hay dos contextos diferentes aquí. No puedes pasar instancias de clase de un contexto de entorno diferente a otro, donde estamos usando incluso un motor completamente diferente. Ahora, puedes realmente usar esto hoy ya que Xpressdk52 se lanzó como beta ayer por la noche. Y en Xpressdk52, estamos lanzando componentes DOM como una característica experimental. Ahora, si quieres probarlo hoy en tu teléfono, echa un vistazo a la aplicación de Evan. Como dije, Evan anuncia en React Universe, creó una aplicación donde todo es un componente DOM, pero es ultra poly. Puedes escanearlo desde TestFlight y realmente ejecutarlo en tu aplicación, o puedes escanear el sitio web para que puedas ponerlos uno al lado del otro. El código de este es de código abierto, de hecho, así que encuéntralo tú mismo o ven a saludarme.

Eso es todo lo que tengo por hoy. Mi nombre es Cedric van Putten y hoy rompimos la barrera del navegador usando componentes DOM. Fue una gran presentación. Es tan maravilloso cada año... Ya no trabajo activamente en React Native. Aproximadamente una vez al año veo una charla de expo en una conferencia y es simplemente increíble lo que ustedes siguen produciendo año tras año. Parece un verdadero tipo de compromiso con una misión continua que sigue teniendo sentido. Cada versión de SDK está llena de nuevos tipos de cosas, como SDK 52 es la más grande hasta ahora, creo. Contiene una vista previa temprana de RSC incluso, vista previa para desarrolladores, no puedes usarlo en producción todavía, pero estamos trabajando duro en eso.

Y por supuesto, incluye conceptos muy interesantes como componentes DOM. Así que sí. Genial. Bueno, mencionaste RSC y creo que mientras veía tu charla, parecía que como paradigma es relativamente similar a los componentes de servidor, incluso advertir a las personas que solo pasen props serializables a través de la frontera. Y es muy similar a cómo ahora pensamos sobre la frontera del componente en los componentes de servidor de React. Así que dos preguntas sobre eso. Una, ¿hay algún tipo de conexión en términos de la implementación de la API? Y también, ¿podemos de alguna manera intercalar componentes nativos y DOM de la misma manera que podemos hacer con los componentes de servidor donde puedes pasar un componente de servidor como un hijo a un componente cliente, etcétera?

Sí, o sea, el diseño de la API está algo relacionado con RSC, ¿verdad? Donde tenemos una directiva para habilitar una propiedad diferente como un comportamiento diferente del componente en sí. Así que con RSC, tú, bueno, en realidad, estamos haciendo lo mismo, ¿verdad? Donde tenemos un contexto nativo, bueno, en este caso, el servidor. Y lo ejecutamos como conectamos o unimos dos cosas que están completamente separadas. Pero lo hacemos para que todo sea React. Así que puedes simplemente pasar props, puedes pasar algunas otras cosas y funciona en ambas plataformas. Ahora es algo similar. Quiero decir, ambos son una característica avanzada de empaquetado que estamos agregando a Metro. No diría que están usando exactamente el mismo código, pero están relacionados en ese sentido, sí.

Genial, y supongo que tenía curiosidad, como, ¿sería posible en el futuro ir en la otra dirección donde podrías simplemente, ya sabes, tener la mayor parte de tu aplicación siendo renderizada como un componente DOM y luego simplemente intercalar una especie de componente nativo allí? Bueno, quiero decir, hay, con cada enfoque hay compensaciones, ¿verdad? Así que en este caso, la vista web es algo lenta. Como si la usas a pantalla completa, puedes hacer trucos como cargar anticipadamente todas las pestañas en tu aplicación. Así que el tiempo de carga cuando cambias de pantalla es casi nada. Y luego si agregas una buena transición de una a otra pantalla, se desvanece por completo. Así que diría que no es necesariamente, ¿puedes hacerlo? Es como, por supuesto, probablemente puedas, pero es mejor simplemente probarlo e iterar sobre ello para ver qué tan bien puedes lograrlo. Esa es también la razón por la que mostramos la aplicación de componente DOM o DOM comp.

Genial. Eso tiene sentido. La segunda pregunta aquí, la pregunta más valorada, ya sabes, esto va un poco sobre lo que dijiste que, ya sabes, esta característica depende de, ya sabes, una integración avanzada del empaquetador que tienes en Metro. Y, ya sabes, la mayoría de los desarrolladores web hoy en día, ya sabes, aún no están usando el enrutador de Expo, ya sabes, como su solución de enrutamiento. Así que, ya sabes, si alguien tiene una, ya sabes, una aplicación de tamaño medio de Next.js y quiere ir y, ya sabes, portarla a móvil, ¿qué pasos implicaría pasar de Next.js por ejemplo? Así que Next.js no funciona en absoluto en nativo, ¿verdad? Como no solo el marco en sí, sino que el empaquetador es diferente. Así que hay muchas diferencias, como que no es compatible Next.js y Expo, pero los componentes que escribes en Next.js deberían funcionar en un componente DOM de Expo. Así que el único paso que tienes que hacer primero es pasar de una aplicación de enrutador de Next o como enrutador de aplicación de Next a una estructura de enrutador de Expo. Una vez que tengas eso, puedes llenar los espacios en blanco, como hice en mi ejemplo, donde comencé con solo tres páginas separadas y luego agregué los diseños para unirlas bien en nativo.

Yo diría que esos son los mismos pasos que tienes que seguir para pasar de una aplicación Next a una aplicación nativa adecuada. Puede ser desalentador para una aplicación realmente grande, pero si te mueves pantalla por pantalla y si las ajustas pantalla por pantalla o como grupo por grupo, deberías llegar allí bastante rápido.

Sí, ¿hay como una historia de migración incremental desde, digamos, el enrutador de Next a Expo router, incluso en la web? ¿Puedes hacerlo poco a poco? Puedes hacerlo, pero tienes que traducirlo a la estructura de rutas de Expo router. No hay una herramienta automatizada que puedas usar para cambiar entre ellos. E incluso entonces todavía tienes que iterar y pulirlos todos al mismo tiempo. Eso tiene sentido.

Bien, así que tenemos la siguiente pregunta más valorada aquí, es ¿puedes interactuar con APIs nativas desde componentes DOM como retroalimentación háptica o notificaciones push? De hecho, sí. Y eso es lo que Evan también está demostrando en la aplicación DOM-COM, donde es un poco difícil tener interactividad entre componentes si no puedes pasar funciones o no puedes pasar algo que sea invocable, ¿verdad? Así que tanto Kudo como Evan trabajaron en algo loco donde en realidad también conectamos funciones. Así que lo que puedes hacer es pasar una función al componente DOM, que está disponible en una cola web. Y luego, cuando tengas hápticos o cuando quieras hacer una notificación push, puedes simplemente llamar a la función que realmente desencadena eso en un sitio nativo. Así que a través de eso, puedes engancharte a lo que necesites. Si tienes demasiadas cosas a la vez, puede ser un poco incómodo, pero si lo usas sabiamente, debería ser bastante sencillo. Genial. Sí, esa fue una buena pregunta. Y tuve una buena respuesta. Me sorprendió escuchar la respuesta. Pensé que iba a ser un no. No, está ahí. Está ahí. Muy genial.

Bien, así que la siguiente pregunta es ¿pueden los componentes DOM ser usados en una aplicación React Native existente que no sea de Expo? Siempre recibimos esta pregunta y es una buena pregunta. Como, ¿puede esta característica del framework de Expo ser usada sin Expo? Y la respuesta corta es no. Es el framework. Lo que tienes que entender con Expo es que también expandimos el conjunto de características de Metro. Como tuvimos la resolución rápida al principio. Tuvimos todo tipo de cosas adicionales alrededor de la resolución para acelerar las cosas bastante. Afortunadamente, eso se integró bastante rápido. Pero estas características de empaquetado muy avanzadas como RSE, componentes DOM, simplemente no están disponibles sin Expo ya que es la funcionalidad añadida sobre Metro. Concedido, quiero decir, no voy a decir nunca que no se integrará, pero por ahora no puedes. Genial, gracias.

Bien, nos quedan cuatro minutos y todavía tenemos tres preguntas aquí. Veamos si podemos responder a todas.

Bien. Así que la pregunta principal es ¿recomendarías esto para un proyecto nuevo en lugar de usar React Native, sabes, para hacer una especie de aplicación mixta web y nativa? Yo diría que depende del equipo. Si tu equipo es capaz de usar web, adelante. Quiero decir, no hay desventajas en comenzar de esa manera y luego volver a lo nativo a medida que avanzas. Obtendrás una aplicación mucho más rápido, especialmente si tu equipo ya está familiarizado con la web. Así que sí, no debería haber desventajas.

Y creo que esta es una pregunta relacionada de alguna manera también desde el punto de vista de la implementación es si los componentes DOM de Expo están relacionados con React Strict DOM de alguna manera. ¿Cuáles son las desventajas entre los dos enfoques? Así que React Strict DOM es como la próxima versión de React Native web. Y React Native web es básicamente la capa entre cómo escribes tus componentes o cómo escribes tu UI y cómo se traduce en web y nativo. Ahora no está relacionado, como RSD es separado, pero es como la parte que falta que podría ayudarte a llegar a React Native mucho más rápido. Y personalmente, estoy muy emocionado con RSD. Todavía necesita un poco de trabajo, pero hay cosas prometedoras allí.

Genial. Gracias. Y la última pregunta que tenemos por ahora es, y sabes, ampliamos un poco, como para hablar de React Native, es, sabes, ¿por qué en este caso, sabes, comienzas desde productos web existentes, sabes, por qué ir a una plataforma React Native en lugar de envolver el PWA con algo como Ionic o Tory v2? Bueno, mostré algo muy específico como la pulsación larga en nativo, ¿verdad? Ese tipo de cosas no son posibles a menos que las implementes completamente tú mismo. Ahora, no quieres hacer eso cuando Apple anunció como todos los nuevos conceptos alrededor del navegador de barra de pestañas, donde en tabletas, todo el navegador puede ser desacoplado. Quiero decir, tenemos a alguien en la audiencia, alguien en la audiencia aquí, que realmente implementó eso parcialmente en el lado nativo. Así que ve a hablar con él. Pero si usas WebView para toda tu aplicación, ese tipo de cosas no son posibles. Así que siempre nos quedamos atrás. Y es como mi problema personal con herramientas como Flutter o Ionic es que su estructura, su arquitectura te impide potenciar lo nativo, algo que React Native no hace. Genial, bueno, eso fue todo el tiempo que tenemos.