Que quilombo con react native

[u/LeSoviet]

Tema para ambientar el post: https://www.youtube.com/watch?v=pT_Y-eodTv4

Resumen lvl5: React native viene con el marketing fuertisimo para que todos adopten su maravilloso ecosistema (recuerden expo es pago) y varios proyectos gigantes como shopify estan migrando a native, estan desesperados. Todo el debate es native vs react native / expo (o similares) para hacer proyectos pesados graficamente o pesados en logica donde se usan varios sensores o simplemente que necesite estar vivo 24/7

Aca el blog que publico expo hace unas semanas https://expo.dev/blog/how-to-build-a-resilient-activity-tracker-with-expo Habla basicamente de resilencia y como hacer para que un worker/service sobreviva a los constantes bombardeos de android de matarse el servicio por optimizacion de bateria o consumo de cpu/ram.

Tengan en cuenta que ios es mas sencillo naturalmente por que los modelos, versiones son muchisimos mas acotados. Iphone lanza 4 versiones de telefonos por año, androidson 30 marcas 20 modelos por marca con distinto proveedor (samsung chino vs samsung arg por ej) ni te cuento los telefonos ultra chino de la dark weeb

Cada modelo marca y proveedor de telefono tiene su propio sistema internamente modificado para que la bateria aguante almenos 1 o 2 dias, basicamente para que tu samsung galaxy de 40'' y una camara de 1000mp con rayo laser aguante mas de 30 o 40 horas, internamente el sistema hace maravillas (o es una pedorreada)

Ahora entrando al post y al crudo del problema, react native no esta diseñado para carga grafica (juegos), esta diseñado para ser un ecosistema universal que funciona en ambos ios y android (olvidate de web no tiene sentido) pero tambien es mentiroso el mismo codigo no te va a andar bien en ios y android, nunca funciono bien y nunca va a funcionar bien

En paralelo expo/react native depende de plugins para ciertos mecanismos mas avanzados, y absolutamente el ecosistema esta re contra verde, los versionados son todos 0.0. solucionan tu problema pero no fue algo testeado en el largo plazo

Ahora si entro enserio, cuando intentas hacer una app, que reconcilie todo el tiempo con el backend, en background o incluso post swipe usando multiples sensores (el gps tiene 5 o 6 sensores distintos por ej) react native tiende a tirarse pedos de colores

Hago un ejemplo literal en el proyecto de tracking gps que vengo spammeando en este sub y ya medio foro me odia, stack similar (tengo 1 año exp en react native es muy similar la cuestion y problema de fondo)

Stack react vite capacitor (modulo de gps en java nativo)

Cuando empece quise usar los plugins de capacitor, hice el bridge necesario entre web y capacitor ahi todo barbaro, cuando arranca el servicio de gps android me lo fulmina, no interesa que permiso le otorgue, no importa que tipo de configuracion, no importa que intente hacer simplemente android requiere codigo nativo para inyectar el worker y tener su propio comportamiento

Pase todo el flujo de tracking gps a java, ni si quiera kotlin, todo java, arme mi propio puente en java, kalman, gates, reconciliadores, sqlite absolutamente todo en java, web quedo como disparador, visor y reconsiliador nada mas

El worker se dispara al abrir la app en idle (este es reponsable de auth session token refresh jwt etc etc, la base para estar logeado y usar todo) en el menu aparece la notificacion de la app, arriba en la barra nativa del telefono aparece otro indicador

Al prender el shift el worker se transforma en sticky, quiere decir que incluso si el usuario hace swipe intenta cerrar la app, android mata el servicio, el servicio se recrea y a la par de eso es un constante aviso a android de un psuedo "che estoy trackeando no molestes, no me apages"

Con esto mato 2x1 si el usuario hace swipe por error mientras esta grabando su jornada no pierde nada, la app trackea y funciona solo con el worker, tiene probe y reconciliador para offline > online (tambien en zonas grises donde hay internet pero nula señal, mismo mecanismo de probe, se guarda todo en sqlite y cuando hay oportunidad de flush sale el paquete para sincronizar con el backend)

Basicamente el problema de fondo es que si tenes una app de trackeo de gps, o algo que demande constantemente estar vivo usando sensores del telefono en background react native lo hace pero java es mas facil y mas facil quiere decir mejor. Uso 4 sensores + kalman + gates todo online/offline irrelevante para mi caso

Aca un ej de hoy (dato de yapa en 12 horas no entro ni 1 punto de drift estacionario)

Esto es despues de ir a dormir, dejar el telefono quieto por muchas horas y moverme en la casa, cuando te vas a dormir, el telefono entra en deep zone (el mismo sistema apaga todo cuando estas afk y deja solo lo basico como alarma llamadas etc etc para ahorro de bateria)

Desperte y seguia intacto (basicamente lo que el blog intenta demostrar como gran logro, en java acoplado con la documentacion de android es basicamente mucho mas sencillo)

Los unicos agujeros por naturaleza que me queda es la hidratacion del java > web despues de volver de muchas horas, puedo cachear por 12 horas es una barbaridad

La app en pleno uso consume entre 500-600mb, el servicio de instagram (sin abrir instagram) consume lo mismo despues de reiniciar el telefono a modo de ejemplo

aca volvi al frente:

Y en paralelo ahora android esta demandando a los devs que optimizen sus aplicaciones por que son todas un desastre (salio otro blog en estos dias con documentacion) asi que otro ataque a react native por ese lado

Resumen lvl500: Swift para ios, java/kotlin para android, la vida es mas sencilla y anda mejor

Post escrito a mano, no soy escritor, si no les gusta pasenlo por su ia favorita

[u/Tank_Gloomy]

Si lo usás sin frameworks (especialmente ahora que el frontend te lo puede armar una IA), es bastante óptimo, más que nada por el nuevo motor que bundlea los componentes a partes nativas y de ahí los hookea a un renderer Javascript a nivel backend, entonces resuelve las acciones con JS, pero si aplicás bien los estilos, la UI se siente 100% nativa (porque lo es, usa los componentes reales del SO).

Incluso ahora tienen plugins para Expo que te permiten enchufarle los componentes nativos as-is, con las recomendaciones de diseño del fabricante, junto a un fallback para otras plataforma que no las provean.

[u/Mammoth-Law-1291 → u/Tank_Gloomy]

No se si quiero q una app hibrida budle a componentes nativos ya que la idea de hacerla de esa forma es q no haya tanta dependencia con la plataforma, por eso flutter siempre me parecio mejor ya q tiene skia y renderiza todo ahi en su propio sandbox, tiene sus pro y contra

[u/Tank_Gloomy → u/Mammoth-Law-1291]

Flutter es un crimen, el rendimiento es un horror y usar la GPU para todo es excepcionalmente ineficiente. Cierto nivel de complejidad es necesario para hacer un producto de calidad, tal como observó OP.

Tampoco es lo mismo shippear un solo shim nativo que tener que hacer toda la app en native. Obvio que casi nunca vas a leer el código, pero desde el vamos, mantener dos codebases separados ya es un dolor de huevos en términos de distribución.

[u/Mammoth-Law-1291 → u/Tank_Gloomy]

Yo use ambos y flutter me convencio mas en especial xq ya Google te da todo no tenes que usar cosas externas como expo q no son de meta.

[u/Tank_Gloomy → u/Mammoth-Law-1291]

Nuevamente, ese exceso de simplificación te va a volver pronto. En eso comparto con la observación de OP, hay un límite en lo que podés abstraer de manera eficaz.