Spectra

Clientes móviles nativos para el panel de hosting Spectra - apps separadas para Android (Kotlin) e iOS (Swift). Gestión completa de servidores desde el teléfono: estados, consola, facturación y notificaciones. No un sitio empaquetado, sino una interfaz realmente nativa en cada plataforma.

Spectra
TL;DR

Spectra es un panel de hosting para servidores de juego. La versión móvil no es un sitio encerrado en una WebView, sino dos aplicaciones nativas separadas: Android en Kotlin e iOS en Swift. Desde el teléfono haces lo que haces en el panel del navegador - consultar el estado, abrir la consola, pagar una factura. Las notificaciones push te dicen que el servidor se cayó antes de que lo haga un jugador.

Introducción

En la web, Spectra es el centro de mando completo del cliente: pedido de servidores, consola, archivos, estadísticas, facturación. Todo lo que un administrador necesita para mantener en pie y en funcionamiento su servidor de Minecraft u otro juego. El problema es que ese centro de mando está encadenado al escritorio.

Un administrador no trabaja de nueve a cinco frente a un monitor. Una caída no consulta el calendario - llega en el autobús, en el almuerzo, en mitad de la noche, cuando el servidor está justo lleno de jugadores. Entonces solo importa una cosa: qué tan rápido el teléfono en tu bolsillo te lleva a un reinicio y a una consola antes de que los jugadores empiecen a marcharse.

Por eso construimos la versión móvil de Spectra como una forma de pleno derecho de manejar la plataforma, no como un añadido al panel web. En la práctica son dos aplicaciones separadas escritas en el lenguaje nativo de cada plataforma - Android en Kotlin, iOS en Swift - que se dirigen exactamente a la misma API que el panel del navegador.

Una caída no pregunta dónde estás

Cuando un servidor se cae en plena hora punta, cada minuto son jugadores que no vuelven. En ese momento no arrancas un portátil, no inicias sesión en el panel web, no buscas una pestaña. Sacas el teléfono que ya tienes en la mano y quieres estar en la consola en dos toques.

Eso cambia lo que la aplicación tiene que ser. Una herramienta a la que recurres bajo el estrés de una caída tiene que arrancar al instante, responder sin tirones y llevar al objetivo sin vagar por los menús. Cada segundo de retraso entre tocar el icono y ver la consola es un segundo en que el servidor sigue caído.

➜
Consejo

La WebView no es mala por principio - para una pantalla que miras una vez por trimestre puede ser una elección razonable. La regla que seguimos en Spectra: cuanto más a menudo y más bajo presión usas una pantalla, más fuerte es el argumento a favor de lo nativo. La consola y un reinicio del servidor están justo de ese lado.

Por qué no una página en un marco

La vía más simple y barata hacia el móvil es envolver el panel web existente en una WebView y enviarlo a la tienda como "aplicación". El código ya está, basta con rodearlo de una ventana. Pero el atajo se delata a cada paso: la aplicación arranca despacio, porque primero tiene que despertar el motor del navegador, pierde los gestos nativos, notifica mal o nada y parece una página en un marco delgado.

Para un panel que tocas de vez en cuando sería un compromiso aceptable. Para una herramienta de rescate no. Así que tomamos el camino más difícil: una interfaz propia y nativa en cada plataforma, que se ve y se comporta como una aplicación de su sistema, no la misma maqueta aplastada en Android e iOS a la vez.

Una página en un marco frente a lo nativo

RasgoWebViewNativo (Spectra)
Arranque de la appespera al motor del navegadorinstantáneo
Gestos y desplazamientoa menudo con tironesfluidos, a nivel de sistema
Notificaciones pushlimitadascompletas, con un deep link
Acceso al sistematras un muro de sandboxnativo
Aspectouna página en un marcouna aplicación de su plataforma

Tiempo hasta la primera pantalla útil (ilustrativo, ms)

WebView
2600
Nativo
400

Dos lenguajes, una API

Lo que ambas aplicaciones comparten es lo que hay debajo: la API y el modelo de datos. Lo que difiere es la interfaz, porque Android e iOS tienen sus propios patrones de navegación, su propio lenguaje de gestos y sus propias expectativas sobre cómo debe comportarse una aplicación. Forzar una única interfaz común en ambos acaba haciéndola parecer ajena en ambos.

El punto clave es que el cliente móvil habla exactamente con la misma API que el panel web. No hay una "versión móvil recortada" con posibilidades reducidas - un reinicio del servidor desde el teléfono pasa por el mismo contrato que un reinicio desde el navegador. Así, en el teléfono haces de verdad lo que haces en el escritorio, y no un subconjunto elegido.

1
Dos aplicaciones nativas

Android en Kotlin, iOS en Swift; API y modelo de datos comunes, una interfaz propia ajustada a los patrones de cada plataforma.

2
Consola en vivo

un flujo de los registros del servidor y la entrada de comandos desde el teléfono, con un teclado que no tapa la mitad de lo que escribes.

3
Estado y acciones de alimentación

iniciar, detener, reiniciar y una vista del uso de recursos sin recurrir al escritorio.

4
Facturación

vista de facturas y pago, para que el servidor no caduque solo porque estabas fuera de casa.

5
Notificaciones push

el servidor está caído, el periodo de facturación termina, una copia de seguridad falló; tocas y aterrizas en la pantalla correcta.

Un push que lleva directo a la consola

Las notificaciones no son un adorno sino el núcleo de toda la idea para el móvil. Son ellas las que te hacen enterarte de una caída antes que el primer jugador. Sin ellas la aplicación sería una ventana pasiva que tienes que abrir tú mismo en el momento adecuado - y el momento adecuado suele ser aquel en que no sabes nada.

Un evento del backend tiene una forma simple e inequívoca, y es esa forma la que decide dónde te deja un toque en la notificación. El deep link no lleva a una pantalla de inicio sino directo a la consola del servidor concreto que tiene un problema. Sin búsquedas, sin navegación - del sonido del teléfono al punto donde puedes actuar hay un solo toque.

push-event.json · json
{
  "type": "server.down",
  "serverId": "srv_4192",
  "serverName": "SkyPvP",
  "severity": "critical",
  "deepLink": "spectra://servers/srv_4192/console",
  "at": "2026-09-10T02:14:09Z"
}
2
aplicaciones nativas separadas (Android, iOS)
1
API común para web y móvil
< 1 s
de una notificación push a la consola del servidor

Un servidor salvado desde una parada de autobús

El resultado es una herramienta que de verdad rescata un servidor desde el teléfono, no una vía de emergencia que usas una vez y vuelves al portátil. El administrador recibe el panel completo en el teléfono: estado, consola, acciones de alimentación, facturación - y se entera de un problema en el momento en que ocurre, no cuando mira por casualidad.

Del lado de Spectra la ganancia es igual de concreta: el móvil no es un producto separado que vive su propia vida, sino otro cliente de la misma API. Una nueva posibilidad en el backend es alcanzable desde el teléfono igual que desde el navegador, sin reescribir la lógica una segunda y una tercera vez. Los números de arriba son ilustrativos, pero la dirección no.

Una caída llegará de todos modos en el peor momento. La cuestión era que el peor momento ya no significara impotencia - solo un teléfono sacado del bolsillo.

Más proyectos

Más trabajos de la misma categoría - mira cómo abordamos retos parecidos.

¿Tiene un proyecto similar?

Escríbenos - el presupuesto es gratuito y llega en una hora.