¿Cómo mejorar la tasa de aprobación de revisiones de iOS?

Los estudiantes responsables del desarrollo de aplicaciones iOS deben ser torturados por el mecanismo de revisión de la APP Store. En el nuevo año se acerca una nueva ronda de auditorías, ¿estás preparado?

Para ayudar a los desarrolladores de aplicaciones de iOS a evitar la tortura, Tencent Bugly invitó a los estudiantes del equipo de revisión previa de iOS a analizar una gran cantidad de datos, resumir el mecanismo de revisión de Apple y apresurarse a escribir una guía para mejorar iOS. revisa los trucos (divididos en dos partes debido al gran contenido) y compártelos con todos.

Después de casi un año de monitoreo de datos por parte del equipo de revisión previa de iOS y análisis de casos de rechazo de aplicaciones anteriores, analizamos cuidadosamente la situación de revisión de iOS y compilamos estadísticas sobre los motivos más comunes de rechazo:

A través de los casos anteriores, combinados con las "Pautas de revisión de la App Store de Apple", podemos dividir aproximadamente el trabajo de revisión en tres partes: inspección de recursos del cliente, inspección del contenido de la aplicación e inspección de recursos de auditoría. A continuación, lo guiaremos a través de los tres pasos para revelar la verdad sobre la auditoría de iOS.

Paso 1: Verificación del cliente

El objetivo principal de la verificación del cliente es verificar la configuración del cliente, incluido el sistema de almacenamiento, el archivo de configuración, la conexión de red (VPN), la verificación de íconos y la API privada. Las comprobaciones garantizan que los clientes cumplan con las especificaciones de desarrollador de Apple y otros requisitos actualizados, mientras que las revisiones previas cubrirán todos los puntos de prueba en estas secciones.

1. Verificación del sistema de almacenamiento

Apple tiene oficialmente regulaciones estrictas sobre el almacenamiento de datos del usuario, por lo que si desea aprobar la revisión, primero debe comprender el contenido del almacenamiento de datos oficial de Apple. pautas:

Cláusula de rechazo: 2.23

Las aplicaciones deben seguir las pautas de almacenamiento de datos de iOS o serán rechazadas (con el almacenamiento de iCloud habilitado, las aplicaciones deben seguir las pautas de almacenamiento de datos de iOS o serán rechazadas). ser rechazado).

Casos de rechazo

Los motivos del rechazo se describen a continuación:

Descubrimos que su aplicación no sigue las pautas de almacenamiento de datos de iOS, que son necesarias para la revisión de la App Store.

Específicamente, descubrimos que su aplicación almacenó 5,6 MB de datos al iniciar y/o descargar contenido. Para comprobar cuántos datos almacena tu aplicación:

Instala e inicia tu aplicación y descubrirás que no sigue las pautas de almacenamiento de datos de iOS, que son necesarias para la revisión de la App Store.

Instala e inicia tu aplicación

Ve a Configuración>iCloud>Almacenamiento>Copia de seguridad>Administrar almacenamiento

Si es necesario, haz clic en Mostrar todas las aplicaciones "

Comprueba el almacenamiento de tu aplicación

Las pautas de almacenamiento de datos de iOS establecen que iCloud solo debe realizar una copia de seguridad del contenido creado por los usuarios que usan tu aplicación (como documentos, archivos nuevos, ediciones, etc.).

Los archivos temporales utilizados por su aplicación deben almacenarse solo en el directorio /tmp; recuerde que los archivos almacenados en esta ubicación deben eliminarse cuando el usuario sale de la aplicación.

Los datos que se pueden recrear pero que deben persistir para garantizar que la aplicación funcione correctamente, o que deben persistir porque el cliente espera que estén disponibles sin conexión, deben marcarse con el atributo "no realizar copia de seguridad". Para los objetos NSURL, agregue el atributo NSURLIsExcludedFromBackupKey para evitar que se realice una copia de seguridad del archivo correspondiente. Para objetos CFURLRef, utilice la propiedad kCFURLIsExcludedFromBackupKey correspondiente. Después de modificar la aplicación para agregar el atributo sin respaldo (NSURLIsExcludedFromBackupKey) en el directorio de documentos, la revisión pasó.

