Saltar al contenido
Reboll StudioREBOLL STUDIO

Desarrollo

Cómo nombramos nuestras apps: la convención com.rebollstudio.*

Qué es un identificador de paquete en notación de dominio inverso, por qué no se puede cambiar después de publicar y cómo lo aplicamos en Android, iOS y Unity.

Reboll Studio 3 min de lectura

Cuando publicas una app en Google Play o en la App Store, hay un dato que parece un trámite y que en realidad es una de las decisiones más permanentes del proyecto: el identificador de la aplicación. En Reboll Studio todos siguen el mismo formato:

com.rebollstudio.<proyecto>

En este artículo explicamos de dónde viene esa convención, qué reglas sigue y los errores que conviene evitar.

Notación de dominio inverso

La idea viene de Java: para evitar que dos paquetes de distintas empresas se llamen igual, se usa el dominio de la organización al revés, del más general al más específico. Nuestro dominio es rebollstudio.com, así que el prefijo es com.rebollstudio. A partir de ahí añadimos el nombre del proyecto:

Proyecto Identificador
ChronoShift com.rebollstudio.chronoshift
MetalCalc com.rebollstudio.metalcalc
Reboll Scanner com.rebollstudio.scanner
Crimson Core com.rebollstudio.crimsoncore

Como el dominio nos pertenece, nadie más debería usar ese prefijo, y el identificador queda garantizado como único en las tiendas.

Por qué es una decisión permanente

En Google Play, el applicationId identifica la app para siempre. Si lo cambias, para la tienda es una app nueva: pierdes las reseñas, las descargas y, sobre todo, los usuarios existentes no reciben la actualización. En iOS pasa lo mismo con el Bundle Identifier.

Por eso lo decidimos al crear el proyecto y no lo volvemos a tocar.

Reglas que seguimos

  1. Solo minúsculas, números y puntos. Nada de guiones (-): en Java no son válidos en nombres de paquete. Si el nombre tiene varias palabras, se juntan: crimsoncore, no crimson-core.
  2. Nombre estable, no comercial. El nombre visible de la app puede cambiar con una campaña de marketing; el identificador no. Elegimos una palabra corta que represente al proyecto.
  3. Sufijos para variantes. Para versiones de desarrollo usamos un sufijo, de modo que se puedan instalar junto a la versión estable: com.rebollstudio.chronoshift.dev.
  4. Sin palabras reservadas. Segmentos como int, new o class dan problemas en Java/Kotlin.

Android: applicationId frente a namespace

En los proyectos Android modernos con Gradle hay dos valores que suelen confundirse:

android {
    namespace = "com.rebollstudio.chronoshift"
    defaultConfig {
        applicationId = "com.rebollstudio.chronoshift"
    }
    buildTypes {
        debug {
            applicationIdSuffix = ".dev"
        }
    }
}
  • namespace define el paquete del código generado (la clase R, BuildConfig). Puedes reorganizar tu código sin afectar a la tienda.
  • applicationId es el que ve Google Play. Es el que nunca se cambia.

Mantenerlos iguales al empezar evita confusiones, pero saber que son independientes te permite refactorizar sin miedo.

iOS y Unity

En Xcode el valor equivalente es el Bundle Identifier, y en Unity se configura en Player Settings → Other Settings → Package Name (Android) y Bundle Identifier (iOS). Usamos exactamente el mismo valor en ambas plataformas para que el proyecto sea fácil de reconocer en cualquier consola de desarrollador.

Proyectos web

Para servicios web la notación inversa no aplica: usamos subdominios del propio dominio, como ai.rebollstudio.com o lab.rebollstudio.com. La lógica es la misma: el dominio es nuestro y el nombre identifica al proyecto.

En resumen

  • Elige el identificador una vez, al crear el proyecto.
  • Usa tu dominio al revés como prefijo.
  • Minúsculas, sin guiones y con un nombre corto y estable.
  • Usa sufijos para las variantes de desarrollo.

En la sección Stack de la portada puedes copiar el formato com.rebollstudio.<proyecto> con un clic y ver la lista de identificadores de todos nuestros proyectos.

  • #Android
  • #iOS
  • #Unity
  • #Buenas prácticas

Sigue leyendo

Volver al blog