React Native: Un Equipo, Dos Tiendas de Apps

• La mayoría de la lógica empresarial y las pantallas son compartidas; las diferencias de plataforma permanecen en el último tramo.
• Los módulos nativos son la escotilla de escape y necesitan varios cambios en la economía.
• Las actualizaciones sobre el aire pueden enviar correcciones sin revisión de la tienda, dentro de las reglas de la plataforma.
• La piscina de talento es la ventaja práctica: los desarrolladores web pueden construir la aplicación.
• Las mejoras en el marco y la dependencia son un costo anual, no un evento único.
• Elija para ajuste y equipo, no porque sea popular.

Esta guía es lo que un propietario de negocios necesita saber antes de comprometerse: lo que realmente se reutiliza, cuando el código nativo todavía es necesario y lo que eso cuesta, cómo las actualizaciones sobre el aire cambian ciclos de liberación, y el impuesto de actualización que sorprende a las empresas dos años en. Reducida a una oración: el marco es una decisión de contratación y mantenimiento tanto como técnica.

Orientación para propietarios y operadores. Nada aquí es asesoramiento legal o técnico. App store policies, including rules on remotely updating app behaviour, change and should be verified before relying on them.

• La idea. Escriba la aplicación una vez en el mismo idioma que la mayoría de los desarrolladores web ya utilizan, y el marco hace componentes nativos reales en cada plataforma en lugar de una página web en un shell.
• Por qué eso importa. Los botones, listas y navegación son los propios de la plataforma, por lo que la aplicación se siente nativa del usuario, a diferencia del enfoque envuelto-website de hace una década.
• Lo que se comparte. La lógica, el manejo de datos, las llamadas API, la estructura de pantalla y más estilo.
• Lo que no es. Cualquier cosa que toque una capacidad de plataforma el marco no cubre, y los detalles de diseño que cada plataforma espera.
• El punto de madurez. Ha sido utilizado en la producción por grandes aplicaciones de consumo durante años. La pregunta ya no es si funciona, pero si se ajusta a una aplicación específica, detallada en la decisión multiplataforma.

• Lógica empresarial. Reglas, cálculos, validación, estado. Escrito una vez.
• Datos y redes. Llamadas de API, caching, almacenamiento sin conexión, sincronización. Escrito una vez.
• Pantallas y navegación. La estructura de la aplicación, compartida con patrones apropiados para plataformas aplicadas.
• Muy estilizante. Con diferencias deliberadas donde las convenciones de cada plataforma las exigen.
• Lo que está escrito dos veces o una vez por plataforma. Puentes de módulos nativos, manejo de permisos específicos de plataforma, configuración de almacenamiento, configuración de notificación de empuje, y los pequeños ajustes que detienen la sensación de la aplicación extranjera en cualquier plataforma.
• La parte realista. Una gran mayoría de la base de código compartida para una aplicación de negocio típica, menos a medida que la aplicación se acerca al hardware.

Esta es la parte que decide si React Native fue la llamada correcta.

• Lo que son. Código específico de plataforma escrito en el propio idioma de cada plataforma, expuesto a la base de código compartida. El puente para cualquier cosa que el marco no maneja nativamente.
• Cuando se necesitan. Herrajes poco comunes, SDKs especializados, comportamiento de fondo que combate las reglas de la plataforma, procesamiento de rendimiento crítico, y cualquier biblioteca de proveedores que navegue exclusivamente nativo.
• Lo que cuestan. Cada uno es efectivamente dos pequeños proyectos nativos más la integración. Uno o dos es normal. Varios medios la aplicación está luchando contra el marco, y los ahorros se evaporan.
• El ecosistema existente. Muchas necesidades comunes —cámara, mapas, pagos, notificaciones, biometría— ya tienen módulos comunitarios bien mantenidos, que es una gran parte del valor práctico del marco.
• El paso de la diligencia. Antes de comprometer, listar cada capacidad de dispositivo y SDK de terceros la aplicación necesita y comprobar cada uno contra el ecosistema. Las sorpresas encontradas aquí son las que importan.

Una verdadera ventaja que vale la pena comprender con precisión.

• Lo que permite. Envío de cambios al código compartido de la aplicación directamente a las aplicaciones instaladas, sin una presentación o revisión de la tienda.
• Por qué importa. Un error encontrado el viernes se puede fijar el viernes, en lugar de esperar a la revisión. Para empresas con trabajadores de campo en una aplicación crítica, esta es la diferencia entre una tarde y una semana.
• Lo que no cubre. Los cambios que implican código nativo todavía requieren una versión completa de la tienda.
• Las reglas. Las plataformas permiten esto dentro de los límites —en términos generales, fijar y mejorar una aplicación existente en lugar de cambiar sustancialmente lo que hace. Las políticas son específicas y cambian, por lo que deben ser verificadas en lugar de asumirlas.
• La disciplina. Las actualizaciones sobre el aire facilitan el envío sin preocupaciones. El mismo estándar de pruebas debe aplicarse, con la puesta en marcha escalonada y la capacidad de volver a rodar.

