Notarización en macOS: cambios en la estructura de los componentes

El proceso de notarización de macOS sigue evolucionando. Desafortunadamente, la estructura interna de los componentes 4D diseñada con 4D v11 – pensada para permitir la compatibilidad entre plataformas – ya no cumple con los requisitos introducidos por Apple para Macs basados en Silicon, haciendo que la notarización de componentes sea cada vez más difícil.

Para simplificar el proceso de despliegue, hemos actualizado la estructura de los componentes a partir de 4D 20 R8. Esta nueva estructura de carpetas hace que la notarización y el despliegue sean tan sencillos como desplegar una aplicación. Sin embargo, hay una advertencia importante: la estructura actualizada no es compatible con versiones anteriores de 4D (por ejemplo, 4D 20 R7 y anteriores), mientras que los componentes más antiguos seguirán siendo compatibles con las versiones más recientes de 4D.

El componente Build4D también ha sido actualizado para reflejar la nueva estructura. Cuando cree componentes, tenga cuidado y asegúrese de que está utilizando la versión correcta de Build4D.

Recordatorio importante: los componentes construidos con 4D 20 R7 o versiones anteriores pueden encontrar errores durante la notarización. La solución recomendada es actualizar a 4D 20 R8.

La lista detallada de los cambios en la estructura de los componentes:

Todos los archivos del componente están ahora dentro de una carpeta Contents.
El archivo info.plist se añade ahora durante la creación de un componente.
Algunos campos son configurados automáticamente por 4D en tiempo de compilación, tomando su contenido del archivo buildApp.4DSettings:

• CFBundleDisplayName y CFBundleName serán definidos con el nombre de la aplicación.
• CFBundleShortVersionString y CFBundleVersion tomarán el valor de Versioning / Common / CommonVersion
• NSHumanReadableCopyright tomará el valor de Versioning / Common / CommonCopyright

Para componentes construidos con el componente Build4D, estos archivos tomarán estos valores:

• CFBundleDisplayName y CFBundleName tomarán el valor del nombre de la aplicación.
• Se puede establecer un copyright que llenará el campo NSHumanReadableCopyright
• CFBundleShortVersionString y CFBundleVersion contendrán la versión de la aplicación (en el formato x.x.x)

Si quiere leer más sobre la notarización, puedes leer esta entrada del blog que explica todo.

Si tiene alguna duda o necesita más ayuda, por favor pregunte en el foro de 4D. Estamos aquí para ayudar a que esta transición sea lo más fácil posible.