Construire à partir des sources Qt pour Linux embarqué

Notes sur la plate-forme - iOS

Déploiement

Le développement, la construction, l'exécution et le débogage d'une application Qt pour iOS peuvent tous être effectués avec Qt Creator sur macOS. La chaîne d'outils est fournie par Xcode d'Apple, et l'exécution de qmake ou CMake sur un projet destiné à iOS générera également un fichier de projet Xcode (.xcodeproj), avec les paramètres initiaux de l'application. Comme Qt Creator ne fournit pas d'interface pour gérer tous les paramètres spécifiques à la plateforme iOS, il est parfois nécessaire de les ajuster directement dans Xcode. Il est particulièrement important de vérifier que l'application est correctement configurée avant de la soumettre pour publication dans l'App Store d'Apple.

Paquets d'applications

Les applications iOS sont généralement déployées sous la forme de paquets d'applications autonomes. Le paquet d'applications contient l'exécutable de l'application ainsi que les dépendances, telles que les bibliothèques Qt, les plugins, les traductions et les autres ressources dont l'application peut avoir besoin.

Pour construire votre application en tant que bundle d'application avec CMake, définissez la propriété MACOSX_BUNDLE sur votre cible exécutable, comme suit :

qt_add_executable(MyApp)
if(APPLE)
    set_target_properties(MyApp PROPERTIES MACOSX_BUNDLE TRUE)
endif()

Avec qmake, les bundles sont la valeur par défaut. Définissez CONFIG -= app_bundle dans votre fichier de projet (.pro) pour le désactiver.

Fichiers de la liste des propriétés de l'information

Le fichier de liste des propriétés des informations (Info.plist) sur iOS et macOS est utilisé pour configurer un bundle d'application. Ces paramètres de configuration comprennent :

le nom d'affichage et l'identifiant de l'application
les capacités requises de l'appareil
les orientations de l'interface utilisateur prises en charge
les icônes et les images de lancement

Pour plus de détails, voir la documentation sur le fichier de la liste des propriétés de l'information dans la bibliothèque du développeur iOS.

Info.plist avec CMake

CMake génère un fichier Info.plist par défaut si la propriété MACOSX_BUNDLE d'une cible est réglée sur TRUE. Malheureusement, ce fichier n'est pas adapté aux projets iOS.

À la place, les projets peuvent utiliser qt_add_executable, qui générera automatiquement un fichier Info.plist avec des valeurs par défaut adaptées aux projets iOS.

Pour spécifier un Info.plist personnalisé, les projets peuvent définir la propriété cible MACOSX_BUNDLE_INFO_PLIST comme indiqué ci-dessous. Cela désactivera la génération automatique du fichier fournie par qt_add_executable et utilisera à la place la gestion native de CMake pour le fichier Info.plist fourni par le projet.

qt_add_executable(app)
if(IOS)
    set_target_properties(app
        PROPERTIES MACOSX_BUNDLE_INFO_PLIST "${CMAKE_CURRENT_SOURCE_DIR}/ios/Info.plist")
endif()

Voir la documentation CMake MACOSX_BUNDLE_INFO_PLIST pour des informations sur les propriétés et variables cibles qui peuvent être spécifiées pour la substitution de modèle effectuée par CMake.

Info.plist avec QMake

Lorsque qmake est exécuté, un fichier Info.plist est généré avec les valeurs par défaut appropriées.

Il est conseillé de remplacer le fichier Info.plist généré par votre propre copie, afin d'éviter qu'il ne soit écrasé lors de la prochaine exécution de qmake. Vous pouvez définir une liste personnalisée de propriétés d'information avec la variable QMAKE_INFO_PLIST dans votre fichier .pro.

ios {
    QMAKE_INFO_PLIST = ios/Info.plist
}

Actifs de l'application

Pour les fichiers qui ne peuvent pas être regroupés dans les ressources Qt, la variable QMAKE_BUNDLE_DATA de qmake permet de spécifier un ensemble de fichiers à copier dans le paquet d'applications. Par exemple :

