Cómo publico apps de Android como desarrollador en solitario en 2026

Lo más difícil de publicar una app de Android en solitario en 2026 no es el código. Compose está maduro, las herramientas de Play son buenas y hay más bibliotecas de las que nadie tiene tiempo de leer. Lo difícil es terminar. El alcance se desborda, el pulido drena el calendario, y un día te das cuenta de que la app que empezaste hace tres meses es técnicamente más impresionante y sigue sin estar en la tienda.

He publicado dos apps de esta forma, con una tercera en preparación, y por fin me he decidido por un manual que me lleva de la idea a la ficha publicada en unas cuatro a seis semanas. Nada de esto es ingenioso. Todo consiste en decir que no a las cosas.

1. Acota sin piedad — una pantalla, un verbo

Antes de escribir una línea de Kotlin, hago un solo ejercicio: describir la app en una frase con un solo verbo. Granyn — registra un gasto en dos toques. Hydrame — recibe un aviso tranquilo antes de que olvides beber agua. Subly — fotografía una factura y extrae la suscripción en el dispositivo. Si la frase tiene una «y», la app son dos apps.

Esta única frase se convierte en la regla de cada decisión de funcionalidad. ¿Gráficas? Solo si apoyan el verbo. ¿Sincronización en la nube? Solo si no tenerla rompe el verbo. ¿Ajustes? Cuantos menos, mejor. El truco más infravalorado del desarrollo en solitario es no construir cosas.

Si tu presentación en una frase tiene una «y», estás construyendo dos apps.

Una forma real de hacer cumplir esto: escribe la ficha de Play Store — título, descripción corta, el subtítulo de 80 caracteres — antes de escribir código. Si no puedes vender la app en 80 caracteres, tampoco puedes construirla en ocho semanas.

2. Elige un stack diminuto y aburrido

Para Android en 2026, todo mi stack es deliberadamente diminuto:

• Kotlin + Jetpack Compose (sin layouts XML, sin fragments)
• Una sola activity con androidx.navigation.compose
• Room con Flow y funciones suspend para todo lo local
• DataStore (variante preferences) para los ajustes
• WorkManager para el segundo plano, AlarmManager solo donde se requiere exactitud
• Material 3 para los componentes, con un esquema de color personalizado
• Hilt para la inyección de dependencias — pero solo si la app es lo bastante grande como para necesitarlo (Granyn sí, una utilidad diminuta no)

Esa es toda la lista. Sin generadores pesados de KSP, sin capa de red a menos que la app hable de verdad con un servidor, sin kits de UI de terceros. La regla: una nueva dependencia tiene que ganarse su línea en build.gradle.kts con una justificación de una frase que esté dispuesto a escribir.

3. Construye primero las pantallas aburridas

Contraintuitivo pero cierto: construyo las pantallas menos emocionantes antes que la funcionalidad estrella. Estados vacíos, ajustes, onboarding, marcadores de «aún no hay datos». Revelan el modelo de datos y el grafo de navegación más rápido que cualquier otra cosa, y son las pantallas que temerás más adelante si las dejas para el final.

La funcionalidad estrella llega en tercer o cuarto lugar. Para cuando llego a ella, la capa de datos ya está diseñada por las pantallas aburridas que necesitaban leer de ella.

Un andamiaje mínimo que reutilizo en cada proyecto:

@Composable
fun App() {
    val navController = rememberNavController()
    Scaffold(
        bottomBar = { AppBottomBar(navController) },
    ) { inner ->
        NavHost(
            navController = navController,
            startDestination = Routes.Home,
            modifier = Modifier.padding(inner),
        ) {
            composable(Routes.Home) { HomeScreen() }
            composable(Routes.Stats) { StatsScreen() }
            composable(Routes.Settings) { SettingsScreen() }
        }
    }
}

Esa es toda la «arquitectura» de la mitad de mis apps.

4. Fija el modelo de datos pronto, migra para siempre

Las migraciones de esquema son la asesina silenciosa de las apps indie. La solución es pensar en la base de datos como una API pública — una vez en producción, cada cambio es una migración con una prueba. Room lo hace manejable:

@Database(
    entities = [Expense::class, Category::class],
    version = 4,
    autoMigrations = [
        AutoMigration(from = 1, to = 2),
        AutoMigration(from = 2, to = 3, spec = MigrateNotesField::class),
        AutoMigration(from = 3, to = 4),
    ],
    exportSchema = true,
)
abstract class AppDatabase : RoomDatabase() { ... }

Lo más útil que hago: exportSchema = true y hacer commit de esos archivos JSON en git. Entonces una prueba gestionada por Room atrapa las regresiones de esquema antes de que lleguen al dispositivo de un usuario. No puedo contar el número de malas tardes que esto me ha ahorrado.

5. Pruebas manuales en teléfonos reales, automatizadas solo donde importa

Pirámide de pruebas del dev en solitario: un puñado de pruebas unitarias puras para las partes fáciles de probar e imposibles de depurar de otro modo (matemática de divisas, matemática de fechas, la extracción de campos por OCR en Subly). Cero pruebas de UI. Pruebas de humo manuales intensivas en tres teléfonos reales: un Pixel, un Samsung de gama media y un Xiaomi realmente barato. El teléfono barato no es negociable — es el que tus usuarios tienen de verdad.

El Samsung y el Xiaomi sacarán a la luz problemas reales que no aparecen en el emulador. Notificaciones matadas por optimización agresiva de batería, alarmas exactas reprogramadas sin avisar, patrones de vibración que se disparan 200 ms tarde. Si tu app necesita notificaciones fiables (Hydrame las necesita), prueba en un Samsung o lo descubrirás tras el lanzamiento.

6. La ficha de Play Store es la mitad de tu app

Dedica un fin de semana a la ficha de la tienda. El título y la descripción corta son el SEO. Las capturas de pantalla son la conversión. El gráfico de funcionalidad (feature graphic) son los primeros 1,6 segundos que alguien pasa con tu marca.

Una lista de comprobación realista:

• Título con la palabra clave principal (no te pongas mono — «Granyn — Budget & Expense Tracker» gana a «Granyn»)
• Descripción corta (80 caracteres) con el verbo y el único diferenciador
• Descripción larga con tres a cinco párrafos cortos, subtítulos y emojis usados con moderación
• Capturas de pantalla a 1080×2400 o más, siendo la primera captura tu imagen estrella. La mayoría de usuarios nunca deslizan.
• Gráfico de funcionalidad (1024×500). Mantén el texto al mínimo — es un banner, no una valla publicitaria.
• URL de la política de privacidad — obligatoria. Alójala tú mismo (GitHub Pages funciona) para poder editarla sin publicar una versión.
• Clasificación de contenido — rellena el cuestionario con honestidad. Es más rápido de lo que crees.
• Categorización de la app — formulario de Seguridad de datos (Data Safety). Tómatelo en serio; es la versión pública de tu política de privacidad.

El formulario de Seguridad de datos es el que la mayoría se salta a la ligera. Rellénalo como si se lo explicaras a un abogado. Si no puedes marcar «no se recopilan datos», explica exactamente qué tercero (Firebase, AdMob, Play Billing) procesa qué campo. Google lo contrasta con el comportamiento en tiempo de ejecución de forma más estricta cada año.

7. Lanza en silencio, vigila el embudo

Haz un soft-launch en tu país primero. No lo anuncies. Las primeras 50 instalaciones son tu beta — presta atención a los informes de fallos, a los ANR y a la ratio de instalación/desinstalación. Si la retención al día 1 está por debajo del 30 %, arregla el onboarding antes de hacer cualquier marketing.

Lo primero que reviso cada mañana en Play Console durante las dos primeras semanas:

• % de usuarios sin fallos
• Tasa de ANR
• Vitals (activaciones excesivas, fotogramas congelados)
• Reseñas de 1 estrella — lee cada palabra. Son oro.

Luego despliego más amplio — al resto de Europa, después a nivel global. El despliegue por fases (10% → 25% → 50% → 100%) es gratis; úsalo.

8. El aburrido trabajo posterior al lanzamiento

Dos semanas después del lanzamiento empieza el trabajo de verdad: responder reseñas, arreglar los pequeños bugs que encontraron los primeros 500 usuarios y resistir el impulso de empezar la siguiente app. Actualizar una vez por semana con changelogs breves y honestos construye un tipo de confianza que ningún marketing ingenioso puede igualar.

Aquí también es donde el ASO se acumula. Palabras clave en el título y la descripción, un flujo constante de pequeñas actualizaciones y un lento goteo de reseñas orgánicas — nada de ello es glamuroso, todo funciona.

Qué haría diferente la próxima vez

Una lista corta, ya que la retrospectiva es la mejor maestra:

1. Escribe la ficha de Play Store primero. Trátala como la especificación. No es broma.
2. Estados vacíos más grandes desde el primer día. Una pantalla en blanco mata las primeras impresiones; un estado vacío bien pensado te compra una segunda apertura.
3. El onboarding tiene una pantalla. Quizá dos. Si necesitas tres, tienes un problema de UX que arreglar en la app, no un onboarding más largo.
4. Configura Crashlytics el primer día. Sí, incluso para una utilidad diminuta.
5. Política de privacidad alojada en su propio dominio o en GitHub Pages. La actualizarás más a menudo de lo que crees y no quieres una nueva revisión de Play Console por cada retoque.

Todo el manual es poco romántico a propósito. El romanticismo del desarrollo indie es la libertad de publicar; el manual es lo que protege esa libertad de tu propio desbordamiento de alcance.

Si estás en algún punto intermedio de una app de Android a medio construir ahora mismo, lo más útil que puedes hacer esta semana es borrar una funcionalidad. Luego ve a escribir la descripción de Play Store. El lanzamiento está más cerca de lo que crees — la mayor parte de lo que te frena está en tu lado de la pantalla.