App para iPhone y Android con un solo servidor

Qué significa «un solo servidor»

Toda app de empresa necesita un sitio donde viven los datos: clientes, pedidos, citas, facturas. Ese sitio es el servidor, y la forma que tienen las apps de hablar con él es una API: un conjunto de direcciones seguras a las que la app pide y envía información.

El error habitual es construir cada pieza por separado: una app con su propia base de datos, una web con otra y el programa de gestión con la suya, sincronizándose a base de exportaciones o, peor, de volver a teclear. Con un solo servidor, la app del iPhone, la de Android, la web y el panel de gestión llaman todas a la misma API, y la API es la única que toca la base de datos.

App iPhoneiOS · .NET MAUI

App AndroidAndroid · .NET MAUI

Webclientes · Blazor

Panel de gestióntu equipo · Blazor

HTTPS · JSON

Servidor único: API RESTASP.NET Core · Azure App Service

• Usuarios y permisos
• Reglas de negocio
• Notificaciones push
• TicketBAI · Verifactu

una sola fuente de datos

Base de datosSQL Server en Azure

Tres formas de tener app para iPhone y Android

Cuando una empresa quiere estar en los dos móviles, estas son las opciones realistas:

Para una pyme, la tercera opción es casi siempre la que mejor envejece: la app no es un proyecto aislado, sino otra puerta de entrada al mismo sistema.

Qué ganas compartiendo servidor

• Los datos son los mismos en todas partes. Lo que el cliente hace en la app aparece al instante en el panel de gestión, y al revés. No hay exportaciones ni dobles registros.
• Un solo usuario para todo. El cliente entra en la app y en la web con la misma cuenta, y los permisos de tu equipo se definen una vez.
• Las reglas se programan una vez. Precios, disponibilidad, descuentos o validaciones viven en el servidor. Si cambian, cambian para todos a la vez, sin publicar una nueva versión de la app.
• La facturación cumple una sola vez. Si la app emite o consulta facturas, el envío a TicketBAI o Verifactu lo hace el servidor, no cada aplicación por su cuenta.
• Notificaciones push desde tu propio sistema. El servidor decide cuándo avisar (una cita, un pedido listo, un documento para firmar) y el aviso llega al iPhone o al Android a través de los servicios de Apple y Google.
• Crecer es más barato. Si mañana necesitas una app para tu equipo de campo, un portal para proveedores o una integración con otro programa, se conectan a la API que ya existe.
• La seguridad está en un solo sitio. La base de datos no está expuesta a internet: solo la API habla con ella, y la API comprueba quién eres y qué puedes ver en cada petición.

Cómo lo hacemos en GestionByte

Trabajamos siempre sobre el ecosistema de Microsoft, con el mismo lenguaje de principio a fin:

• App móvil: .NET MAUI y C#. Un único proyecto que se compila como app nativa para iPhone, iPad y Android, con acceso a cámara, GPS, notificaciones, lector de códigos y trabajo sin conexión.
• Servidor: una API REST en ASP.NET Core desplegada en Azure App Service, con los datos en SQL Server en Azure, servidores en Europa y copias de seguridad diarias.
• Web y panel de gestión: Blazor, también en C#, sobre la misma API.

Usar C# en la app, en el servidor y en la web tiene una ventaja práctica: las reglas y los modelos de datos se escriben una vez y se comparten entre todas las piezas, y el mismo equipo puede tocar cualquier parte sin cambiar de tecnología. Si ya tienes software a medida o un programa de gestión con el que conectar, la API hace de puente.

Un ejemplo real: ByClinics

ByClinics es nuestro propio software de gestión para centros sanitarios, y está construido exactamente así. Sobre un mismo servidor en Azure funcionan:

• El programa de gestión del centro: agenda multicentro, ficha del paciente, caja y facturación conforme a TicketBAI y Verifactu.
• El portal del paciente, donde el paciente reserva, firma y consulta sus documentos.
• La app móvil, con la que el profesional gestiona su agenda desde el teléfono.

Una cita reservada desde el portal aparece en la app del profesional y en la agenda del centro sin que nadie la vuelva a teclear, y llega a la factura con los mismos datos. La app de ByClinics está en proceso de publicación en App Store y Google Play.

Lo que piden App Store y Google Play

Publicar una app no es subir un archivo. Esto es lo que conviene saber desde el principio:

• Las cuentas de desarrollador, a nombre de tu empresa. Igual que el dominio de tu web, la app debe publicarse desde tu cuenta, no desde la de la agencia. Apple cobra una cuota anual por el Apple Developer Program y Google, un pago único por la cuenta de Google Play Console.
• Apple pide un número D-U-N-S para dar de alta una cuenta de organización. Es gratuito, pero puede tardar días: mejor pedirlo al empezar el proyecto.
• Google exige pruebas cerradas a las cuentas personales nuevas antes de publicar en abierto: un grupo mínimo de probadores durante un periodo de días. Las cuentas de organización no tienen este requisito, otro motivo para darte de alta como empresa.
• Las dos tiendas revisan la app. Apple la revisa antes de cada publicación, y ambas pueden rechazarla si falta información, si algo no funciona o si no se explica bien para qué se usan los datos.
• Privacidad declarada. Hay que rellenar la «etiqueta de privacidad» de App Store y la sección de «Seguridad de los datos» de Google Play, y tener una política de privacidad publicada.
• Borrar la cuenta desde la app. Si tu app permite crear una cuenta, las dos tiendas exigen que el usuario pueda solicitar su eliminación. Con un servidor compartido, se implementa una vez en la API.
• Para compilar la versión de iPhone hace falta un Mac. Es un requisito de Apple; nosotros lo tenemos resuelto, pero conviene saberlo si comparas con quien ofrece «apps para iPhone» sin él.

¿Y si no necesito una app?

No toda empresa necesita estar en App Store y Google Play. Si tus clientes van a entrar de vez en cuando a consultar algo o a hacer una reserva, una web bien hecha que funcione en el móvil puede ser suficiente, y te ahorras las tiendas y sus revisiones.

La app compensa cuando hay uso frecuente (tu equipo la abre cada día, tus clientes repiten), cuando necesitas funciones del teléfono (cámara, GPS, lector de códigos, trabajar sin cobertura) o cuando las notificaciones push son parte del servicio. La buena noticia del servidor compartido es que no hay que decidirlo todo al principio: puedes empezar con la web y añadir la app después sobre la misma API.

Qué preparar antes de pedir presupuesto

No hace falta un documento técnico. Con esto podemos darte un presupuesto realista:

1. Quién va a usar la app: tus clientes, tu equipo o ambos.
2. Las tres o cuatro cosas imprescindibles que tiene que hacer el primer día.
3. Qué programas usas ya (gestión, facturación, web) y si la app tiene que hablar con ellos.
4. Si necesita funciones del teléfono: cámara, ubicación, notificaciones, trabajo sin conexión.
5. Si va a cobrar o facturar, porque entonces entra en juego TicketBAI o Verifactu.
6. Plazos: si hay una fecha que no se puede mover.

En GestionByte desarrollamos aplicaciones móviles para empresas de Irún, Donostia y toda Gipuzkoa. Tras una primera conversación sin compromiso te preparamos un presupuesto personalizado.

Preguntas frecuentes