¿Qué prácticas han aprendido las personas antes de realizar su compilación final y enviarlas a la App Store? Además de pasar de Debug a la versión & comentando las llamadas a NSLog, ¿qué otras cosas básicas y/o no tan básicas debemos tener en cuenta?Lista de comprobación preliminar antes de compilar la versión final para la tienda de aplicaciones
Esta es una buena pregunta y quisiera reiterar algunas de las respuestas y agregar algunas propias. He hecho esta respuesta Community Wiki, siéntase libre de agregarle.
Elimina la aplicación de tu dispositivo, desactiva la conexión WiFi, desactiva los datos móviles, ahora instala y prueba la aplicación. ¿Funciona correctamente (tanto como puede sin Internet)? ¿Al menos le dice al usuario que se requiere una conexión de red (si es así) o se bloquea?
Si utiliza CLLocationManager: elimine la aplicación, instale y ejecute de nuevo, pero no permita que la aplicación tenga datos de ubicación. ¿La aplicación se comporta bien o se bloquea? ¿Al menos le dice al usuario que no puede ejecutarse sin datos de ubicación (si es un requisito)? ¿Funciona en un iPod Touch que hace toda la ubicación geográfica usando solo WiFi?
Ejecute la aplicación en el simulador y para cada controlador de vista realice los siguientes pasos: (a) Desde el menú Simulador de iPhone seleccione "Hardware" -> "Simular memoria de advertencia", (b) ahora navegue alrededor de su aplicación para ver otros controladores y ver si todo está funcionando, (c) repetir la prueba para otro controlador de vista.
Si admite firmware anterior (es decir, iOS 3.1.3), instale su aplicación en un dispositivo que ejecuta 3.1.3 y pruébela allí (si no tiene una, use el simulador 3.2).
Inicie su aplicación mientras está en una llamada telefónica o cuando el Hotspot personal está activo.¿Son correctos todos los diseños de pantalla (la barra de estado es de 40 px de alto en lugar de 20)? ¿Los 20 píxeles inferiores de la vista se salieron de la pantalla o se redimensionaron correctamente?
Acepte una llamada telefónica mientras está en su aplicación, ¿se resuelve y se reanuda correctamente? ¿Los sonidos de tu aplicación dejan de reproducirse durante la llamada?
Inicie su aplicación mientras reproduce música, ¿la música continúa sonando? ¿Sus sonidos se mezclan correctamente o difuminan la música de manera apropiada?
Pruebe el rendimiento en un devices más lento con RAM limitada como: iPhone 3G (128MB RAM, CPU 412Mhz) o iPod Touch (1ra o 2da generación).
Ejecute el analizador estático Clang y corrija (o al menos comprenda) cada advertencia.
Asegúrese NSZombiesEnabled es NO en las variables de entorno (precaución: no estoy seguro si esto sigue siendo un problema)
En lugar de cambiar a Release, cambio a "Distribution". Es una copia de Release, pero así es como me enseñaron algunos doc de Apple y iPhoneDeveloperTips.
puntos importantes:
Después de la versión final, pero antes de salir corriendo a cerrar la cremallera de su aplicación, abra el paquete utilizando Mostrar contenido del paquete del Finder. Debido a algún error en el MacOS, que me mordió en versiones anteriores a Snow Leopard (y aún podría estar allí), si se cierra demasiado rápido (usando el elemento de menú Compresor o Archivo del Finder), algunos de los recursos aún no ser arrojado al archivo. Cuando haces un Show Package Contents, los contenidos se actualizan. La forma en que se daría cuenta de este problema es que el tamaño de su aplicación comprimida sería entre un quinto y un décimo o menos del tamaño esperado. Podrías pensar, "oye, esa utilidad de compresión realmente hace un gran trabajo de compresión", pero ese no es el caso. Este problema ocurriría en este punto en lugar de durante la prueba, principalmente porque está haciendo una compilación de "limpiar todo" y todos los recursos y contenidos del paquete de la aplicación están comenzando vacíos y luego llenados por Xcode. Y por alguna razón, incluso después de que Xcode termine de crear el archivo, el contenido aún no está allí, si se comprime, pero estaría allí si se mira (como un Heisenberg inverso). Tener cuidado.
Otra área en la que paso mucho tiempo es hacer una buena copia de seguridad de las fuentes, después de haber confirmado todos los últimos cambios en SVN, crear una nueva rama y etiquetar el archivo. También me gustaría que mi número de versión coincida con mi número de compilación/confirmación de SVN, así que siempre sé qué versión de SVN coincide con mi versión. Tengo esos dos números de versión en mi info.plist y puede ser retirado por el usuario de la aplicación cuando llegan a i para obtener información. Por ejemplo, un info.pist actual incluye:
<key>CFBundleShortVersionString</key>
<string>2.0a1</string>
<key>CFBundleVersion</key>
<string>346</string>
Hay diferentes ideas sobre cómo utilizar el CFBundleVersion. Esta es mi manera. También es útil la utilidad de línea de comandos, agvtool.
Una vez que se compila la aplicación, después de comprimir para que no esté realizando ningún cambio en la versión comprimida, revise el archivo de la aplicación y asegúrese de que esté firmado con el certificado de distribución correcto y no con el correcto. Aprender a utilizar la utilidad de línea de comandos, codesign, es útil para este tipo de comprobación y depuración. Al hacer primero la copia comprimida, se asegura de que no modifique de ninguna manera la copia final que Xcode le entregó y que la cargará a iTunes, si todo se ve bien.
Otras cosas para recordar son el icono de la aplicación, los otros iconos y gráficos necesarios para la tienda de iTunes, el info.plist y el hecho de que cuando la carga de la aplicación falla con un mensaje de error críptico, generalmente tiene que ver con la falta de una de estas piezas en el archivo comprimido que está compilando (las piezas que pertenecen al paquete de la aplicación).
algunas cosas:
realidad, yo no recomiendo crear una configuración de generación llamada "Distribución", como especifica Apple, porque a menudo estoy creando especial construye para los probadores beta. Creo dos configuraciones de compilación, una llamada Ad Hoc y otra llamada AppStore, por lo que no estoy confundido. La única diferencia entre los dos es la presencia del archivo Entitlements.plist para la compilación Ad Hoc.De esta manera puedo probar lo más cerca posible lo que enviaré a Apple.
La mayoría de los desarrolladores son optimistas. Es por eso que estamos trabajando los fines de semana para crear una aplicación que sabemos que nos convertirá en millonarios. Antes de enviar, sea pesimista. Imagine todo lo que posiblemente puede salir mal y vuelva a verificarlo.
No asuma nada. No suponga que ese pequeño cambio que hizo en la aplicación no afectará a nada más. La ley de Murphy dice que ese pequeño cambio hará que tu aplicación se cuelgue en todos los iPod Touches o algo así. Pruebe, pruebe y pruebe minuciosamente entre la edición del código final y el envío de Appstore. Si tiene que hacer un pequeño cambio, repita hasta que sea perfecto.
Recuerde que si la aplicación no falla para el 99.9% de sus usuarios, entonces 1 de cada 1,000 descargas resultará en una revisión mordaz de 1 estrella.
Uso el analizador estático de Clang, las filtraciones y las asignaciones de objetos durante el desarrollo, pero hago una ejecución adicional de estas herramientas antes de enviarlas por si acaso.
Si no tiene un dispositivo anterior, obtenga uno, porque el rendimiento de 3GS es significativamente mejor y es posible que omita algunos problemas de rendimiento importantes.
Prueba de su aplicación con las siguientes configuraciones cuando la red o ubicación son aplicables:
Mira en este documento lista de verificación @ Github