El desarrollo de apps Android empieza cada vez antes de escribir la primera función, con decisiones sobre distribución, identidad del desarrollador, facturación y alcance del soporte.
Google está avanzando con la verificación de desarrolladores de Android y, a partir del 30 de septiembre de 2026, algunos países y tiendas participantes exigirán que las apps estén registradas por desarrolladores verificados para poder instalarse en dispositivos Android certificados.
El modelo de tarifas de Google Play también cambia por etapas, con Japón y Corea del Sur programados para el nuevo marco de tarifa de servicio y opciones de facturación desde el 31 de diciembre de 2026.
Esto no afecta solo a las grandes empresas de apps.
Las apps por encargo, las herramientas internas, los pequeños productos SaaS y los prototipos también necesitan decidir pronto qué cuenta de desarrollador será propietaria de la app, qué ruta de facturación se usará y si la distribución externa seguirá formando parte del plan.
Por qué la distribución ya no puede quedar para el final
Muchos proyectos Android solían pasar del desarrollo de funciones a la publicación en Google Play como una tarea final.
Ese enfoque se vuelve frágil cuando la verificación del desarrollador, el registro del nombre del paquete, las claves de firma, las tiendas externas y las descargas directas influyen en la ruta de lanzamiento.
Los materiales de Google describen dos pasos principales para la verificación: confirmar la identidad del desarrollador y registrar los nombres de paquete de las apps.
Las organizaciones también pueden necesitar verificar datos corporativos y su sitio web.
Por eso, el propietario de la app, la empresa operadora y el proveedor de desarrollo deben decidir quién asume la responsabilidad antes de iniciar el trabajo de publicación.
Dejar esa decisión para el final puede convertir el acceso a la cuenta, la revisión, la transferencia de la app y la configuración de pagos en bloqueos evitables.
Cómo cambia el proceso de desarrollo con la verificación
Google afirma que las nuevas protecciones de verificación comenzarán el 30 de septiembre de 2026 en Brasil, Indonesia, Singapur y Tailandia, en Google Play y varias tiendas participantes.
El requisito se ampliará a nivel global en 2027 y después.
El cambio no se limita a las apps distribuidas por Google Play.
La página de verificación de desarrolladores de Google también dirige a quienes distribuyen solo fuera de Google Play a verificar su identidad y registrar nombres de paquete mediante Android Developer Console.
Al mismo tiempo, Google ha descrito cuentas de distribución limitada para estudiantes, aficionados y personas en aprendizaje, que permiten compartir apps hasta en 20 dispositivos sin documento oficial ni tarifa de registro.
Google también afirma que las apps no registradas podrán instalarse mediante ADB o un flujo avanzado para usuarios expertos, pero esa ruta tiene suficiente fricción como para no tratarla como el canal normal de distribución masiva.
La facturación debe diseñarse dentro del producto
Google Play está separando su tarifa de servicio de la tarifa de facturación mediante un despliegue gradual.
La nueva estructura empieza en Estados Unidos, Reino Unido y el Espacio Económico Europeo el 30 de junio de 2026, y está programada para Japón y Corea del Sur el 31 de diciembre de 2026.
La documentación de ayuda de Google explica que las tarifas dependen en parte de si una transacción procede de una instalación nueva o existente respecto de la fecha regional de despliegue.
Las transacciones que usan Google Play Billing también tienen una tarifa de facturación adicional, fijada en el 5% en Estados Unidos, Reino Unido y el Espacio Económico Europeo.
Google indica que los detalles de la tarifa de facturación para otras regiones se anunciarán más adelante.
La decisión de desarrollo no es una simple comparación de porcentajes.
Si una app usa un enlace de pago externo o facturación alternativa, el negocio debe diseñar impuestos, reembolsos, recibos, cancelación de suscripciones, soporte y sincronización de derechos.
Si la app permanece en Google Play Billing, la implementación y el soporte pueden ser más consistentes, pero los precios, campañas y suscripciones deben adaptarse a las reglas y API de Play.
Decisiones antes de estimar el proyecto
Una estimación de Android no puede basarse solo en número de pantallas e integraciones API.
Si las premisas de distribución y monetización quedan abiertas, el equipo puede tener que rediseñar el lanzamiento, la firma, la facturación y el soporte después de construir la app.
| Decisión | Qué confirmar | Riesgo si se retrasa |
|---|---|---|
| Cuenta de desarrollador | Si la app pertenece al cliente, al operador o al proveedor | Derechos de publicación, facturas y transferencias se vuelven más difíciles |
| Canal de distribución | Google Play, tiendas externas, descarga directa o distribución interna | La verificación, la revisión y las actualizaciones pueden cambiar tarde |
| Clave de firma | Quién la guarda y cómo accede CI/CD | Las actualizaciones, la propiedad y la recuperación se convierten en riesgos |
| Modelo de facturación | Google Play Billing, facturación alternativa o enlaces externos | Términos, reembolsos, impuestos y soporte pueden rehacerse |
| Base de calidad | Pantallas grandes, tasa de fallos, accesibilidad, ANR y memoria | Suben los costes de revisión y mantenimiento después del lanzamiento |
Tres riesgos que suelen pasar desapercibidos
Publicar una app de negocio desde una cuenta personal
Una cuenta personal puede parecer más rápida durante un prototipo.
En una app de negocio, después puede crear problemas de propiedad, nombre público del desarrollador, facturación, contacto de soporte y transferencia de la app.
La ruta más segura es decidir pronto el propietario del negocio y alinear el nombre público, la política de privacidad y la responsabilidad de soporte antes del lanzamiento.
Tratar la distribución interna como una excepción
Las apps internas y los APK de prueba también necesitan disciplina de distribución cuando crece la audiencia.
Sin registro de dispositivos, grupos de usuarios, versiones, frecuencia de actualización y retirada de accesos, el equipo puede no poder rastrear un incidente ni revocar acceso con rapidez.
Incluso una distribución pequeña necesita una lista básica de quién puede usar qué versión y hasta cuándo.
Añadir pagos cuando el producto ya está terminado
Pasar de una app gratuita a funciones de pago no debe tratarse como una tarea tardía de interfaz.
Los derechos de acceso, la verificación de compras en servidor, los estados de reembolso, la cancelación y las herramientas de soporte deben diseñarse antes de cerrar las pantallas.
Las suscripciones requieren especialmente claridad para el usuario y una forma interna de que soporte consulte el estado de la cuenta.
Lista práctica para equipos de desarrollo
- Revisar roles de propietario, administrador, facturación y publicación en Play Console y Android Developer Console.
- Inventariar nombre de paquete, clave de firma, canales de distribución, países objetivo y modelo de facturación de cada app.
- Si hay distribución externa, confirmar si se requiere verificación del desarrollador y registro del paquete.
- Si CI/CD genera APK o App Bundle firmados, revisar almacenamiento de claves y permisos de acceso.
- En apps de pago, diseñar por separado tarifa de servicio, tarifa de facturación, reembolsos y sincronización de suscripciones.
- Incluir pantallas grandes, teclado, fallos, ANR y uso de memoria en la base de lanzamiento.
- Incluir política de privacidad, seguridad de datos, contacto de soporte y solicitudes de eliminación en la revisión previa al lanzamiento.
La prioridad para los próximos proyectos Android
La pregunta de los futuros proyectos Android no es solo si el equipo puede construir la app.
La pregunta más fuerte es si la app puede seguir distribuyéndose, actualizándose, monetizándose y recibiendo soporte bajo las reglas de plataforma aplicables a su audiencia.
Incluso las apps distribuidas solo en Google Play se ven afectadas por verificación de desarrolladores, registro de paquetes, estructuras de tarifas y programas de calidad.
Las apps que usan tiendas externas o descargas directas necesitan un plan más claro de verificación, instalación para usuarios expertos y soporte.
La primera decisión no es la tecnología.
Es quién responde por la app, dónde se distribuirá, cómo funcionarán los pagos y cómo recibirán los usuarios actualizaciones seguras.
Cuando esa base está clara, las decisiones sobre Kotlin, Jetpack Compose, API de servidor, facturación, analítica y operación se vuelven mucho más realistas.
FAQ
¿Importa la verificación si la app solo está en Google Play?
Sí.
Google afirma que la mayoría de desarrolladores de Play ya completaron la verificación y que la información de Play Console puede usarse para registrar apps elegibles.
¿Desaparecerá la distribución externa?
Google afirma que las apps no registradas aún podrán instalarse mediante ADB o un flujo avanzado para usuarios expertos.
Para una distribución amplia a consumidores, sin embargo, registrarse como desarrollador verificado probablemente será el modelo operativo más práctico.
¿Qué deberían comprobar primero los equipos en Japón sobre las tarifas de Google Play?
Conviene empezar por el modelo de ingresos de la app, las regiones de los usuarios, el uso de Google Play Billing y la necesidad de facturación alternativa o enlaces externos.
Japón está programado para el nuevo marco el 31 de diciembre de 2026, pero algunos detalles regionales de la tarifa de facturación siguen pendientes, por lo que el diseño debe dejar margen para actualizaciones oficiales.
Fuentes
- Android developer verification
- Android developer verification: Building a safer ecosystem together
- Android developer verification: Balancing openness and choice with safety
- Expanded billing choice and lower fees on Google Play
- Understanding Google Play’s lower service fees