Para resumir las especificaciones de almacenamiento después de iOS5:

ü Solo los documentos generados por el usuario y otros datos o datos que la aplicación no pueda reconstruir deben guardarse en el directorio /Documentos. Se realizará una copia de seguridad de estos archivos de datos automáticamente a través de iCloud.

ü Los datos que se pueden volver a descargar o reconstruir deben guardarse en el directorio /Library/Caches. Puede colocar archivos de caché de bases de datos o contenido descargable como revistas, periódicos, datos de aplicaciones de mapas, etc. en el directorio de caché.

ü Los datos necesarios temporalmente deben guardarse en el directorio /tmp. Aunque no se realiza una copia de seguridad de estos archivos en iCloud, recuerde eliminarlos tan pronto como ya no los necesite para evitar desperdiciar más espacio de almacenamiento en su dispositivo.

ü Utilice el atributo "No realizar copia de seguridad" para especificar archivos que no requieren copia de seguridad de iCloud (por ejemplo, archivos que deben usarse en un entorno fuera de línea; este atributo se aplica a cualquier directorio). Debido a que estos archivos ocupan espacio en el dispositivo, las aplicaciones necesitan un mecanismo para monitorear y limpiar estos archivos periódicamente.

Qué hacer

En este caso, la copia de seguridad de iCloud no está habilitada para la aplicación. Si la copia de seguridad de iCloud está habilitada, puede resolver este problema almacenando datos más grandes (clases de plantilla, datos descargados de Internet, etc.) en el directorio /Library/Caches.

2. Inspección del archivo de configuración (Info.plist)

Cada aplicación utiliza el archivo Info.plist para almacenar la metainformación anterior, que a menudo se denomina "lista de propiedades". iOS usa Info.plist para determinar qué íconos muestra el paquete, qué aplicaciones admite actualmente la apertura y cuántas aplicaciones tiene abiertas. iOS usa Info.plist para determinar los íconos que muestra el paquete, los tipos de documentos que la aplicación admite actualmente y otra información. Como se mencionó anteriormente, Info.plist en sí es un archivo de texto estructurado que contiene información de configuración importante. Al examinar esta sección, normalmente nos centramos en lo siguiente:

Términos de rechazo

Las aplicaciones multitarea solo pueden utilizar servicios en segundo plano para los fines previstos: VoIP, reproducción de audio, ubicación, tarea. finalización, notificación local, etc.: VoIP, reproducción de audio, geolocalización, finalización de tarea, notificación local, etc.)

Caso de rechazo

Descripción del motivo del rechazo:

Nosotros Se descubrió que su aplicación utiliza un modo en segundo plano pero no incluye funcionalidad que requiera que se ejecute continuamente. Este comportamiento no cumple con las pautas de revisión de la App Store.

Notamos que su aplicación declara soporte para VoIP en la clave UIBackgroundModes en Info.plist, pero no proporciona ningún servicio de Voz sobre IP.

Reconocemos que VoIP proporciona una función de "mantenimiento" que ofrecen muchas funciones de aplicaciones.

Reconocemos que VoIP proporciona la funcionalidad "permanente" que muchas aplicaciones desean. Sin embargo, como se indica en la Guía de programación de aplicaciones de iOS, usar VoIP de esta manera no es el propósito previsto de VoIP: "

Sería apropiado agregar la funcionalidad VoIP o eliminar la configuración "VoIP" de UIBackgroundModes. palabra clave

Breve comentario:

La palabra clave UIBackgroundModes definida en Info.plist declara indirectamente la función de UIBackgroundModes.

Dado que la clave UIBackgroundModes definida en Info.plist declara indirectamente soporte para la función VoiP, Apple considerará que la aplicación real no está implementada de acuerdo con la definición de Voip, lo que resultará en el rechazo al eliminarla; Info.plist Después de agregar UIBackgroundModes (VoIP) y el código relacionado, la aplicación pasó la revisión. En general, cuando su aplicación se envíe por primera vez para revisión, intente eliminar las funciones controvertidas para asegurarse de que su aplicación esté disponible lo más rápido posible.

3. Conexión de red (VPN)

La mayoría de los servidores de revisión de aplicaciones están implementados en China, pero el equipo de revisión de iOS de Apple está en Estados Unidos y utilizan la red estadounidense para su revisión. Las conexiones de red intercontinentales inevitablemente provocan alta latencia, fluctuaciones, pérdida de paquetes y otros problemas de red y, por lo tanto, son rechazadas.

Contramedidas

Para verificar de antemano la respuesta del servidor backend de la aplicación en esta situación, el equipo de revisión previa utilizó el método VPN de EE. UU. para simular el entorno de red al que accede el Equipo de revisión de Apple.

4. Verificación de íconos

Los funcionarios de Apple tienen requisitos claros para los íconos de iPhone, iPad, iPod y otras aplicaciones: el paquete ipa debe contener tamaños de 180x180, 120x120, 76x76, 152x152. Ícono en formato PNG (consulte la tabla a continuación para obtener más detalles), el contenido del ícono de diferentes tamaños debe ser el mismo.

5. Verificación de API privada

La API privada se refiere a la API ubicada en el marco PrivateFrameworks, y la API no publicada se refiere a la API ubicada en el marco de Frameworks pero que no figura en la lista oficial de Apple. documentos (como API documentada en instrucciones, descripciones de código, etc.).

Anteriormente, la APP Store eliminó varias API, incluidas "Dad", "The Rise of the Fairy", "The Rise of the Fairy" y "The Rise of the Fairy". La App Store eliminó 256 aplicaciones, incluidas "Dónde está papá 2" y "Encuentra a tu hermana", por llamar a API privadas que Apple aparentemente no permite el uso de aplicaciones.

Cláusula de Rechazo: 2.5

Las aplicaciones que utilicen API no públicas serán rechazadas... (Las aplicaciones que utilicen API no públicas serán rechazadas.)

Caso de rechazo

El motivo del rechazo se describe a continuación:

Descubrimos que su aplicación utiliza una o más API no públicas, lo que no cumple con las regulaciones de revisión de la App Store.

Encontramos la siguiente API no pública en su aplicación:

descriptionWithCalendarFormat:

Si ha definido la misma API que arriba en el nombre del método de su código fuente , le recomendamos que cambie el nombre del método para que ya no entre en conflicto con la API privada de Apple para evitar que su aplicación sea marcada en futuros envíos.

Además, una o más de las API anteriores pueden estar ubicadas en bibliotecas estáticas incluidas con su aplicación. Si no tiene acceso al código fuente de la biblioteca, puede utilizar las herramientas de línea de comandos "strings" o "otool" para buscar los binarios compilados. Estas herramientas generarán una lista de métodos llamados por la biblioteca, mientras que "otool -ov " generará una estructura de clase Objective-C y su estructura.

Apreciamos las precauciones que está tomando en su código para utilizar API no públicas, pero no podemos predecir de manera precisa o completa cómo se podrían modificar las API y qué impacto podrían tener esas modificaciones. Por lo tanto, no permitimos el uso de API no públicas en aplicaciones de la App Store.

Breves comentarios:

Hay texto más descriptivo de por qué se rechazó esta cláusula. Echemos un vistazo a la clasificación de las API de Apple:

1) API publicada (API pública): También conocida como API documentada (API documentada en documentación). Son todas las API que Apple expone a desarrolladores externos de todo el mundo a través de Cocoa Touch.

2) API no publicada: también conocida como API no documentada, se refiere a las API que se colocan en el marco pero no están documentadas en los documentos oficiales de Apple (como instrucciones, descripciones de código, etc.). Según Apple, las API no documentadas son API menos maduras y están sujetas a cambios. Según Apple, las API no publicadas se refieren a API que no están lo suficientemente maduras y pueden cambiar. Se convertirán en API públicas una vez que estén completamente formadas, pero actualmente no existe ningún compromiso con ellas, es decir, pueden dejar de ser válidas después de que se actualice la versión del sistema. actualizado.

