¿Elegir un lenguaje u otro en una app de iOS cambia el presupuesto de la agencia y el mantenimiento?

¿Tienen totalmente claro qué va a hacer la app? ¿Llevará escaneo de código de barras por bluetooth, rastreo GPS en segundo plano o animaciones complejas de cámara? Si solo son operaciones de base de datos estándar como listar productos, confirmar pedidos y enviar notificaciones, quizás no valga la pena pagar los 110.000 TL de diferencia por algo native. Pero si hay integraciones pesadas de hardware, a la larga lo multiplataforma sale más caro.

El año pasado mandamos a hacer una app de pedidos parecida. Pagamos 180.000 TL y fuimos por multiplataforma; el primer año todo perfecto. Pero tras una actualización del sistema operativo, el módulo del lector de códigos con la cámara falló. La agencia dijo que la librería de código abierto que usaron ya no se actualizaba y tenían que hacer el módulo desde cero, pidiéndonos 45.000 TL extra. Más de la mitad del ahorro inicial se nos fue en arreglar un solo fallo.

En el mercado se exagera bastante eso de que "si es native es mejor". Hoy en día, hasta en apps bancarias o de gran e-commerce muchas pantallas corren sobre multiplataforma o interfaces web. Más que el lenguaje que use la agencia, importa la experiencia del equipo en ese lenguaje. Una app native con mala arquitectura genera muchísimos más costes de mantenimiento que una multiplataforma bien estructurada.

Técnicamente, a lo que más le tienen que prestar atención es a la gestión de dependencias. En los lenguajes multiplataforma hay una capa puente entre el núcleo de la app y el sistema operativo. Esa capa puede generar retrasos con cada gran actualización del sistema. Pregúntenle a la agencia cuántos plugins de terceros van a usar aparte de los gestores externos. Cuanto mayor sea el número de dependencias externas, más se multiplicará el coste de futuras actualizaciones.

Cláusulas que deberían añadir al pliego antes de sentarse con la agencia: 1) Se debe verificar que el código fuente cumpla estándares de arquitectura limpia y tenga comentarios completos. 2) Se debe exigir el uso de una versión actualizada y con soporte a largo plazo del lenguaje. 3) Al entregar el proyecto, se debe adjuntar el desglose de licencias y versiones de todas las librerías externas. 4) Se debe preparar una guía de instalación paso a paso para que otro equipo pueda levantar el proyecto si la agencia deja de dar soporte.

nosotros estabamos en el mismo dilema. cuando despues buscamos freelancers vios esto: la mayoria q hace hibrido es gente nueva y sabe a medias de las dos plataformas. cuando exploto todo tuvimos q pasar a native si o si. pues si hay presupuesto y solo van a ios, ir a native limpio desde el principio te da tranquilidad.

Al evaluar las ofertas no deben pensar el alcance del contrato de mantenimiento independientemente del lenguaje del proyecto. Sea cual sea el lenguaje, una cláusula de acuerdo de nivel de servicio (SLA) y la fijación de la cuota mensual de mantenimiento protegerán a su empresa ante posibles salidas de desarrolladores o actualizaciones de versión. Asegúrense también de incluir en el contrato la cesión incondicional de la propiedad del código.

Hace dos años elegimos la opción barata para una app de ventas al por mayor similar. Dijimos "al fin y al cabo es un catálogo simple y pantalla de pedidos". La agencia terminó el trabajo, entregó y a los ocho meses cerró. Le llevamos el código a otro desarrollador. El chico abrió el proyecto y dijo que estaba escrito en un framework facilísimo muy antiguo que ya ni tenía soporte, y que salía más barato hacerlo de cero que arreglarlo. Ese día entendimos que no solo hay que cuestionar el lenguaje, sino la sostenibilidad que hay detrás.

Correcto. Las credenciales de acceso deben crearse a nombre de la empresa, no con cuentas personales.

Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde. Si escribís el resultado aquí, también servirá de ayuda a otros.

Gracias esa era la respuesta que buscaba. Si decidimos sin medir, siempre acabamos en el mismo punto.

Espero que le sea útil.

tieene razón.

Tiene razón. En un sistema heredado, lo más caro son las dependencias desconocidas.

Comprobado por experiencia.

Voy a detallar un poco el aspecto técnico. Si intentas cambiarlo todo a la vez, nada termina de asentarse.

La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación. Yo seguiría por ese camino.

¿Podría ampliar un poco esto? la verdad que todo el mundo haga algo no significa que sea lo correcto.

ánimo.

¿Podría ampliar un poco esto? La oferta más barata suele ser la menos pensada.

Esta es mi opinión, no lo escribo como una verdad absoluta.

Hablaré desde el otro lado yo estoy en el lado del proveedor. Todos los que se apresuran con lenguaje de aplicacion ios se atascan en el mismo punto.

También me gustaría saber si alguien lo hace de otra manera.

No tengo ninguna experiencia en lenguaje de aplicacion ios, por eso pregunto. Intentar hacerlo solo es la vía más cara.

Hay un punto que me genera dudas. Establecer un proceso de solicitud de cambios no ralentiza el trabajo, lo agiliza.

Esta es mi opinión, no lo escribo como una verdad absoluta.