ITMS-90683 significa que la app subida puede acceder a un recurso protegido, pero su Info.plist final no contiene el purpose string requerido. La solución no es añadir todas las claves de privacidad. Localiza el recurso que nombró App Store Connect, identifica qué código puede alcanzarlo y declara una razón honesta y orientada al usuario, solo si la app necesita de verdad ese acceso.
Lee la clave en el mensaje
El mensaje de subida normalmente nombra una clave ausente como NSCameraUsageDescription, NSMicrophoneUsageDescription o NSPhotoLibraryUsageDescription. Esa clave es tu punto de partida. La referencia de recursos protegidos de Apple explica qué purpose string corresponde a cada recurso.
«Esta app necesita acceso a la cámara» repite el nombre del permiso. Un string útil explica la acción: «Haz una foto de perfil» o «Escanea un recibo para adjuntarlo a un gasto».
Encuentra quién referencia el recurso
- Busca en el target de la app la API o capability que nombra el aviso.
- Revisa extensiones y frameworks embebidos, no solo el target principal.
- Repasa los SDK añadidos recientemente y los módulos opcionales. Una dependencia puede referenciar una API protegida aunque tu UI nunca la llame.
- Decide si el build de release necesita la función. Elimina la ruta de código sin uso o añade la declaración correcta.
Comprueba el bundle final de la app
Exporta el mismo archivo de Release que subes y luego inspecciona el plist procesado dentro del bundle .app. La guía de Info.plist de Apple describe cómo Xcode fusiona los ajustes del target con los plist suministrados.
unzip YourApp.ipa -d ipa-check
plutil -p ipa-check/Payload/YourApp.app/Info.plist \
| grep UsageDescriptionEscribe un purpose string que sobreviva a la revisión
- Nombra la acción del usuario que desencadena el acceso.
- Explica qué permite hacer ese dato dentro de la app.
- Describe el producto actual, no una función planificada.
- Localiza el string a cada idioma soportado.
- Prueba el aviso del sistema en una instalación limpia.
Sube un binario nuevo
Cambiar los metadatos de la tienda no modifica el bundle de la app. Incrementa el número de build, archiva exactamente la configuración de release, verifica el plist procesado y sube un binario nuevo. Guarda el mensaje original en el ticket de release para que la misma dependencia no pueda reintroducir el problema sin que nadie lo note.
¿Te ha resultado útil este artículo?