3) API privada: se refiere a la API del SDK bajo el marco PrivateFrameWorks, que realmente existe en Cocoa Touch. La API privada es una API que Apple estipula explícitamente que no se puede utilizar. Por supuesto, no existe tal restricción en los canales de jailbreak (como el canal 91).

Las API no públicas en texto rechazado se incluyen en las dos últimas categorías. Si el código fuente define un método cuyo nombre se cambia utilizando una API no pública, esto también resultará en un rechazo, es más común usar una biblioteca estática de terceros que contenga una API no pública, para que pueda; utilice un comando string o otool para encontrar la API relevante:

strings LibName.a | descripciónWithCalendarFormat

o

cadenas AppName.app |

donde .app está en el directorio de compilación al final del documento de compilación.

Utilice otool -ov LibName.a para generar la estructura de clases de Object-C y los métodos definidos.

Contramedidas

Utilice herramientas de escaneo automatizadas para lograr esto. El principio de implementación es el siguiente:

1. Obtenga bibliotecas no públicas: basadas en iOS SDK. volcar la biblioteca completa menos la biblioteca privada y la biblioteca pública para obtener una biblioteca no pública (API no pública);

2. Obtener el método del archivo de encabezado y la lista de miembros: use Otool y otras herramientas para descompilar. y analice el archivo ejecutable ipa para obtener la lista de métodos y miembros en el archivo de encabezado

3. Coincidencia con bibliotecas no públicas y bibliotecas privadas: haga coincidir los métodos y miembros de la lista con bibliotecas privadas. y bibliotecas no públicas, si no tiene éxito. Si hay una coincidencia, el escaneo pasa. Si hay una coincidencia exitosa, el escaneo falla (se genera una alerta y se proporciona el nombre de la API). nombre de API).

6. Diferencias de hardware y versión

iOS se lanzó como sistema de telefonía móvil en 2007 y posteriormente se aplicó al iPod touch, iPad y Apple TV, y se ha actualizado en múltiples ocasiones. versiones. El hardware de Apple también está en constante evolución y ahora hay más versiones de hardware de sus productos disponibles en mercados externos. Con tantas versiones de hardware y sistemas, cómo garantizar la calidad de las versiones de revisión siempre ha sido un gran desafío para los equipos de pruebas y productos.

Rechazar el caso

Contramedidas

1. Centrarse en la misma versión de aceptación que Apple: se especula que el equipo de revisión de Apple seguirá el principio de selección de aceptación del dispositivo. : Acepte las últimas dos versiones del sistema y dos versiones de hardware lanzadas. Asegúrese de que el juego pueda ejecutarse sin problemas en las dos versiones del sistema y configuraciones de hardware con la mayor participación de mercado.

2. Preste atención a la versión beta: Apple lanzará la versión beta antes de que la nueva versión esté disponible y realizará una pequeña cantidad de pruebas. En este momento, es necesario realizar un seguimiento de la versión beta. para detectar problemas con antelación y evitar la publicación repentina de la versión.

Resumen:

1. La inspección del sistema de almacenamiento es en realidad un conjunto de especificaciones, que siguen la misma serie de conceptos, como el uso razonable del espacio de almacenamiento local del usuario y el uso de Ahorro de espacio de almacenamiento en el servidor Apple iCloud;

2. La verificación del archivo Info.plist es en realidad la verificación del valor clave del archivo xml y la relación con la verificación del valor es paralela.

3. Utilice herramientas automatizadas para escanear si se llaman API privadas. Apple no escanea regularmente las versiones en línea, excepto las versiones de prueba, así que no piense en omitir las API privadas a través de interruptores de control de la nube o códigos enviados. También debe tenerse en cuenta que Apple también considerará cambiar el nombre de una función con una API privada sin llamar a la API privada como una violación de las reglas de la API privada.