Desarrollo de aplicaciones móviles

Apps para iOS y Android que resuelven algo que el navegador no puede: trabajar sin señal, usar la cámara o el GPS, avisar por notificación. Si tu caso no necesita nada de eso, te lo decimos antes de cotizar.

El servicio

Desarrollo de aplicaciones móviles en Ecuador

Construimos apps para iOS y Android conectadas a tu operación, no piezas sueltas. Estas son las seis capacidades por las que vale la pena tener una: si tu proyecto usa dos o más, la app se justifica sola.

Funcionar sin señal

El vendedor en ruta, el técnico en un subsuelo, el inventario en una bodega sin cobertura. La app guarda el trabajo en el teléfono y lo sincroniza cuando vuelve la conexión, con reglas claras para cuando dos personas tocaron lo mismo estando desconectadas.

Ubicación en segundo plano

Seguimiento de flota, rutas de entrega, control de visitas. Es de lo poco que un navegador no puede hacer con la app cerrada, y suele ser la razón técnica que decide el proyecto entero.

Cámara y captura en terreno

Foto de la entrega, lectura de códigos de barras, firma del cliente en pantalla, escaneo de un documento. Funciona rápido y sin pelearse con el navegador, que es lo que hace que la gente lo use de verdad.

Notificaciones que sí llegan

Un pedido nuevo, una alerta de stock, un turno asignado. Llegan aunque la app esté cerrada y sin depender de que alguien tenga abierta una pestaña, que es la diferencia entre enterarse ahora o mañana.

Biometría y seguridad del dispositivo

Entrar con huella o rostro en vez de escribir una contraseña en un teclado pequeño. Sube la seguridad y baja la fricción a la vez, que es raro que ocurra junto.

Hardware conectado

Impresora térmica de tickets, lector de códigos, balanza, terminal de pago. En un negocio de mostrador o en reparto es lo que convierte el teléfono en una herramienta de trabajo y no en una pantalla más.

Una app no es tu web metida en un teléfono

Existen herramientas que empaquetan un sitio y lo publican como aplicación. Sirven para muy pocos casos y traen dos problemas: las tiendas rechazan lo que consideran una web envuelta sin valor propio, y el usuario nota la diferencia en el primer deslizamiento. Si el proyecto no necesita ninguna de las seis capacidades de arriba, la respuesta honesta no es empaquetar: es hacer que tu web funcione bien en el móvil.

Antes de invertir

¿De verdad necesitas una app?

Preferimos perder un proyecto a construir algo que se va a desinstalar. Estas cuatro razones son las que más escuchamos, y ninguna de las cuatro justifica todavía una aplicación.

«La quiero para que la gente me encuentre»

Nadie descubre un negocio buscando en una tienda de aplicaciones. El descubrimiento ocurre en Google y en redes, y para eso el formato que funciona es la web. La app sirve para que vuelva quien ya te conoce.

«Para que vean el catálogo y los precios»

Eso es un sitio web, y además indexable. Pedirle a alguien que instale una aplicación para mirar precios es pedirle un compromiso antes de haberle dado una razón.

«La competencia tiene una»

Es un motivo entendible y una mala base para invertir. La pregunta útil es cuántas veces por semana entraría un cliente tuyo: si la respuesta es «una vez al mes», el ícono va a terminar borrado.

«Para mandar promociones por notificación»

Puede funcionar, pero solo si la app hace algo más. Nadie mantiene instalada una aplicación que únicamente le manda avisos, y la desinstalación es tan barata que el canal se agota rápido.

La pregunta que sí decide

¿Qué necesita hacer tu usuario que un navegador no le permite? Si hay una respuesta concreta —seguir trabajando sin señal, registrar con la cámara en terreno, recibir un aviso con la app cerrada, usar la impresora del mostrador— la app se justifica y el proyecto arranca con un objetivo claro. Si no la hay, todavía no es el momento, y lo vas a agradecer.

Ver desarrollo web, que es a donde lleva la mayoría de estos casos

La decisión técnica

Multiplataforma o nativo

Es la primera bifurcación y la que más mueve el presupuesto. No hay una respuesta buena para todos, pero sí hay una para tu caso, y se decide con cuatro criterios.

Multiplataforma

Nativo

CriterioMultiplataformaNativo
Cuándo convieneLa app hace lo que hacen casi todas: listas, formularios, cámara, mapas, notificaciones, pagos. Es el caso de la enorme mayoría.La app vive del hardware o del rendimiento: procesamiento de video, realidad aumentada, sensores poco comunes, uso intensivo de batería.
Costo de las dos plataformasUna sola base de código para iOS y Android. No es la mitad del costo, pero se acerca bastante: lo que se comparte es la lógica, no todo.Dos desarrollos y dos mantenimientos en paralelo. Cada cambio se hace dos veces, y esa cuenta se repite todos los años.
Acceso a lo nuevo del sistemaLo que sale en iOS o Android llega con algo de retraso, cuando el ecosistema lo soporta. Para la mayoría de las apps eso es irrelevante.Acceso inmediato a lo que Apple o Google acaben de publicar, sin esperar a nadie.
Encontrar quién la mantenga despuésEl grupo de gente que puede tomar el relevo es más grande, en Ecuador y afuera. Importa más de lo que parece el día que cambias de proveedor.Necesitas perfiles de cada plataforma. Más escasos y más caros, sobre todo fuera de Quito y Guayaquil.

Lo que recomendamos casi siempre, y por qué

Multiplataforma, salvo que tu caso caiga claramente en la columna de la derecha. No es por preferencia técnica: es porque el costo real de una app no está en construirla sino en sostenerla, y sostener una base de código cuesta bastante menos que sostener dos. Cuando el proyecto sí necesita nativo lo decimos en la primera reunión, con el motivo concreto, no como norma general.

Lo que nadie cotiza

Publicar en App Store y Google Play

El desarrollo termina y ahí empieza otra cosa que casi ninguna cotización menciona. No es difícil, pero tiene reglas propias y sorprende a quien nunca publicó.

Las cuentas van a tu nombre

La cuenta de desarrollador de Apple y la de Google Play se abren a nombre de tu empresa, no del proveedor. Es la diferencia entre ser dueño de tu app y depender de alguien para actualizarla. Ambas tienen su costo anual o inicial, y la de Apple para empresas exige identificar legalmente a la organización, un trámite que conviene arrancar antes de escribir la primera línea.

La ficha es parte del producto

Nombre, ícono, capturas, descripción y palabras clave deciden cuánta gente instala después de encontrarte. Se preparan como se prepara una página de venta, no la noche anterior a publicar.

Política de privacidad y declaración de datos

Las dos tiendas exigen una política publicada y una declaración de qué datos recoge la app y para qué. Tiene que coincidir con lo que la app hace de verdad: si declaras de menos, te rechazan; si declaras de más, ahuyentas a quien lee la ficha.

Cada actualización pasa por revisión

No es como publicar en la web, donde subes y ya está. Cada versión se revisa, y aunque hoy suele resolverse rápido, hay que planificarlo. Por eso conviene poder cambiar textos y parámetros desde el servidor, sin publicar una versión nueva por cada ajuste.

Los rechazos que más se repiten

  • Es una web empaquetada y no aporta nada propio del teléfono.
  • Pide permisos —ubicación, contactos, cámara— sin explicar para qué los usa.
  • El revisor no puede entrar: la app exige cuenta y nadie le dejó una de prueba.
  • Permite crear una cuenta pero no eliminarla desde la misma app.
  • Cobra por fuera del mecanismo de pago que la tienda exige para ese tipo de contenido.
  • Errores o pantallas vacías en el primer minuto de uso.

Ninguno es fatal: se corrige y se vuelve a enviar. Lo que cuesta es descubrirlos cuando ya prometiste una fecha de lanzamiento, así que los revisamos antes del primer envío y no después del primer rechazo.

La app va a mostrar datos que viven en tu ERP, tu CRM o tu sistema de pedidos. Esa parte es un trabajo en sí mismo, y conviene verlo desde el inicio.

Ver integraciones y APIs

El costo real

Una app no se termina, se sostiene

Es la diferencia más grande entre una app y un sitio web, y la que más presupuestos rompe. El sitio que publicaste hace tres años probablemente sigue funcionando solo; la app, no.

iOS y Android sacan versión todos los años

Cada versión trae cambios que pueden romper algo, y las tiendas exigen compilar contra versiones recientes para aceptar actualizaciones. Una app que nadie toca durante año y medio suele necesitar trabajo solo para volver a publicarse.

Los permisos y las reglas se endurecen

Lo que hoy se aprueba con una explicación breve, mañana exige justificación o deja de estar disponible. Pasó con la ubicación en segundo plano y con el acceso a identificadores del dispositivo, y va a seguir pasando.