ios {
    fontFiles.files = $$files(fonts/*.ttf)
    fontFiles.path = fonts
    QMAKE_BUNDLE_DATA += fontFiles
}

Avec CMake, la même chose peut être faite de la manière suivante :

qt_add_executable(app)
file(GLOB_RECURSE font_files CONFIGURE_DEPENDS "fonts/*.ttf")
if(IOS AND font_files)
    target_sources(app PRIVATE ${font_files})
    set_source_files_properties(
        ${font_files}
        PROPERTIES MACOSX_PACKAGE_LOCATION Resources/fonts)
endif()

Pour les ressources images, une alternative consiste à utiliser les catalogues de ressources dans Xcode, qui peuvent être ajoutés de la manière suivante avec qmake :

ios {
    QMAKE_ASSET_CATALOGS += ios/Assets.xcassets
}

avec CMake :

qt_add_executable(app)
set(asset_catalog_path "ios/Assets.xcassets")
target_sources(app PRIVATE "${asset_catalog_path}")
set_source_files_properties(
    ${asset_catalog_path}
    PROPERTIES MACOSX_PACKAGE_LOCATION Resources)

Icônes

À partir de Xcode 13, les icônes doivent être ajoutées au jeu d'icônes d'un catalogue d'actifs, qui est généralement appelé AppIcon. Xcode se chargera ensuite de mettre à jour le fichier Info.plist avec les clés et les valeurs correctes, ainsi que de copier tous les fichiers d'icônes nécessaires directement dans le bundle de l'application.

À partir de Xcode 14, une seule image de 1024x1024 pixels est nécessaire. Xcode se charge de générer toutes les icônes nécessaires à partir de celle-ci. Il est également possible de spécifier les images manuellement dans le catalogue des ressources.

Une liste détaillée des icônes qui peuvent être spécifiées est disponible sur Icon files.

Le nom du fichier n'est pas important, mais la taille réelle en pixels l'est. Pour prendre en charge une application iOS universelle, les images suivantes sont nécessaires :

AppIcon60x60@2x.png: 120 x 120 (pour iPhone)
AppIcon76x76@2x~ipad.png: 152 x 152 (pour iPad)
AppIcon167x167.png: 167x167 (pour iPad Pro)
AppIcon1024x1024.png: 1024 x 1024 (pour l'App Store)

Les distributions ad hoc doivent également inclure les noms de fichiers suivants dans le paquet d'applications afin de visualiser l'application dans iTunes :

iTunesArtwork 512x512
iTunesArtwork@2x 1024x1024

La manière la plus simple d'ajouter les icônes est de suivre la documentation de Xcode à Créer des catalogues et des ensembles de ressources.

Lors de la construction d'un projet avec CMake, il faut également spécifier l'attribut Xcode suivant pour s'assurer que les icônes de l'application sont générées par Xcode.

set_target_properties(app_target_name PROPERTIES
    XCODE_ATTRIBUTE_ASSETCATALOG_COMPILER_APPICON_NAME AppIcon)

Voici un exemple de ce à quoi pourrait ressembler un fichier Assets.xcassets/AppIcon.appiconset/Contents.json pour Xcode 14 :

{
  "images" : [
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "2x",
      "size" : "20x20"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "3x",
      "size" : "20x20"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "2x",
      "size" : "29x29"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "3x",
      "size" : "29x29"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "2x",
      "size" : "38x38"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "3x",
      "size" : "38x38"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "2x",
      "size" : "40x40"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "3x",
      "size" : "40x40"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "2x",
      "size" : "60x60"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "3x",
      "size" : "60x60"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "2x",
      "size" : "64x64"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "3x",
      "size" : "64x64"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "2x",
      "size" : "68x68"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "2x",
      "size" : "76x76"
    },
    {
      "idiom" : "universal",
      "platform" : "ios",
      "scale" : "2x",
      "size" : "83.5x83.5"
    },
    {
      "filename" : "AppIcon1024x1024.png",
      "idiom" : "universal",
      "platform" : "ios",
      "size" : "1024x1024"
    }
  ],
  "info" : {
    "author" : "xcode",
    "version" : 1
  }
}

Écrans et images de lancement

Écrans de lancement

Chaque application iOS doit fournir un écran de lancement qui s'affiche au lancement de l'application. L'écran de lancement est un fichier de construction d'interface .xib, également appelé fichier storyboard. Pour plus d'informations, voir Spécifier l'écran de lancement de votre application.

La prise en charge des écrans de lancement a été introduite dans iOS 9.0.

qmake et CMake génèrent tous deux un écran de lancement par défaut appelé LaunchScreen.storyboard.

Pour spécifier un écran de lancement personnalisé, il doit être copié dans le paquet d'applications et la clé UILaunchStoryboardName doit être définie sur le nom de l'écran de lancement dans le fichier Info.plist.

Qt prend en charge les écrans de lancement personnalisés avec CMake depuis Qt 6.4, et avec qmake depuis Qt 6.0.

En supposant que le fichier de lancement s'appelle Launch.storyboard, il peut être ajouté à Info.plist comme suit :

<key>UILaunchStoryboardName</key>
<string>Launch</string>

Pour copier l'écran de lancement dans le paquet d'applications avec qmake, utilisez l'extrait de code suivant dans le fichier .pro de votre projet :

ios {
    QMAKE_IOS_LAUNCH_SCREEN = $$PWD/Launch.storyboard
}

Avec CMake :

qt_add_executable(app)
if(IOS)
    set_target_properties(app PROPERTIES
        QT_IOS_LAUNCH_SCREEN "${CMAKE_CURRENT_SOURCE_DIR}/Launch.storyboard")
endif()

Images de lancement

Il est également possible de spécifier des images de lancement (fichiers PNG) au lieu de l'écran de lancement.

Remarque : l'utilisation d'images de lancement n'est pas recommandée, car leur prise en charge est obsolète depuis iOS 13.0. Il est préférable d'utiliser les écrans de lancement.

Les images de lancement doivent être copiées dans le bundle de l'application et leurs noms doivent être définis dans le fichier Info.plist à l'aide de la clé UILaunchImages.

Les images suivantes doivent être préparées :

LaunchImage-iOS7-568h@2x.png : 640 x 1136
LaunchImage-iOS7-Landscape.png : 1024 x 768
LaunchImage-iOS7-Landscape@2x.png : 2048 x 1536
Image de lancement-iOS7-Portrait.png : 768 x 1024
LaunchImage-iOS7-Portrait@2x.png : 1536 x 2048
LaunchImage-iOS7@2x.png : 640 x 960

Les images peuvent être ajoutées à Info.plist comme suit :

<key>UILaunchImages</key>
<array>
    <dict>
        <key>UILaunchImageMinimumOSVersion</key>
        <string>7.0</string>
        <key>UILaunchImageName</key>
        <string>LaunchImage-iOS7</string>
        <key>UILaunchImageOrientation</key>
        <string>Portrait</string>
        <key>UILaunchImageSize</key>
        <string>{320, 568}</string>
    </dict>
    <dict>
        <key>UILaunchImageMinimumOSVersion</key>
        <string>7.0</string>
        <key>UILaunchImageName</key>
        <string>LaunchImage-iOS7</string>
        <key>UILaunchImageOrientation</key>
        <string>Portrait</string>
        <key>UILaunchImageSize</key>
        <string>{320, 480}</string>
    </dict>
</array>
<key>UILaunchImages~ipad</key>
<array>
    <dict>
        <key>UILaunchImageMinimumOSVersion</key>
        <string>7.0</string>
        <key>UILaunchImageName</key>
        <string>LaunchImage-iOS7-Landscape</string>
        <key>UILaunchImageOrientation</key>
        <string>Landscape</string>
        <key>UILaunchImageSize</key>
        <string>{768, 1024}</string>
    </dict>
    <dict>
        <key>UILaunchImageMinimumOSVersion</key>
        <string>7.0</string>
        <key>UILaunchImageName</key>
        <string>LaunchImage-iOS7-Portrait</string>
        <key>UILaunchImageOrientation</key>
        <string>Portrait</string>
        <key>UILaunchImageSize</key>
        <string>{768, 1024}</string>
    </dict>
    <dict>
        <key>UILaunchImageMinimumOSVersion</key>
        <string>7.0</string>
        <key>UILaunchImageName</key>
        <string>LaunchImage-iOS7</string>
        <key>UILaunchImageOrientation</key>
        <string>Portrait</string>
        <key>UILaunchImageSize</key>
        <string>{320, 568}</string>
    </dict>
    <dict>
        <key>UILaunchImageMinimumOSVersion</key>
        <string>7.0</string>
        <key>UILaunchImageName</key>
        <string>LaunchImage-iOS7</string>
        <key>UILaunchImageOrientation</key>
        <string>Portrait</string>
        <key>UILaunchImageSize</key>
        <string>{320, 480}</string>
    </dict>
</array>

Pour copier les images de lancement dans le bundle de l'application avec qmake, utilisez l'extrait de code suivant dans le fichier .pro de votre projet :

ios {
    app_launch_images.files = $$files($$PWD/ios/LaunchImage*.png)
    QMAKE_BUNDLE_DATA += app_launch_images
}

Avec CMake :

qt_add_executable(app)
file(GLOB_RECURSE launch_images CONFIGURE_DEPENDS "ios/LaunchImage*.png")
if(IOS AND launch_images)
    target_sources(app PRIVATE ${launch_images})
    set_source_files_properties(
        ${launch_images}
        PROPERTIES MACOSX_PACKAGE_LOCATION Resources)
endif()

Note : Les versions antérieures d'iOS permettaient de spécifier une seule image de lancement à l'aide de la clé UILaunchImageFile dans Info.plist, mais cette fonction n'est plus prise en charge depuis iOS 10.0.

Sélecteur d'images natif

Si votre fichier Info.plist contient une entrée pour NSPhotoLibraryUsageDescription, qmake inclura automatiquement un plugin supplémentaire qui permet d'accéder au sélecteur d'images natif.

Pour CMake, liez manuellement le sélecteur d'images natif avec qt_import_plugins:

qt_import_plugins(app INCLUDE Qt6::QIosOptionalPlugin_NSPhotoLibraryPlugin)

Si le répertoire de votre site QFileDialog est défini comme suit: :

QStandardPaths::standardLocations(QStandardPaths::PicturesLocation).last();

ou alternativement le currentFolder dans un FileDialog en QML à :

shortcuts.pictures

puis le sélecteur d'images natif est affiché pour permettre l'accès à l'album photo de l'utilisateur.

Expression des versions iOS prises en charge

Les plateformes Apple disposent d'un moyen intégré d'exprimer les versions du système d'exploitation prises en charge par une application, ce qui permet aux anciennes versions des plateformes d'afficher automatiquement un message d'erreur convivial invitant l'utilisateur à mettre à jour son système d'exploitation, au lieu de se bloquer et d'afficher une trace de la pile.

Les principaux concepts impliqués dans l'expression de la prise en charge d'une gamme particulière de versions de systèmes d'exploitation sont les suivants :

Lacible de déploiement spécifie la version minimale de macOS ou d'iOS que votre application prend en charge.
Laversion du SDK spécifie la version maximale souple de macOS ou d'iOS que votre application prend en charge.

Lorsque vous développez une application pour une plateforme Apple, vous devez toujours utiliser la dernière version de Xcode et le dernier SDK disponible au moment du développement. Sur certaines plateformes, comme iOS, vous serez rejeté de l'App Store si vous ne le faites pas. Par conséquent, la version du SDK est toujours supérieure ou égale à la cible de déploiement.

Lorsque vous développez une application pour une plateforme Apple, vous devez définir la cible de déploiement. Les différents outils de construction de la chaîne d'outils Xcode disposent tous d'un indicateur que vous pouvez utiliser pour définir cette valeur, y compris, mais sans s'y limiter, le compilateur et l'éditeur de liens. En définissant la valeur de la cible de déploiement, vous déclarez explicitement que votre application doit fonctionner au moins sur cette version, et qu'elle ne fonctionnera pas avec des versions antérieures du système d'exploitation. Il vous appartient alors de vous assurer que votre utilisation des API du système correspond à ce que vous avez déclaré. Comme le compilateur sait ce que vous avez déclaré, il peut vous aider à le faire respecter.

La version du SDK est considérée comme une version maximale souple du système d'exploitation avec laquelle une application est compatible. En effet, si l'application est construite avec un SDK, elle continuera à utiliser les comportements de ce SDK même sur des versions plus récentes du système d'exploitation, car le système d'exploitation vérifie les commandes de chargement du binaire et émule la rétrocompatibilité avec l'ancien système d'exploitation. Par exemple, si une application est construite avec le SDK macOS 10.12, elle continuera à utiliser les comportements de la version 10.12 même sur les versions 10.13 et supérieures.

Cependant, les binaires Mach-O sont intrinsèquement compatibles avec le futur. Par exemple, une application construite avec le SDK iOS 9 fonctionnera très bien sur iOS 10, mais ne pourra pas bénéficier des changements de comportement apportés à certaines fonctionnalités de la nouvelle version, jusqu'à ce que cette application soit recompilée avec ce SDK plus récent.

La version minimale du système d'exploitation peut être exprimée au système par les drapeaux du compilateur et de l'éditeur de liens qui l'intègrent dans le binaire Mach-O. En outre, la clé LSMinimumSystemVersion doit être définie dans le paquet d'applications de l'application. Cette valeur doit être égale à la valeur transmise au compilateur et à l'éditeur de liens, car sur macOS, elle permettra au système d'exploitation d'afficher une boîte de dialogue d'erreur conviviale indiquant que l'application nécessite une version plus récente du système d'exploitation, plutôt qu'une boîte de dialogue de plantage. L'adresse LSMinimumSystemVersion est également la clé utilisée par l'App Store pour afficher la version du système d'exploitation requise ; les drapeaux du compilateur et de l'éditeur de liens n'ont aucun pouvoir à cet égard.

Dans la plupart des cas, les applications Qt fonctionneront sans problème. Par exemple, dans qmake, les mkspecs Qt définissent QMAKE_IOS_DEPLOYMENT_TARGET ou QMAKE_MACOSX_DEPLOYMENT_TARGET à la version minimale que Qt lui-même supporte. De même, dans Qbs, les modules Qt fixent cpp.minimumIosVersion, cpp.minimumMacosVersion, cpp.minimumTvosVersion, ou cpp.minimumWatchosVersion à la version minimale que Qt supporte lui-même.

Cependant, vous devez faire attention lorsque vous définissez manuellement votre propre version cible. Si vous la définissez à une valeur supérieure à celle requise par Qt XML et que vous fournissez votre propre fichier Info.plist, vous devez ajouter une entrée LSMinimumSystemVersion à Info.plist qui corresponde à la valeur de la cible de déploiement, car le système d'exploitation utilisera la valeur LSMinimumSystemVersion comme faisant autorité.

Si vous spécifiez une valeur de cible de déploiement inférieure à celle requise par Qt, l'application se plantera presque certainement quelque part dans les bibliothèques Qt lorsqu'elle sera exécutée sur une version plus ancienne que celle prise en charge par Qt. Par conséquent, assurez-vous que le code du système de construction reflète la version minimale du système d'exploitation qui est réellement requise.

Publication sur l'App Store d'Apple

Vérifier que votre application Qt pour iOS est prête à être publiée sur l'App Store peut être fait comme décrit dans Soumettre l'application. Pour soumettre l'application, vous pouvez utiliser Xcode ou l'Application Loader (installé avec Xcode). Qt Creator ne fournit pas d'interface pour gérer tous les paramètres d'une configuration de projet Xcode.

L'application doit être testée sur les versions iOS et les appareils qu'elle est censée prendre en charge. La cible de déploiement minimale pour les applications Qt varie selon la version de Qt. Pour plus d'informations, voir les configurations prises en charge.

Le processus de publication proprement dit implique la création d'un certificat de distribution et d'un profil de mise à disposition, la création d'une archive signée de votre application et l'exécution d'une série de tests de validation.

Pour plus d'informations, voir le Guide de distribution des applications dans la bibliothèque des développeurs iOS.

Avertissements relatifs à la visibilité des symboles

Dans le contexte de la liaison des bibliothèques C++, les fonctions et les objets sont appelés symboles. Les symboles peuvent avoir une visibilité de default ou de hidden.

Pour des raisons de performance, Qt XML et de nombreuses autres bibliothèques compilent leurs sources en utilisant par défaut la visibilité hidden, et ne marquent les symboles avec la visibilité default que lorsqu'ils sont destinés à être utilisés dans des projets d'utilisateurs.

Malheureusement, l'éditeur de liens d'Apple peut émettre des avertissements lorsqu'une bibliothèque est compilée avec la visibilité hidden et qu'une application ou une bibliothèque d'un projet d'utilisateur est compilée avec la visibilité default.

Si les développeurs de projets veulent faire taire l'avertissement, ils doivent également compiler le code de leur projet avec la visibilité hidden.

Dans CMake, cela peut être fait en ajoutant le code suivant au fichier CMakeLists.txt:

set(CMAKE_CXX_VISIBILITY_PRESET hidden)

Dans qmake, cela peut être fait en ajoutant le code suivant à votre fichier .pro:

CONFIG+=hide_symbols

Si un projet construit des bibliothèques, tous les symboles de la bibliothèque qui sont destinés à être utilisés dans une autre bibliothèque ou application devront être explicitement marqués avec la visibilité default. Par exemple, cela peut être fait en annotant ces fonctions ou classes avec Q_DECL_EXPORT.

Problème d'archivage des produits avec CMake

En raison d'un problème dans CMake, essayer de créer une archive de produit avec une application iOS peut échouer.

Cela peut se produire à la fois en essayant de créer l'archive dans Xcode en utilisant l'élément de menu Product -> Archive, ou à partir de la ligne de commande en utilisant xcodebuild -archivePath.

Le message d'erreur peut faire référence à des symboles non définis ou à des chemins de fichiers inexistants.

Pour contourner le problème, assurez-vous de construire une version Release du projet avant d'essayer de créer une archive.

Le bundle dSYM est manquant dans l'archive xc créée par un projet CMake Xcode.

En raison d'un bogue dans Xcode et de certaines limitations de CMake, un projet Xcode généré par CMake ne parvient pas à inclure le bundle dSYM d'une application dans une archive xcarchive, au cours de la tâche d'archivage de Xcode.

Qt XML fournit une solution de contournement sous forme d'opt-in, de sorte que le bundle dSYM est inclus dans le xcarchive, mais elle s'accompagne de compromis. En effet, les fonctionnalités CMake suivantes ne fonctionneront pas correctement :

toutes les expressions du générateur $<TARGET_FILE:app> peuvent se développer en un chemin invalide qui ne mène pas au binaire de l'application
la variable CMAKE_RUNTIME_OUTPUT_DIRECTORY et la propriété RUNTIME_OUTPUT_DIRECTORY target qui lui est associée seront ignorées même si elles sont définies.
autres problèmes inconnus

Pour atténuer les problèmes susmentionnés, vous pouvez :

activer la solution de contournement uniquement lorsque vous avez l'intention de créer le site xcarchive et non pendant le développement du projet
vous assurer que vous n'ajoutez des exécutables et des bibliothèques que dans le répertoire racine du projet, et non dans les appels add_subdirectory.

Pour activer la solution de contournement, configurez le projet avec l'option suivante :

cmake . -DQT_USE_RISKY_DSYM_ARCHIVING_WORKAROUND=ON

ou définissez la variable dans le projet avant tout appel à qt_add_executable ou qt_add_library:

set(QT_USE_RISKY_DSYM_ARCHIVING_WORKAROUND ON)

...

qt_add_executable(app)

Construire à partir des sources Qt pour Linux embarqué

© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.