Avec la mise à jour Sequoia, macOS s’appuie désormais sur l’UUID des applications pour divers contrôles de confidentialité et de sécurité, tels que l’accès au réseau. Cette nouvelle fonctionnalité de macOS pourrait causer des problèmes du côté de l’utilisateur final, notamment en l’obligeant à réautoriser fréquemment les applications 4D finales. Pour y remédier, à partir de 4D 20 R9, chaque application 4D créée pour macOS dispose désormais de son propre UUID d’application. Ce changement garantit des contrôles d’accès mieux adaptés. Entrons dans les détails.

macOS Sequoia et les UUID d’application

Avec l’introduction de la version Sequoia, macOS base désormais certains paramètres de confidentialité et de sécurité sur les UUID des applications plutôt que sur leurs noms. Ainsi, si plusieurs applications partagent le même UUID, cela peut causer des problèmes dans les contrôles du système. Ceci est particulièrement pertinent pour l’accès au réseau local, comme expliqué dans cette note technique. Les paramètres concernés se trouvent dans la boîte de dialogue Paramètres du système, dans le panneau Réseau local de l’élément Confidentialité et sécurité :

UUID d’application unique

Avant 4D 20 R9, les applications 4D finales partageaient le même UUID que l’application 4D Volume Desktop ou 4D Server utilisée comme source.

Désormais, lors de la création d’une application, son UUID est automatiquement défini en utilisant une combinaison de l’application 4D source et de l’identifiant de votre application. Cela garantit que votre application est considérée comme unique sur les systèmes macOS et maintient le même UUID pour votre application tant que vous utilisez la même version de l’application source 4D.

Bien entendu, ce nouveau comportement s’applique également au composant Build4D !

Bonne nouvelle, vous n’avez rien à faire, rien à changer dans votre chaîne de construction, tout se fait automatiquement. En général, vous pouvez arrêter votre lecture ici, mais si vous en avez besoin, nous offrons un contrôle total de l’UUID ! Ceci est expliqué dans le paragraphe suivant.

Fonctions mises à jour

Pour prendre en charge cette nouvelle fonctionnalité, nous avons mis à jour la fonction File.getAppInfo() pour qu’elle renvoie l’UUID de l’application lorsqu’elle est appliquée à l’exécutable de l’application. Voici un exemple de code :

var $app:=File("/Applications/myApp.app/Contents/MacOS/myApp")
var $info:=$app.getAppInfo()


Et voici un exemple de résultat :

{
  "archs": [
    {
      "type": 16777223,
      "name": "x86_64",
      "uuid": "9C286FBFFAAA242FEBF462654C950ECF"
    },
    {
      "type": 16777228,
      "name": "arm64",
      "uuid": "8D8AA28824AACC558AB3D287A43EC53A"
    }
  ]
}

En outre, la fonction File.setAppInfo() a été améliorée pour vous permettre de définir votre propre UUID si vous le souhaitez. Voici comment procéder :

var $app:=File("/Applications/myApp.app/Contents/MacOS/myApp")
var $info:=$app.getAppInfo()
 
// regenerate uuids for all architectures
For each ($arch; $info.archs)
  $arch.uuid:=Generate UUID
End for each
 
// update the app with the new uuids
$app.setAppInfo($info)


Nous espérons que cette fonctionnalité améliorera l’expérience de l’utilisateur avec vos applications déployées, en veillant à ce qu’elles soient uniques et mieux intégrées dans les environnements macOS.

Bon codage !