Notarisation sur macOS : modifications de la structure des composants

Le processus de notarisation de macOS continue d’évoluer. Malheureusement, la structure interne des composants 4D conçus avec 4D v11 – destinée à permettre une compatibilité multiplateforme – ne répond plus aux exigences introduites par Apple pour exécuter une application sur Mac Silicon, ce qui rend la notarisation des composants de plus en plus difficile.

Pour simplifier le processus de déploiement, nous avons mis à jour la structure des composants à partir de 4D 20 R8. Cette nouvelle structure de dossiers rend la notarisation et le déploiement aussi simples que le déploiement d’une application. Cependant, il y a une mise en garde importante : la structure mise à jour n’est pas compatible avec les anciennes versions de 4D (4D 20 R7 et antérieures), tandis que les anciens composants resteront compatibles avec les nouvelles versions de 4D.

Le composant Build4D a également été mis à jour pour refléter la nouvelle structure. Lorsque vous créez des composants, soyez prudent et assurez-vous que vous utilisez la bonne version de Build4D.

Rappel important: Les composants construits avec 4D 20 R7 ou une version antérieure peuvent rencontrer des erreurs lors de la notarisation. La solution recommandée est de mettre à jour vers 4D 20 R8.

La liste détaillée des modifications apportées à la structure des composants :

Tous les fichiers du composant se trouvent maintenant dans un dossier Contents.
Le fichier info.plist est désormais ajouté lors de la création d’un composant.
Certains champs sont automatiquement définis par 4D, en prenant leur contenu dans le fichier buildApp.4DSettings :

  • CFBundleDisplayName et CFBundleName seront définis avec le nom de l’application.
  • CFBundleShortVersionString et CFBundleVersion prendront la valeur de Versioning / Common / CommonVersion.
  • NSHumanReadableCopyright prendra la valeur de Versioning / Common / CommonCopyright.

 

Pour les composants construits avec le composant Build4D, ces champs prendront ces valeurs :

  • CFBundleDisplayName et CFBundleName prendront la valeur du nom de l ‘application.
  • Un copyright peut être défini et remplira le champ NSHumanReadableCopyright.
  • CFBundleShortVersionString et CFBundleVersion contiendront la version de l’application (au format x.x.x).

 

Si vous souhaitez en savoir plus sur la notarisation, vous pouvez lire cet article de blog qui vous expliquera tout.

Si vous avez des questions ou si vous avez besoin d’aide, n’hésitez pas à les poser sur le forum 4D. Nous sommes là pour vous aider à rendre cette transition aussi facile que possible.

Nicolas Brachfogel
- Product Owner & Senior Developer - Nicolas Brachfogel a rejoint 4D en 2017 en tant que développeur senior (4D Server et networking) et en tant que Product Owner pour gérer la mise en production d'Apple Silicon. Il est chargé de rédiger les user stories et de les traduire en spécifications fonctionnelles, ainsi que de s'assurer que les implémentations des fonctionnalités répondent aux besoins des clients. Diplômé de l'Institut Supérieur d'Informatique Appliquée (INSIA), Nicolas a commencé sa carrière en tant que développeur de logiciels en 2001. Après plusieurs années de programmation en Java et C++, il s'est spécialisé dans le développement client-serveur pour des sociétés de jeux vidéo. En tant que développeur/architecte serveur, il a travaillé avec succès sur les architectures serveur de nombreux jeux (Dofus Arena, Drakerz, Trivial Pursuit Go !).