Firma de código en macOS: Lo que los Desarrolladores han de saber, Parte 4

En el artículo anterior vimos como la firma de aplicaciones macOS involucra más partes que simplemente la gestión de certificados, principalmente porque intervienen otras piezas del puzzle en función del tipo de distribución que tengas prevista para tu app, e incluso de las características que dicha aplicación pueda ofrecer.

Ahora que ya sabemos cuáles son todas las partes involucradas (Certificados, Sandboxing, Notarización, Hardened Runtime, etc.), la siguiente pregunta que deberíamos responder sería…

¿Qué tipo de firma de código quieres hacer hoy?

Los Certificados de Desarrollo de Apple instalados (disponibles) en tu Mac determinan el tipo de firmado y, por tanto, el tipo de distribución que podrás hacer para tu app macOS; e incluso si dichas apps pueden soportar algunos de los requerimientos de seguridad de Apple que deberían de aplicarse en función del tipo de distribución seleccionado y/o las características que deberían de añadirse a la mezcla cuando se vaya a firmar la app (piensa por ejemplo en los entitlements o los perfiles de aprovisionamiento).

Este diagrama te resultará de ayuda a la hora de determinarlas en función del certificado utilizado para firmar la app, de modo que puedas tener una mejor idea:

Como resumen práctico:

Ad-Hoc signing / None: sólo tiene sentido cuando estés desarrollando la app en tu Mac y ejecutándola desde el IDE (es decir, depurándola) o bien cuando ejecutes una compilación en tu propio ordenador… siempre que la app propiamente dicha no requiera del uso de entitlements o perfiles de aprovisionamiento específicos para su funcionamiento.
Apple Developer / Development. Cuando se utiliza este certificado podrás aplicar capacidades como Sandboxing, Hardened Runtime, Entitlements y perfiles de aprovisionamiento incluso cuando estés depurando la app desde el IDE o bien quieras probar la compilación resultante en tu propio ordenador. Esto te ofrecerá una mejor experiencia. Aun así, aún no podrás Notarizarla o pasar la barrera de Gatekeeper en el caso de que la distribuyas a otros usuarios.
Developer ID Application / Direct Distribution. Cuando utilizas este certificado podrás Notarizar la app, lo que significa que Gatekeeper no se quejará cuando la distribuyas a otros usuarios utilizando canales distintos a la Mac App Store. Además, cuando se depure la app desde el IDE, se aplicarán los Entitlements y perfiles de aprovisionamiento que hayas indicado (si procede); además del opcional Sandboxing.
Apple Distribution / App Store. El uso de este certificado sólo es recomendable cuando hayas testeado la app en profundidad y esté lista para su envío a la App Store Connect, de modo que Apple pueda revisarla y permitir que esté disponible en la Mac App Store… o incluso si tienes previsto permitir que tus beta-testers la puedan probar mediante el servicio TestFlight de Apple.

¿Cómo ayuda el IDE de Xojo con todo esto?

A lo largo de los años hemos ido añadiendo características al IDE para permitir que todo lo relacionado con la firma de aplicaciones macOS sea un proceso más sencillo y limpio; la mayoría de estas disponibles desde Build Settings > macOS > Sign:

Developer ID – Build For

Supone la incorporación más reciente para facilitar todo lo relacionado con la pieza principal (y más importante) del puzzle: ¡la gestión de los certificados! Así, en vez de que tengas que cambiar entre la aplicación Acceso a Llaveros y el IDE para averiguar qué certificado necesitas y copiar los datos requeridos para pegarlos en el IDE en función del tipo de compilación o distribución que desees realizar.

En vez de ello, ahora podrás encontrar bajo el campo Developer ID todos los equipos de desarrollo disponibles (en la mayoría de los casos, probablemente sólo el tuyo) para, posteriormente, una vez que se haya seleccionado un equipo determinado, encontrar en el menú desplegable “Build For” las opciones de compilación/distribución disponibles para dicho equipo en particular.

Cuando todos los certificados de desarrollo de Apple se encuentran instalados correctamente para un equipo determinado, las opciones disponibles serán: Development, Direct Distribution y App Store (además de None, equivalente a la firma Ad-Hoc).

Si observas que no está presente alguna de estas opciones en el menú desplegable “Build For”, entonces significará que el certificado correspondiente no está instalado o bien que existe algún tipo de problema con dicho certificado en concreto (puede que haya expirado o le falte la clave privada asociada). Para este tipo de casos, hemos incluido la opción “Inspect…” en el menú desplegable “Developer ID”. Al seleccionar dicha opción se mostrará una ventana en la que podrás ver todos los certificados que presenten problemas para un equipo determinado, y también obtener una serie de consejos para solucionar el problema detectado en cada caso.

Sandboxing