La razón por la que muchos negocios aterrizan aquí, y uno legítimo.

• La piscina de talento. Los desarrolladores que trabajan en el marco web dominante pueden crear aplicaciones nativas recreativas con un aprendizaje adicional modesto. Esa piscina es mucho más grande que la piscina de especialistas nativos de iOS o Android.
• Costo y disponibilidad. Fácil de contratar, más fácil de reemplazar y más fácil de encontrar una agencia, que reduce el riesgo de persona clave en una aplicación de larga vida.
• El argumento del equipo web. Una empresa con una aplicación web existente a menudo puede compartir lógica, patrones y personas entre web y móvil.
• La caverna. Alguien en el proyecto todavía necesita entender ambas plataformas. Un equipo sin experiencia nativa eventualmente golpeará un problema nativo y se detendrá.
• La pregunta de continuidad. Quien lo construya, ¿puede otro equipo asumirlo? Esa es una cuestión de contrato y documentación tanto como técnica, detallada en propiedad asentada antes de comenzar el trabajo.

El costo que sorprende a las empresas en el año dos.

• Lo que es. El marco libera regularmente, actualiza las dependencias, las plataformas requieren nuevas versiones de destino, y una aplicación que salta las actualizaciones se hace progresivamente más difícil de actualizar en absoluto.
• Lo que parece en la práctica. Un esfuerzo anual de actualización tocando la versión marco, las dependencias nativas y los requisitos de la tienda. Modest cuando se hace anualmente, doloroso cuando se aplazaron tres años.
• El riesgo de dependencia. Los módulos comunitarios se pueden abandonar. Una aplicación que se basa en un módulo sin mantenimiento para algo caras críticas una reescritura de esa pieza.
• Cómo reducirlo. Preferir módulos bien mantenidos, minimizar el número de dependencias, mantener actualizaciones anuales, y presupuesto para ellos explícitamente, según mantenimiento del día uno.
• El encuadre correcto. Esto no es un defecto nativo de reacción; cada aplicación móvil tiene un costo de mantenimiento. Es un artículo de línea que se deja sin citas.

• Aplicaciones inteligentes para hardware. Procesamiento continuo de cámara, visión en dispositivo, periféricos Bluetooth, integración de escáner resistente. Los nativos manejan estos con menos fricción.
• Interfaz de rendimiento crítica. Gráficos en tiempo real, experiencias de animación, listas de datos muy grandes.
• Aplicaciones monoplataforma. Una aplicación de campo sólo para Android no gana nada de un marco multiplataforma y paga su sobrecarga.
• Integración de la plataforma profunda. Donde widgets, aplicaciones de reloj o características de sistema específicas de plataforma son centrales en lugar de incidental.
• Equipos con habilidades nativas fuertes ya. Usar lo que un equipo es excelente en es mejor que adoptar lo que es popular.

• La respuesta corta. Para la mayoría de las aplicaciones empresariales, cualquiera de los principales marcos multiplataforma funcionará, y la diferencia importa menos que el alcance, la calidad del diseño y la disciplina de mantenimiento.
• ¿Qué debería decidirlo? Las habilidades existentes del equipo, la disponibilidad de módulos para las capacidades específicas necesarias, y quién lo mantendrá.
• Lo que no debería decidirlo. Parámetros no relacionados con la aplicación, popularidad marco, o la preferencia de un desarrollador sin examinar.
• El punto de reversibilidad. Los marcos de conmutación significan una reescritura. La decisión merece la hora que se necesita para comprobar los requisitos contra los ecosistemas.

Cada capacidad de dispositivo y SDK de terceros se enumeran y verifican contra el ecosistema. Necesidades del módulo nativo identificadas y estimadas. Las versiones y dispositivos compatibles del sistema operativo acordaron. El presupuesto de mantenimiento y actualización acordado antes de la construcción, no después.

La lógica compartida, la capa de datos y las pantallas primarias, con convenios de navegación de plataforma respetados en cada uno. Dispositivos reales de ambas plataformas en pruebas desde la primera semana. Infraestructura de actualización sobre el aire con puesta en marcha.

