La agencia dijo "Flutter para iOS y Android" — ¿me ata esta decisión a futuro?

Con las actualizaciones de iOS a veces hay pequeñísimos desajustes visuales si cambia el motor de renderizado. Incluye sí o sí una cláusula para que la agencia dé soporte de compatibilidad durante al menos 1 año cuando salgan versiones principales de iOS.

El año pasado lanzamos nuestra app de seguimiento logístico en Flutter. En vez de dos equipos nativos, gastamos 210.000 TL con uno solo. Tenemos 12.000 usuarios activos y solo 2 quejas fueron por lag en la interfaz, y era en móviles viejos.

Muchas agencias dicen "un solo código para dos plataformas" para bajar costes, pero ni miran las guías de interfaz de iOS. Si sale una app en iOS que parece de Android, los usuarios de iPhone te van a acribillar a malas reseñas.

Pídeles al menos tres apps en Flutter que ya tengan publicadas en la App Store. Descárgalas en tu iPhone y prueba la fluidez del scroll la respuesta del teclado y las animaciones de transición.

¿Tus técnicos trabajarán offline? ¿Les has preguntado cómo estructurarán la sincronización y el almacenamiento local? El cuello de botella suele ser la sincro de la base de datos local, no la interfaz.

llevamos dos años usándolo y cero problemas. bueno si lo hiciéramos nativo ese presupuesto se duplicaba como mínimo, para empezar no hace falta para nada.

Ed: ya se preguntó abajo, dejé la respuesta en el segundo mensaje.

Si luego tienes que pasar a nativo no significa que la app haya fracasado al contrario significa que el negocio ha crecido mucho. Para cuando llegue ese día tendrás músculo para financiar el código nuevo, ahora céntrate en ganar velocidad.

Al pasar a nativo tiras el código de la interfaz, pero la arquitectura del backend la conservas tal cual; 280.000 TL es un presupuesto de prueba superrazonable para ese riesgo.

Hablaré desde el otro lado, yo estoy en el lado del proveedor. La respuesta varía mucho según el sector, no hay una regla general.

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

estoy totalmente de acuerdo y todo lo que no está por escrito, ambas pates lo recordarán de forma distinta en el futuro.

eso es todo, disculpa si me he extendido demasiado.

Lo probaré.

Tienes razón, yo también pasé por lo mismo. El calendario de pagos debe vincularse a las fases del proyecto, no a fechas fijas.

Si la propiedad del código no está en el contrato, al irte no tienes poder de negociación. Yo seguiría por ese camino.

Aquí hay una trampa no puedo dejar de mencionarla. la verdad el error cometido por desarrollo ios con flutter suele ser reversible, pero caro.

Es correcto en general, pero falta un detalle. Si es la primera vez que lo hacéis, empezad poco a poco, la escala llegará después.

Yo seguiría por ese camino.

De acuerdo, incluso me gustaría recalcarlo. Intentar hacerlo solo es la vía más cara.

Comprobado por experiencia.

A mí me pasó justo al revés, por eso escribo. Si es la primera vez que lo hacéis, empezad poco a poco, la escala llegará después.

La oferta más barata suele ser la menos pensada.

Me pasó lo mismo. o sea no tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

Al tomar decisiones, escribe también el peor escenario, no solo el mejor... o sea eso es todo disculpa si me he extendido demasiado.

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

Si el alcance crece, debe crecer el plazo o el presupuesto. No hay tercera opción. Yo seguiría por ese camino.