Activa esta capacidad si tienes previsto depurar/compilar/distribuir tu app bajo esta modalidad. En este caso, el Editor asociado te facilitará seleccionar las capacidades de sandboxing que se apliquen a tu app en particular. El IDE se encargará dle resto. Ten en cuenta que, si bien el Sandboxing sólo se aplicaba a las apps compiladas/distribuidas en las anteriores versiones de Xojo, a partir de Xojo 2026r1 también se aplicará cuando se depura la app desde el IDE.

Hardened Runtime

Activa esta opción principalmente para las apps que vayas a compilar y/o distribuir utilizando las opciones Direct Distribution o bien App Store. Si bien es opcional cuando se distribuye la app mediante la Mac App Store, es muy recomendable que actives dicha capacidad también en dicho escenario.

Cuando la app se esté depurando desde el IDE, no se aplicará Hardened Runtime incluso si estuviese activado… principalmente ¡para que puedas depurarla!

Al igual que ocurre con el Sandboxing, la opción Hardened Runtime también cuenta con su propio editor asociado para facilitar la selección de capacidades específicas para tu app. El IDE se encargará de aplicar todo lo necesario cuando compiles la aplicación, de forma totalmente transparente.

Notarización

Si aún no estabas aplicando la notarización a tus apps de macOS… ¡es el momento de que empieces a hacerlo! (Apple ha reforzado MUCHO las medidas de seguridad, especialmente desde macOS Sequoia). La notarización sólo es posible cuando se utiliza la opción “Direct Distribution” (equivalente al uso del certificado Developer ID Application), e implica la activación de Hardened Runtime… de modo que cuando se activa la opción de Notarización, también se activará Hardened Runtime.

La Notarización requiere el uso de lo que Apple denomina una “contraseña específica de aplicación”, siendo dicho proceso algo que puedes realizar siguiendo los pasos disponibles en la ventana que se muestra cuando se hace clic sobre el botón de Setup asociado.

Una vez que esté todo correctamente configurado, el proceso de Notarización se aplicará la próxima vez que compiles tu app. Además, dicho proceso no tendrá lugar cuando estés depurando la app desde el IDE (tal y como también ocurre con Hardened Runtime), de modo que no tienes por qué desactivar la Notarización de forma específica para dicho caso.

Entitlements

La combinación de algunas de las opciones de Certificados/Compilación/Distribución que puedas elegir para tu app puede que requieran definir una serie de Entitlements; tal y como ocurre por ejemplo cuando se activan Sandboxing o Hardened Runtime. Además, a partir de Xojo 2026r1 es posible permitir que la app Instruments de Apple se asocie con el proyecto que estés depurando desde el IDE de Xojo, lo que te permitirá realizar inspecciones adicionales de depuración que aun no están soportadas por el depurador de Xojo.

En todos los escenarios descritos Xojo se encargará de aplicar los entitlements requeridos sin que tengas que intervenir; pero si tu app incluye capacidades que requieran del uso de entitlements adicionales (y probablemente la incorporación del perfil de aprovisionamiento asociado), tal y como ocurre si se hace uso de servicios de Apple como iCloud, Keychain, o compras desde la app, etc., entonces tendrás que crear el archivo .plist correspondiente y añadirlo utilizando la opción User Entitlements. Dichos entitlements se combinarán automáticamente con los generados por Xojo y se aplicarán durante el proceso de firma de código para tu app.

Provisioning Profiles

Los perfiles de aprovisionamiento en macOS están soportados mediante un paso de compilación Copy Files, y requiere seleccionar Contents como la carpeta de destino. No es algo ideal, pero de esta forma puedes seleccionar el tipo de perfil de aprovisionamiento que se utilizará cuando compiles tu app o bien cuando la estés depurando desde el iDE (de hecho, esta es una nueva capacidad disponible a partir de Xojo 2026r1).

Property List Editor

Si bien Xojo ya soportaba la inclusión de tus propias entradas para el listado de propiedades en tus apps macOS compiladas/distribuidas, ahora encontrarás un completo Editor de Lista de Propiedades integrado en el IDE desde Build Settings > macOS (desde Xojo 2025). Esto facilita enormemente la creación de este tipo de entradas, e incluso guardarlas en un archivo externo de modo que puedas reutilizarlas en otros proyectos.

Las entradas que añadas mediante el Editor de Lista de Propiedades se combinarán con las generadas automáticamente por el IDE o incluso aquellas otras que puedas haber añadido en el proyecto utilizando las capacidades soportadas con anterioridad (básicamente, añadir un archivo .plist externo al Navegador del proyecto).

Publicar a la Mac App Store

Si bien algunos de los pasos han de realizarse en el Portal de Desarrollo de Apple y en el portal App Store Connect, podrás definir la categoría de tu app directamente desde el IDE de Xojo desde Build Settings > macOS.

Además, la característica Publish (responsable de enviar tu app a App Store Connect) se encargará de realizar una verificación previa al envío, para asegurarse de que el proyecto cumple con los requerimientos básicos requeridos por Apple como paso previo a su envío y posterior revisión por parte de Apple, o bien su uso mediante la característica TestFlight.