Módulos nativos completados y probados. Ambos almacenan presentaciones preparadas en paralelo, con tiempo presupuestado para el rechazo. Control de Crash y rendimiento por plataforma. La cadencia de actualización y nombrado propietario de mantenimiento en lugar antes del lanzamiento.

Astra Results Marketing comprueba los requisitos contra el ecosistema antes de recomendar un marco: cada capacidad de dispositivo y SDK de terceros listados, necesidades de módulo nativo estimadas sin optimismo, y la recomendación cambió a nativo cuando la aplicación es hardware-heavy o monoplataforma.

El presupuesto de mantenimiento y actualización anual está acordado antes de la construcción en lugar de descubrir en el año dos, las actualizaciones sobre el aire se establecen con la puesta en marcha y la devolución escalonadas, y el código está documentado para que otro equipo pueda asumirlo. Los avances comienzan con una evaluación de capacidad y marco a través de nuestra Desarrollo y diseño UI/UX equipo.

Lecturas relacionadas

• Apps de iPad para Empresas: La Pantalla Grande, Bien Usada
• Swift: iOS Nativo Hecho Como Corresponde
• Crear una App para iPhone: De la Idea a la App Store

Lógica empresarial, manejo de datos y redes, almacenamiento y sincronización sin conexión, estructura de pantalla y más estilo, una gran mayoría de la base de código de una aplicación de negocio típica. Lo que está escrito por plataforma es puentes de módulos nativos, manipulación de permisos, configuración de la tienda, configuración de notificación de empuje, y los ajustes de diseño que detienen la aplicación sintiendo extraño en cualquier plataforma. La parte compartida cae a medida que la aplicación se acerca al hardware.

Código específico de la plataforma expuesto a la base de código compartida, utilizado para hardware poco común, SDKs especializados, comportamiento de fondo que combate las reglas de la plataforma, procesamiento crítico de rendimiento y bibliotecas de proveedores que envían sólo nativo. Uno o dos es normal. Varios medios la aplicación está luchando contra el marco y los ahorros se evaporan, por lo que cada capacidad de dispositivo y SDK de terceros deben ser revisados contra el ecosistema antes de comprometerse.

Los cambios de envío en el código compartido de la aplicación directamente a las aplicaciones instaladas sin una presentación de la tienda, por lo que un error encontrado el viernes se puede fijar el viernes en lugar de esperar a la revisión. Los cambios que implican código nativo todavía necesitan una liberación completa. Las plataformas permiten esto dentro de los límites, fijando y mejorando ampliamente en lugar de cambiar sustancialmente lo que hace la aplicación, y esas políticas son específicas y cambian, por lo que deben ser verificadas en lugar de asumirlas.

En gran medida para contratar. Los desarrolladores que trabajan en el marco web dominante pueden construir aplicaciones nativas React con un aprendizaje adicional modesto, y que la piscina es mucho más grande que los especialistas nativos de iOS o Android — más fácil de contratar, reemplazar y encontrar una agencia para, que reduce el riesgo de persona clave en una aplicación de larga vida. La caveat es que alguien todavía necesita entender ambas plataformas, o el equipo se mantendrá en el primer problema nativo.

El costo anual de mantener la versión marco, las dependencias nativas y los requisitos de almacenamiento actuales. Modest cuando se hace anual, doloroso cuando se aplazan tres años, y ocasionalmente serio cuando un módulo comunitario de la aplicación depende es abandonado. No es un defecto nativo React — cada aplicación móvil lleva mantenimiento — pero es un artículo de línea que se deja de forma rutinaria fuera de las citas.

Aplicaciones de hardware con procesamiento continuo de cámaras, visión en dispositivos, periféricos Bluetooth o escáneres robustos. Interfaz de rendimiento crítica con gráficos en tiempo real o listas de datos muy grandes. Aplicaciones monoplataformas, como una aplicación de campo solo para Android, que no ganan nada y pagan la sobrecarga. Integración de plataforma profunda donde widgets o aplicaciones de reloj son centrales. Y los equipos ya fuertes en nativo, donde el uso de la excelencia existente supera la adopción de lo popular.

¿Listo para saber dónde están las fotos antes de venir? Astra Results Marketing enumera cada capacidad y SDK contra el ecosistema primero, recomienda nativo cuando la aplicación es herraje o monoplataforma, y acepta el presupuesto de actualización antes de la construcción. Astra Results Marketing · 1101 Brickell Ave, Miami, FL 33131 · +1 (786) 321-2866 · [email protected] Encuéntranos. Google · Yelp ▸ LLAMAR AL (786) 321-2866 · ▸ SOLICITE SU CONSULTA