Xcode

El camino para enviar la compilación a la App Store En la Parte 1 creamos el target de compilación para MAS, y en la Parte 2, los archivos de configuración y la bifurcación de código que separan ambos canales. Ahora el target FocusTimer MAS ya tiene una forma que se puede subir a la App Store. En esta última parte cerramos la serie preparando el camino para subir esa compilación a App Store Connect y viendo cómo verificar que ambos canales no se rompan en el futuro. ...

Convertir el target en uno de verdad “para MAS” En la Parte 1 registramos un Bundle ID exclusivo para MAS y duplicamos el target de compilación FocusTimer MAS. Pero ese target todavía no es más que una copia del target de distribución directa. La compilación de MAS debe diferenciarse de la de distribución directa en tres cosas. Entitlements — solo los permisos mínimos adecuados para la App Store Info.plist — quitar las claves de Sparkle y añadir los metadatos de la App Store Código — bifurcado para que compile aunque Sparkle no esté presente En este artículo separamos las tres. ...

Otro canal de distribución — la Mac App Store En la serie anterior cubrimos la configuración inicial para distribuir una app de macOS directamente con Developer ID. Con un certificado, la notarización, las actualizaciones automáticas de Sparkle y el alojamiento del feed de actualizaciones, podías ofrecer la descarga directa de un archivo .dmg sin pasar por la App Store. Esta serie cubre la configuración inicial para subir esa misma app también a la Mac App Store (MAS). Las dos formas de distribución no son excluyentes. Puedes operar una misma app simultáneamente por el canal de distribución directa y por el canal de la App Store. La App Store tiene la ventaja de que Apple se encarga del cobro, los reembolsos y la visibilidad en las búsquedas, y de que inspira más confianza a los usuarios, así que es habitual usarla en paralelo a la distribución directa. ...

La última pieza — dónde subir las actualizaciones En la Parte 1 preparamos el certificado Developer ID y la notarización, y en la Parte 2 la clave de firma de Sparkle. Ya tenemos los medios para firmar la app, notarizarla e incluso verificar la autenticidad de las actualizaciones. Sin embargo, en el lugar al que apunta el SUFeedURL (https://updates.example.com/appcast.xml) que escribimos en el Info.plist de la app en la Parte 2 todavía no hay nada. En esta última parte alojaremos el feed de actualizaciones que debe ir en ese sitio y terminaremos los ajustes de compilación para concluir toda la configuración inicial. ...

Las actualizaciones automáticas, y por qué hace falta una capa más de firma En la Parte 1 terminamos la configuración del certificado Developer ID y de la notarización. Con eso ya tenemos listo lo necesario para entregar la app al usuario por primera vez. Pero una app no se distribuye una sola vez y se acabó: hay que seguir publicando nuevas versiones que corrigen errores y añaden funciones. En el caso de una app de la Mac App Store, la App Store se encarga de las actualizaciones por ti. Las apps de distribución directa no funcionan así, de modo que tienes que incorporar tú mismo una función de actualización automática dentro de la app. En macOS, el estándar de facto para esta tarea es el framework de código abierto Sparkle. Si incorporas Sparkle, la app comprueba periódicamente un “feed de actualizaciones (appcast)” y, si hay una nueva versión, avisa al usuario, la descarga y la instala. ...