Lista de verificación previa al lanzamiento antes de crear la versión final para App Store

Algunas cosas:

Realmente recomiendo no crear una configuración de compilación llamada "Distribución" como especifica Apple, porque a menudo estoy creando compilaciones ad hoc para 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 de los Derechos.archivo plist para la compilación Ad Hoc. De esta manera puedo probar lo más de cerca posible lo que enviaré a Apple.

La mayoría los desarrolladores son optimistas. Por eso estamos trabajando los fines de semana para crear una app que sabemos que nos va a hacer millonarios. Sin embargo, antes de someterse, sea pesimista. Imagine todo lo que pueda salir mal, y vuelva a comprobarlo.

No asumas nada. No asumas que ese pequeño cambio que hiciste en la aplicación no afectará nada más. La ley de Murphy dice que ese pequeño cambio hará que tu aplicación se bloquee en todos los toques de iPod o algo así. Prueba, prueba, prueba minuciosamente entre la edición final del código y el envío de la Appstore. Si tiene que hacer un pequeño cambio, repita hasta que esté perfecto.

Recuerde que si la aplicación no se bloquea para el 99.9% de sus usuarios, entonces 1 de cada 1,000 descargas resultará en una revisión mordaz de 1 estrella.

Utilizo Clang static analyzer, Leaks y Asignaciones de Objetos durante el desarrollo, pero hago una ejecución adicional de estas herramientas antes del envío por si acaso.

Si no tiene un dispositivo anterior, obtenga uno, porque el funcionamiento 3GS es perceptiblemente mejor y usted puede pasar por alto algunas ediciones importantes del funcionamiento.

Pruebe su aplicación con las siguientes configuraciones cuando la red o la ubicación sean aplicables:

• iPod Touch
• iPhone 3G
• iPhone 3GS
• iPhone en modo avión
• iPhone con Wi-Fi
• iPhone con BORDE
• Llame al teléfono mientras usa su aplicación

En lugar de cambiar a Release, cambio a "Distribution". Es una copia de Release, pero así es como me enseñaron algunos documentos de Apple y Iphonedeveloppertips.

Puntos importantes:

Después de la compilación final, pero antes de apresurarte a comprimir tu aplicación, abre el paquete usando el Finder Mostrar contenido del paquete. Debido a algún error en el macOS, que me mordió en versiones anteriores a Snow Leopard (y puede que todavía esté allí), si comprime demasiado rápido (usando el Finder Comprimir o Archivar elemento de menú), algunos de los recursos aún no se han vaciado en el archivo. Cuando se muestra el contenido del paquete, el contenido se actualiza. La forma en que notaría este problema es que el tamaño de su aplicación comprimida sería entre una quinta a una décima o menos del tamaño esperado. Usted puede pensar a sí mismo, "hey, esa utilidad zip 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 las pruebas principalmente porque estás haciendo una compilación de "limpiar todo" y todos los recursos y contenidos del paquete de aplicaciones comienzan vacíos y luego se llenan con Xcode. Y por alguna razón, incluso después de que Xcode haya terminado de crear el archivo, el contenido todavía no está realmente allí, si comprime, pero estaría allí si los mirara (una especie de Heisenberg inverso). Cuidado.

Otra área en la que paso mucho tiempo es hacer una buena copia de seguridad de las fuentes, después de haber enviado todos los últimos cambios a SVN, creó una nueva rama y etiquetó el archivo. También me gusta que mi número de versión coincida con mi número de compilación/confirmación de SVN, por lo que siempre sé qué versión de SVN coincide con mi lanzamiento. Tengo esos dos números de versión en mi información.plist y puede ser arrastrado por el usuario de la aplicación cuando pulsa i para obtener información. Por ejemplo, una información actual.incluye:

<key>CFBundleShortVersionString</key>
<string>2.0a1</string>
<key>CFBundleVersion</key>
<string>346</string>

Hay diferentes ideas sobre cómo usar CFBundleVersion. Esta es mi manera. También es útil la utilidad de línea de comandos, agvtool .

Una vez que la aplicación se construye, después de comprimir por lo que en realidad no está haciendo ningún cambio a la versión comprimida, vaya a comprobar el archivo de la aplicación y asegúrese de que está firmado con el certificado de distribución correcta y no su adhoc uno. Aprender a usar la utilidad de línea de comandos, codesign, es útil para este tipo de comprobación y depuración. Al hacer la copia comprimida primero, se asegura de que no va a cambiar de ninguna manera la copia final que Xcode ha entregado usted y que subirá a itunesconnect, si todo se ve bien.

Otras cosas a recordar son el icono de la aplicación, los otros iconos y gráficos que necesita para la tienda iTunes store, la información.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 una de estas piezas que falta en el archivo comprimido que está construyendo (aquellas piezas que pertenecen al paquete de la aplicación).

Mira este documento de lista de verificación @ Github

Https://github.com/bapu/AppReleaseCheckList