¿Es más difícil iterar rápidamente al desarrollar una aplicación móvil nativa para iOS?

Sí lo es.

La mayoría de las nuevas empresas / empresas tienen un ciclo de lanzamiento de 6 semanas, en comparación con una aplicación web en la que podrían lanzar pequeñas funciones / correcciones de errores semanalmente o incluso a diario.

Los períodos de iteración son más lentos porque se trata de un cliente difícil. Una vez que se libera en manos de las personas, es difícil corregir los errores. Por lo tanto, se necesitan muchas pruebas por adelantado, además, cuando lance, es mejor que tenga algunas buenas características / correcciones de errores, de lo contrario, sus usuarios se molestarán para actualizar cada mes y medio y no verán un progreso claro.

Además, las personas no quieren que se les moleste actualizar cada semana y algunas personas podrían no actualizarse en absoluto. Mientras está en una aplicación web, el usuario no tiene otra opción, y usted tiene más control sobre lo que ve durante cada sesión.

Las pruebas pueden ser mucho más lentas en el lado del cliente. Una de las razones es que, en un cliente móvil, generalmente se trata de un entorno de subprocesos múltiples, donde se puede esperar que los usuarios estén en movimiento, la conexión se caiga, reciba interrupciones de otras llamadas, cambie de aplicación rápidamente, maneje la API del sistema / servicios de hickups. etc. En este entorno, verá todo tipo de errores que tienden a ser únicos y difíciles de reproducir y corregir, lo que hace que el desarrollador. ciclo más largo Estos son problemas con los que las aplicaciones web no tienen que lidiar (Javascript tiene un solo subproceso).

Final: si su aplicación está almacenando una gran cantidad de datos del lado del cliente (utilizando sqlite en gran medida), y el esquema cambia, debe tener cuidado al probar también esa migración de esquema / datos, ya que sus clientes pueden ser antiguos (por ejemplo, usted es lanzamiento de la v. 4, mientras que algunos usuarios todavía pueden estar en la v 3. algunos en 2. y algunos más en la v1.). En una aplicación web, generalmente se pasa de una versión a la siguiente, mientras que en una aplicación móvil algunos usuarios podrían actualizarse desde clientes muy antiguos.

De acuerdo con Ardit en el cambio de esquema de la base de datos local: tenga mucho cuidado al diseñar la base de datos SQLite local, porque una vez que esté disponible y las personas comiencen a incorporarla, las versiones futuras DEBEN ser compatibles con las bases de datos locales de los usuarios nuevos y antiguos.

Esto significa que si hay algún cambio en el esquema, las nuevas versiones deberían (1) poder modificar el esquema automáticamente en las bases de datos locales de los usuarios existentes una vez que se actualicen, o (2) la versión más nueva debe ser responsable de convertir la base de datos de usuarios de esquema antiguo a nuevo esquema migrando datos antiguos a una nueva base de datos. De cualquier manera, es crítico no estropear los datos del usuario.

Además, uno debe tener en cuenta el hecho de que ha creado una aplicación nativa cada vez que actualiza, la libera y luego informa a los usuarios que actualicen, luego tienen que reinstalar la aplicación, lo que presenta un retraso de tiempo significativo con respecto al enfoque de la aplicación web.

A diferencia de Android, no tiene tanto dolor de cabeza por fragmentación, pero aún debe considerarse que con una aplicación nativa necesitará más tiempo para crear una nueva interfaz de usuario que se adapte a las diferencias de iPad / iPhone. Mientras que con una aplicación web, el navegador maneja esto por usted.

También es más vulnerable a los cambios en la API de los servicios que utiliza (pensando en Facebook aquí).