[Xojo 2026r1] Firma de Apps macOS basada en Equipos

En Xojo 2026r1 hemos revisado el campo Developer ID para macOS y lo hemos sustituido por un menú popup basado en Equipos, equivalente al estilo que ya estaba disponible para los proyectos iOS desarrollados con Xojo. Su función es la de ofrecer un manejo más claro sobre todo lo relacionado con los certificados de desarrollador necesarios para un tipo de distribución deseada a la hora de compilar la app.

El campo Developer ID se introdujo por primera vez con Xojo 2022r1, de modo que fuese posible teclear o pegar la información esperada y correspondiente con el certificado de desarrollador a emplear durante la compilación de apps para macOS; pero lo cierto es que en muchos casos resultaba confuso sobre el tipo de información esperada. Por ejemplo, ¿cuál debería de introducirse?:

  • Developer ID Application
  • Developer ID Application: Francisco Javier Rodriguez Menendez
  • Developer ID Application: Francisco Javier Rodriguez Menendez (BW7PU32485)
  • 7D767DB917A45A8976BEB5B92F04E8C18D09501A

Y… ¿qué tipo de certificado debería de utilizar para compilar una app destinada a Desarrollador, Distribución Directa o su Publicación en la Mac App Store? Desde luego, nada sencillo para quienes no hubiesen utilizado antes los certificados de desarrollo.

Además, ¿y si la información introducida fuese la de un certificado ya expirado o si no se encontrase en el Llavero del Mac?

El nuevo enfoque: ¿cómo funciona?

El nuevo selector basado en Equipo para el campo Developer ID de Mac realiza los siguientes pasos:

  • Reúne todos los certificados de desarrollo encontrados en el Llavero del usuario.
  • Agrupa los certificados válidos por Equipo (lo que Apple denomina TeamID).

Basándose en la anterior información, el nuevo menú de tipo popup “Build For” ofrecerá sólo las opciones válidas de firmado de código correspondientes al equipo seleccionado:

  • Desarrollo. Este es el equivalente a utilizar el certificado Apple Development.
  • Distribución Directa. Es el equivalente a usar el certificado Developer ID Application.
  • App Store. Este es el equivalente a usar el certificado Apple Distribution. Además, la característica Publish del IDE se activará sólo si, además de dicho certificado, también está disponible el certificado 3rd Party Mac Developer Installer para el equipo seleccionado.

Si la opción None está seleccionada en el menú Popup correspondiente a Developer ID, entonces la app de macOS se compilará / depurará utilizando la firma “Ad-Hoc”.

Ambos menús se actualizan sobre la marcha, lo que significa que si se añaden (o borran) certificados del Llavero, entonces tanto los popup correspondientes a Developer ID y Build For se actualizarán para reflejar dichos cambios… e incluso si alguno de los certificados ha expirado desde la última vez que se accedió a dichos menus.

Ventana Inspector de Certificados macOS

Entre las opciones incluidas en el popup de Equipos también se encuentra la opción “Inspect…”. Al seleccionarla se abrirá una nueva ventana donde podrás ver información adicional sobre:

  • Certificados Intermedios instalados o ausentes.
  • Certificados de Desarrollador instalados, ausentes o expirados; agrupados por Equipo.

Podrás ver de un vistazo información útil sobre los certificados, como por ejemplo:

  • La fecha de expiración
  • El Llavero donde están guardados.
  • El número de serie, útil a la hora de identificar certificados de desarrollador o intermedios del mismo tipo, pero que se han creado en diferentes Mac.
  • Información específica sobre el emisor de los certificados.

Cuando se hace clic sobre cualquiera de los certificados, obtendrás información más detallada sobre el papel que juegan en el proceso de firmado para apps macOS.

Este inspector también resulta útil a ña hora de identificar algunos de los problemas más comunes relacionados con la gestión de los certificados; entre otros:

  • Certificados ausentes para un determinado Equipo, determinando por tanto las opciones disponibles bajo el menú popup correspondiente a “Build For”.
  • Certificados que han expirado. Estos también determinan las opciones disponibles bajo el menú popup “Build For” para un equipo dado. Además, si quieres hacer algo de limpieza, también es posible borrar dichos certificados expirados directamente desde este Inspector, sin la necesidad de tener que utilizar la app Acceso a Llaveros.
  • Certificados próximos a caducar, de modo que seas consciente de ello y del impacto que podría tener en apps que vayas a distribuir o bien sobre los Perfiles de Aprovisionamiento que ya hubieses creado.
  • Certificados sin Clave Privada. Estos no pueden utilizarse para el firmado de código, de modo que podrás reinstalarlos desde una copia de seguridad o bien instalar un nuevo certificado del mismo tipo.
  • Certificados de desarrollo en los que no se encuentre alguno de los certificados intermedios requeridos. En este caso podrás incluso instalar directamente el certificado intermedio ausente (se requiere de una conexión a Internet activa).

Mejoras en apps macOS compiladas o depuradas

Si bien el soporte de Sandboxing, Entitlements y Perfiles de Aprovisionamiento en las apps macOS no es una capacidad nueva de esta release, hemos hecho algunas mejoras en dichas áreas:

  • Ahora es posible depurar apps con Sandbox activado directamente desde el IDE.
  • Los Entitlements y Perfiles de Aprovisionamiento también se aplican cuando la app se depura desde el IDE.
  • Mejoras en el modo en el que se añaden y firman los Entitlements cuando se compila una app macOS; y también un mejor manejo de los entitlements y perfiles de aprovisionamiento (en el caso de que se requieran) añadidos por el usuario.

Las apps depuradas o compiladas pueden vincularse ahora con la app Instruments. Entre otras cosas, se puede utilizar Instruments para detectar cosas como fugas de memoria sobre la aplicación que se esté ejecutando. Sobre esto, el IDE añadirá automáticamente el entitlement requerido para que esto sea posible sólo cuando la app se depura desde el IDE o se compila utilizando las opciones “None” (firma Ad-Hoc), o bien la opción Development.

Cuando en el menú “Build For” se seleccionan las opciones Direct Distribution o App Store, entonces el entitlement requerido para que Instruments se pueda vincular a la app en ejecución sólo se aplicará cuando se está depurando desde el IDE. Si quieres poder ejecutar Instruments sobre una aplicación compilada y que esté firmada con los certificados Direct Distribution o App Store, entonces deberás de incluir el entitlement de forma explícita.

La explicación sobre dicha decisión se debe a que cuando el entitlement “get-tasks-allow” se define con el valor “True” (este es el requerido para que Instruments se pueda asociar con una app en ejecución), existen vulnerabilidades bien documentadas que podrían utilizarse para escalar privilegios o inyectar código en la app. No es algo que probablemente desees que ocurra en las apps que distribuyas.

Pensando en el futuro

Somos conscientes de que aún existen algunas áreas relacionadas con todo lo relacionado con el firmado de apps macOS (y iOS) que han de mejorarse, y de hecho ya estamos trabajando en ello. Entre tanto, confiamos que encuentres más fáciles de utilizar y comprender las mejoras relacionadas con el nuevo selector de Developer ID; especialmente si se trata de tu primera experiencia en el firmado y la distribución de tu recién creada app para macOS.

Quiero agradecer de forma especial a Richard Grafl por su ayuda y comentarios durante el ciclo beta de esta característica.

¡Feliz firmado de apps para macOS!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *