Qué revisar antes de publicar una app empresarial en iOS y Android
Por Carlos Isidoro De Ayala Diaz ·
Qué revisar antes de publicar una app empresarial: cuentas, firma, permisos, privacidad, pruebas, tiendas y continuidad en iOS y Android para empresas.
Define la propiedad y el recorrido de publicación antes de compilar
Una aplicación empresarial no está lista para publicarse porque funcione en el teléfono del equipo de desarrollo. Antes de generar la versión final hay que decidir quién será titular de las cuentas de Apple y Google, quién podrá aceptar acuerdos, quién atenderá los avisos de las tiendas y quién conservará los accesos. Siempre que sea posible, las cuentas, el identificador de la app y la ficha pública deben quedar bajo control de la empresa que encargó el producto, con usuarios nominativos y permisos limitados.
El inventario de entrega incluye el identificador de paquete, repositorios, certificados, claves de firma, perfiles, configuración de entornos y acceso al backend. No todos esos elementos se comparten del mismo modo: las claves se protegen y se documenta cómo renovarlas o recuperarlas sin enviarlas por correo. También se acuerdan las personas que pueden crear una versión y las que pueden aprobar su salida. Si solo un proveedor controla la firma o el repositorio, una baja o una incidencia puede bloquear futuras actualizaciones.
La ruta de publicación debe separar desarrollo, pruebas y producción. Se elige el canal interno o cerrado, se asigna una versión inequívoca y se registra qué backend utiliza. Para la revisión de Apple o Google se preparan instrucciones y, si el contenido está restringido, un acceso válido que no exponga información real de clientes. Apple advierte que omitir ajustes, credenciales o instrucciones especiales para revisar la app puede retrasar o impedir la evaluación. La aprobación de una tienda sigue dependiendo de sus propios criterios.
Haz que permisos, SDK y declaraciones de privacidad describan la misma app
La declaración de privacidad debe partir de un inventario técnico, no de una plantilla. Se revisan los datos que introduce el usuario, los que genera la app, los que transmite el backend y los que recogen librerías de analítica, mapas, notificaciones, soporte o diagnóstico. Para cada dato se documentan finalidad, destinatario, necesidad, conservación y posibilidad de borrado. Esa misma realidad debe reflejarse en la política de privacidad, en las pantallas de consentimiento y en las respuestas de las tiendas.
Apple exige una URL de política de privacidad para las apps de iOS y que las respuestas de App Store Connect incluyan las prácticas de la app y de los terceros integrados. Google Play exige completar su formulario de Seguridad de los datos y declara responsable al desarrollador de que la información sea completa y exacta, también respecto a SDK de terceros. Por eso no basta con copiar lo declarado en una plataforma: las taxonomías difieren y las respuestas deben contrastarse con el comportamiento de la compilación que se distribuye.
Los permisos del dispositivo se limitan a las funciones previstas. Cámara, ubicación, contactos, archivos o notificaciones se solicitan cuando el usuario entiende qué tarea los necesita. Si Android detecta permisos sensibles o de alto riesgo, la publicación puede requerir una declaración y una justificación adicional. Una dependencia puede añadir permisos sin que la interfaz los utilice; revisar el manifiesto y la compilación final permite retirarlos antes de enviar. Cuando cambia un SDK o una función, se actualizan también las declaraciones públicas.
Prueba seguridad, errores y datos en la versión que llegará a la tienda
La versión candidata se prueba con cuentas y servicios equivalentes a producción, sin usar secretos reales en capturas o instrucciones. La matriz cubre versiones de sistema, tamaños representativos, permisos concedidos y rechazados, pérdida de red, reintentos, cierre de sesión y actualización desde una versión anterior. Si la app funciona sin conexión, se comprueba qué queda almacenado, cómo se protege y qué ocurre cuando dos cambios entran en conflicto al sincronizar.
La autorización se verifica en el servidor. Ocultar un botón en iOS o Android no impide que una cuenta invoque directamente una API. También se revisan caducidad de sesiones, recuperación de cuenta, almacenamiento local, comunicaciones, actualización de dependencias y ausencia de secretos dentro del paquete. OWASP MASVS organiza estas comprobaciones en áreas como almacenamiento, criptografía, autenticación, red, interacción con la plataforma, código, resistencia y privacidad; el alcance concreto se adapta al riesgo y a los datos de la aplicación.
Los registros de errores deben ayudar a diagnosticar sin copiar contraseñas, tokens o contenido sensible. Se prueba que una caída, un rechazo del backend o una operación duplicada produzcan una respuesta comprensible y una evidencia útil para soporte. Las pruebas de accesibilidad, rendimiento y consumo se realizan sobre la compilación firmada, porque una optimización, un SDK o la configuración de producción pueden cambiar el resultado observado durante el desarrollo.
Prepara una salida gradual y un mantenimiento que la empresa pueda operar
Publicar no termina el proyecto. Antes de abrir la versión a todos los usuarios se acuerdan responsables, canal de incidencias, métricas técnicas, alertas y criterio para detener el despliegue. Una distribución gradual reduce el impacto de un fallo, pero necesita alguien que revise señales y pueda decidir. También se prepara la respuesta si la tienda rechaza la entrega: quién interpreta la observación, qué cambio puede hacerse sin alterar el alcance y qué parte requiere una decisión del cliente.
La reversión móvil no equivale a sustituir inmediatamente un archivo web. Algunos usuarios conservarán una versión instalada y otros actualizarán más tarde. El backend debe tolerar durante el periodo acordado las versiones compatibles y evitar migraciones irreversibles antes de confirmar la estabilidad. Si se retira una función, se planifica qué sucede con los datos locales, las sesiones y las notificaciones. La documentación final incluye versión publicada, dependencias externas, cuentas, firma, endpoints y procedimiento de actualización.
Élite Solutions Tech puede preparar desde Murcia el desarrollo y la publicación de apps para proyectos regionales y nacionales. La propuesta concreta plataformas, cuentas, integraciones, pruebas, fichas de tienda, atención de observaciones y mantenimiento posterior. Costes de las cuentas, servicios de terceros, tiempos de revisión y aprobación de Apple o Google no se presuponen. La primera conversación puede centrarse en usuarios, tarea principal, datos, sistemas conectados y quién operará la aplicación después de su lanzamiento.