Para que el botón Publish esté activado tendrás que seleccionar la opción App Store en el menú desplegable “Build For” correspondiente al equipo seleccionado en “Developer ID” desde Build Settings > macOS > Sign.

Resolución de problemas comunes con los Certificados

No importa si tu app requiere de Entitlements, perfiles de aprovisionamiento o si vas a notarizarla o bien distribuirla con Sandboxing y Hardened Runtime. Todo ello se basa en la firma de la aplicación mediante los Certificados de Desarrollo, así que veamos como puedes solucionar algunos de los problemas más comunes relacionados con estos.

Crea copias de seguridad de tus Certificados

Una vez que instales tus certificados, lo primero que deberías de hacer es exportarlos desde la app Acceso a Llaveros a un lugar seguro (idealmente, no en tu ordenador sino en una llave USB o unidad externa). ¿Por qué? Veamos algunos escenarios:

Apple sólo permite crear certificados un máximo de cinco veces por año (principalmente porque esta es la duración válida de este tipo de certificados antes de que expiren). Cada vez que instalas tus certificados, ya sea en el mismo ordenador o bien un Mac diferente que también poseas, estos serán certificados diferentes (es decir, tendrán un número de serie diferente así como una huella SHA1 / SHA256 distinta). En la práctica esto significa que se reducirá el número de instalaciones permitidas por año.
Además, algunas de las características como los perfiles de aprovisionamiento se basan en los certificados que hayas seleccionado durante su creación… de modo que obtendrás un mensaje de error cuando compiles la app en un Mac que tenga instalados otros certificados diferentes.
Si necesitas restaurar tu Mac o bien migrar a un nuevo Mac, los certificados no se restaurarán utilizando las herramientas habituales de Apple. El hecho de contar con una copia de seguridad para tus Certificados de desarrollo te permitirá restaurarlos (instalarlos de nuevo) en la app Acceso a Llaveros una vez que haya finalizado la restauración del Mac o bien cuando cambies a un nuevo Mac.

Así que, en vez de utilizar Xcode para instalar nuevos certificados en cada uno de los Mac que tengas y vayas a utilizar para el firmado de tus apps, instálalos sólo en uno de tus Mac, expórtalos desde ese Mac… e importarlos mediante la app Acceso a Llaveros en el resto de tus Mac. De esta forma todos ellos estarán utilizando el mismo juego de certificados.

Revisa los Acuerdos Pendientes de Apple

Es uno de los problemas más frecuentes relacionados con la firma de código: simplemente deja de funcionar y tu no sabes el por qué… e incluso los mensajes de error devueltos no revelan la causa real del problema. Si estás seguro de que todos tus certificados están instalados, y que estos son válidos y no presentan ningún problema, entonces es el momento de acceder a tu cuenta de desarrollador en el portal de Desarrollo de Apple y en App Store Connect para comprobar que no haya ningún acuerdo de Apple pendiente de confirmar.

Certificados no instalados o expirados

Se trata de otro problema bastante frecuente. Desde Xojo 2026r1 hemos facilitado mucho más el hecho de detectar este tipo de circunstancias (entre otras). Si no está instalado un certificado determinado para un equipo, entonces no podrás seleccionar la opción de firma/distribución correspondiente desde el menú desplegable “Build For” en Build Settings > macOS > Sign. Incluso podrás indagar más seleccionando la opción “Inspect…” en el menú desplegable asociado con “Developer ID”, e incluso recibir consejos sobre cómo solucionar los certificados señalados como problemáticos.

Los Certificados están bien… pero aun obtienes mensajes de error

Cuando se utilizan las opciones “Direct Distribution” o “App Store” el proceso de firmado de código utiliza los servidores de fecha y hora de Apple para datar la firma propiamente dicha. Esto significa que el ordenador ha de contar con una conexión activa a Internet… y que dichos servidores estén en funcionamiento (siendo lo habitual).

Otras operaciones, como la Notarización y Publicación a App Store Connect, también requieren de una conexión activa a Internet y de que los servicios de Apple responsables de estas funcionalidades estén en funcionamiento.

Cuando obtienes errores con este tipo de operaciones, siempre es buena idea consultar la página web correspondiente al estado de los servicios de Apple.

En resumen

Ha sido un largo viaje de cuatro artículos con la esperanza de que ahora tengas una mejor idea y comprensión sobre los aspectos fundamentales relacionados con el firma y distribución de aplicaciones macOS; el tipo de certificados necesarios a la hora de realizar un tipo de distribución determinada y también el tipo de características de seguridad que están soportadas por los certificados Development, Developer ID Application o Apple Distribution. Y, lo más importante, ¡el modo en el que Xojo te ayuda con todo ello!

Me encantaría conocer tu experiencia relacionada con el firmado de tus apps macOs, así como las dificultades que aun estén encontrando y otras mejoras que te gustaría ver implementadas en este área. Los foros de Xojo son un lugar excelente en el que podemos continuar con la conversación.

¡Feliz programación y firmado de apps macOS con Xojo!