Los teléfonos del mercado cambian

Pantallas nuevas, versiones viejas que hay que seguir soportando y una realidad ecuatoriana concreta: buena parte de tus usuarios no tiene el último modelo. Eso hay que probarlo, no suponerlo.

El certificado y las cuentas se renuevan

Las credenciales de publicación caducan. Es el trámite más aburrido del mundo y la causa más tonta de no poder sacar una actualización urgente el día que hace falta.

Cómo lo planteamos nosotros

El presupuesto del proyecto y el de sostenerlo se conversan juntos, desde el inicio y por separado. No es una manera elegante de venderte dos cosas: es que una app lanzada y abandonada desaparece de las tiendas sola, y entonces lo que se pierde no es el mantenimiento, es la inversión completa.

Ver mantenimiento y soporte

Preguntas frecuentes

Lo que nos preguntan sobre apps móviles

Las dudas que aparecen cuando el proyecto pasa de idea a presupuesto.

Se puede empezar con una, y a veces conviene. La pregunta es dónde están tus usuarios: si es una app para tu equipo de campo, mira qué teléfonos tienen y decide con ese dato en la mano. Si es para clientes, en Ecuador el volumen está en Android, aunque el público que más gasta suele estar sobrerrepresentado en iPhone. Construyéndola multiplataforma, sumar la segunda tienda después cuesta bastante menos que hacerla desde cero.

Tú, y conviene dejarlo claro desde el principio porque no siempre se hace así. Las cuentas de desarrollador se abren a nombre de tu empresa y nosotros trabajamos con acceso; si algún día cambias de proveedor, la app se queda contigo, con sus reseñas, sus descargas y su historial. Publicar bajo la cuenta de la agencia es cómodo el primer mes y un problema serio el día que quieres irte.

Apple cobra una suscripción anual y Google un pago único de registro, ambos a nombre de tu empresa y ambos aparte del desarrollo. Son montos menores comparados con el proyecto, pero hay que tenerlos presupuestados y —sobre todo— renovados: una suscripción vencida bloquea las actualizaciones justo cuando necesitas publicar un arreglo. La cuenta de empresa de Apple además pide identificar legalmente a la organización, un trámite que conviene arrancar temprano porque no depende de nosotros.

Hoy suele resolverse en cuestión de horas o pocos días, pero no es un plazo garantizado y conviene no comprometer un lanzamiento contra esa fecha. Lo que sí controlamos es no llegar a revisión con los problemas típicos: permisos sin justificar, falta de una cuenta de prueba para el revisor o una política de privacidad que no coincide con lo que la app recoge. Un rechazo no es grave, pero suma días.

Si tu operación lo necesita, sí, y es una de las razones más sólidas para hacer una app. Se define qué información se guarda en el teléfono, qué acciones se permiten estando desconectado y qué pasa cuando dos personas modificaron lo mismo sin señal. Esa última parte es la que hay que decidir con tu equipo antes de programar, porque es una regla de negocio, no una decisión técnica.

No si se diseña bien. Textos, precios, catálogos, parámetros y buena parte del contenido pueden venir del servidor y actualizarse al instante, sin pasar por revisión. Lo que sí exige versión nueva es cambiar cómo funciona la app. Distinguir una cosa de la otra al diseñarla es lo que evita depender de la tienda para corregir un texto mal escrito.

Se prueba y se ajusta lo que haga falta. Cada versión anual trae cambios que pueden afectar permisos, apariencia o alguna función, y además las tiendas exigen compilar contra versiones recientes para aceptar actualizaciones. Es la razón por la que una app abandonada un par de años no solo se ve vieja: llega un punto en que no se puede actualizar sin trabajo previo.

Si lo que tu usuario hace es mirar, comparar y contactarte, la web bien hecha gana: la encuentra en Google, no tiene que instalar nada y a ti te cuesta menos sostenerla. La app se justifica cuando hace falta algo que el navegador no da —trabajar sin señal, cámara en terreno, avisos con la app cerrada, hardware conectado— o cuando el usuario entra tantas veces por semana que el ícono en la pantalla es un atajo real, no un estorbo.

Cuéntanos qué tendría que hacer tu app

Con saber qué hace tu usuario y dónde lo hace podemos decirte si el proyecto es una app, una web o ninguna de las dos todavía. Esa conversación no cuesta nada y ahorra bastante.

¿Necesitas ayuda?

Escríbenos por WhatsApp