Recommandations pour les applications iOS

27 février 2018

Lors du développement d’applications iOS, utilisez ces recommandations pour améliorer la compatibilité entre XenMobile et les applications mobiles pour appareils iOS.

Infrastructure du SDK Worx App et encapsulation

Si votre application utilise l’infrastructure du SDK Worx App, vous devez utiliser la version de l’outil MDX Toolkit correspondante pour l’encapsulation. Une différence de version entre ces deux composants peut entraîner un fonctionnement incorrect.

Pour éviter ce type d’incohérence, encapsulez l’application en tant qu’application ISV et spécifiez un mode d’application Premium ou General. Cette configuration vous permet de mettre à disposition une application préencapsulée. Par conséquent, le client n’a pas besoin d’encapsuler l’application, ce qui évite l’utilisation d’un MDX Toolkit de version différente. Pour de plus amples informations sur l’encapsulation ISV, consultez la section Encapsulation des applications mobiles iOS dans la documentation du MDX Toolkit.

Utiliser des ID d’application explicites

Si votre compte iOS Developer Enterprise ne prend pas en charge les ID d’application génériques, vous devez créer un ID d’application explicite pour chaque application que vous voulez encapsuler avec le MDX Toolkit et créer un profil de provisioning pour chaque ID d’application.

Ne pas bloquer le thread principal

Vous ne devriez pas utiliser de code de blocage lors de l’exécution sur le thread principal. Il s’agit d’une recommandation Apple, mais elle est encore plus importante avec XenMobile. Certaines actions peuvent prendre plus de temps dans une application gérée ou même bloquer l’exécution d’autres threads. Les opérations de fichier, de base de données et de réseau sont des exemples d’opérations qui peuvent bloquer le thread en cours d’exécution et doivent être évitées sur le thread principal.

Écrire un code robuste

En particulier, vous devriez écrire des applications en suivant les recommandations indiquées dans les guides de programmation d’Apple, tels que le Guide de programmation d’applications Apple.

Utilisez uniquement des interfaces publiées par Apple.

Vérifiez toujours les valeurs renvoyées pour tous les appels API et gérez les exceptions qui peuvent être provoquées par l’appel API, pour garantir une récupération normale après erreur ou la fermeture normale de l’application. Bien que ce soit une recommandation courante en programmation, elle est particulièrement importante pour les applications gérées.

Plusieurs API qui fonctionnent généralement sans problème échouent si la fonctionnalité sous-jacente a été bloquée en raison de stratégies XenMobile. Les fonctionnalités décrites précédemment en sont des exemples :

  • Les API de réseau échouent comme s’il n’existait aucun réseau disponible.
  • Les API de détection, telles que le GPS et l’appareil photo, renvoient une valeur null ou une exception.

Les sélecteurs d’exécution Objective-C suivants renvoient une valeur null si la fonctionnalité sous-jacente a été bloquée en raison de stratégies XenMobile et doivent être traités en conséquence.

Classe d’objet Nom du sélecteur
AVCaptureDevice devicesWithMediaType:
MFMailComposeViewController init:
MFMessageComposeViewController initWithNibName:bundle:
NSFileManager URLForUbiquityContainerIdentifier:
NSUbiquitousKeyValueStore defaultStore:
PHPhotoLibrary sharedPhotoLibrary:
UIImagePickerController availableCaptureModesForCameraDevice:
UIPasteboard dataForPasteboardType:
  valueForPasteboardType:
  items:
  dataForPasteboardType:inItemSet:
  valuesForPasteboardType:inItemSet:
UIPopoverController initWithContentViewController:
UINavigationController ctxInitWithRootViewController:
  ctxPopToViewController:animated:

Rediriger les interfaces d’exécution

XenMobile propose une invite à entrer le code PIN de sorte que vous n’avez pas besoin de le faire dans votre application.

Pour assurer la disponibilité de XenMobile, il est recommandé de ne pas rediriger ou remplacer les sélecteurs d’exécution Objective-C étant donné que XenMobile mélange les méthodes sous-jacentes de plusieurs sélecteurs de classes d’objet pour contrôler et/ou modifier le comportement d’exécution d’une application. Le tableau suivant dresse la liste des sélecteurs de classes Objective-C que XenMobile redirige :

Nom de la classe d’objet Nom du sélecteur
NSURLProtectionSpace serverTrust
NSURLAuthenticationChallenge sender
NSURLConnection sendSynchronousRequest:returningResponse:error:
  initWithRequest:delegate:startImmediately:
  initWithRequest:delegate:
  connectionWithRequest:delegate:
NSURLConnectionDelegate connection:canAuthenticateAgainstProtectionSpace:
  connection:didReceiveAuthenticationChallenge:
  connection:willSendRequestForAuthenticationChallenge:
NSURLSessionConfiguration defaultSessionConfiguration
  ephemeralSessionConfiguration
ALAssetsLibrary authorizationStatus
AVAudioRecorder record
  prepareToRecord
  recordForDuration:
  recordAtTime:
  recordAtTime:ForDuration:
AVAudioSession recordPermission
AVCaptureDevice devices
  devicesWithMediaType:
AVAsset assetWithURL:
AVURLAsset initWithURL:options:
  URLAssetWithURL:options:
AVPlayerItem playerItemWithAsset:
  initWithURL:
  playerItemWithURL:
AVPlayer playerWithPlayerItem:
  initWithPlayerItem:
  initWithURL:
CLLocationManager startUpdatingLocation
UIScrollView setContentOffset:
MFMailComposeViewController canSendMail
  init
MFMessageComposeViewController canSendText
  initWithNibName:bundle:
NSFileManager URLForUbiquityContainerIdentifier:
NSUbiquitousKeyValueStore defaultStore
PHPhotoLibrary authorizationStatus
QLPreviewController setDataSource:
  canPreviewItem:
QLPreviewControllerDataSource numberOfPreviewItemsInPreviewController:
  previewController:previewItemAtIndex:
SLComposeViewController isAvailableForServiceType:
UIActivityViewController initWithActivityItems:applicationActivities:
  setExcludedActivityTypes:
UIApplication openURL:
  canOpenURL:
  setApplicationIconBadgeNumber:
UIDocument closeWithCompletionHandler:
  contentsForType:error:
UIDocumentInteractionController interactionControllerWithURL:
  setURL:
  setDelegate:
  presentPreviewAnimated:
  presentOpenInMenuFromBarButtonItem:animated:
  presentOpenInMenuFromRect:inView:animated:
  presentOptionsMenuFromBarButtonItem:animated:
  presentOptionsMenuFromRect:inView:animated:
UIDocumentMenuViewController initWithDocumentTypes:inMode:
UIImage imageNamed:
UIImagePickerController setSourceType:
  takePicture
  startVideoCapture
  isSourceTypeAvailable:
  isCameraDeviceAvailable:
  isFlashAvailableForCameraDevice:
  availableCaptureModesForCameraDevice:
  setMediaTypes
UINavigationController ctxInitWithRootViewController:
  ctxPushViewController:animated:
  ctxPopToViewController:animated:
UIPasteboard generalPasteboard
  pasteboardWithName:create:
  pasteboardWithUniqueName
  setValue:forPasteboardType:
  setData:forPasteboardType:
  setItems:
  addItems:
  dataForPasteboardType:
  valueForPasteboardType:
  numberOfItems
  pasteboardTypes
  pasteboardTypesForItemSet:
  containsPasteboardTypes:
  containsPasteboardTypes:inItemSet:
  items
  itemSetWithPasteboardTypes:
  dataForPasteboardType:inItemSet:
  valuesForPasteboardType:inItemSet:
  string
  strings
  URL
  URL
  image
  images
  color
  colors
UIPopoverController initWithContentViewController
UIPrintInteractionController isPrintingAvailable
  presentAnimated:completionHandler:
  presentFromBarButtonItem:animated:completionHandler:
  presentFromRect:inView:animated:completionHandler:
UIViewController presentViewController:animated:completion:
UIWebView loadRequest:
  setDelegate:
UIWebViewDelegate webView:shouldStartLoadWithRequest:navigationType:
  webViewDidStartLoad:
  webViewDidFinishLoad:
  webView:didFailLoadWithError:
UIWindow makeKeyAndVisible
UIApplicationDelegate applicationDidFinishLaunching:
  application:didFinishLaunchingWithOptions:
  application:willFinishLaunchingWithOptions:
  applicationWillResignActive:
  applicationDidEnterBackground:
  applicationWillEnterBackground:
  applicationDidBecomeActive:
  applicationWillTerminate:
  application:openURL:sourceApplication:annotation:
  application:handleOpenURL:
  applicationProtectedDataWillBecomeUnavailable:
  applicationProtectedDataDidBecomeAvailable:
  application:performFetchWithCompletionHandler:
  application:handleEventsForBackgroundURLSession:completionHandler:
  application:didReceiveLocalNotification:
  application:didReceiveRemoteNotification:
  application:didReceiveRemoteNotification:fetchCompletionHandler:
  application:didRegisterForRemoteNotificationsWithDeviceToken:
  application:didFailToRegisterForRemoteNotificationsWithError:
  applicationSignificantTimeChange:
  application:shouldAllowExtensionPointIdentifier:
QLPreviewController allocWithZone:

Cryptage des données et iOS 9

Important :

Les applications encapsulées avec le MDX Toolkit 10.0.x ne fonctionneront pas sur iOS 9. Les développeurs doivent encapsuler de nouveau les applications ISV avec le MDX Toolkit 10.2. Les utilisateurs doivent installer les applications mises à niveau avant la mise à niveau de leurs appareils vers iOS 9. Si les utilisateurs essaient d’ouvrir sur iOS 9 des applications qui ont été encapsulées avec le MDX Toolkit 10.0.x, ils ne pourront pas mettre à niveau ces applications et devront réinstaller une version de ces applications encapsulées avec le MDX Toolkit 10.2.

En raison de modifications dans iOS 9, le cryptage MDX n’est pas compatible avec iOS9 pour les données téléchargées sur un appareil iOS 9 à partir d’une application encapsulée. Apple requiert un code secret pour crypter toutes les données des applications sur l’appareil à l’aide du cryptage de fichier iOS. Vous pouvez choisir l’une des options suivantes pour protéger les données :

  • Par défaut, les applications encapsulées requièrent un code PIN ou un code secret sur un appareil iOS 9.
  • En plus d’exiger la saisie d’un code PIN ou d’un code secret, vous pouvez également spécifier une classe de protection des données minimum qui est utilisée pour les données applicatives sauf si un niveau de protection plus élevé est déjà spécifié dans iOS.

Pour prendre en charge le niveau iOS de protection, le MDX Toolkit 10.2 comprend une nouvelle stratégie, Code secret de l’appareil, qui nécessite la saisie d’un code PIN ou d’un code secret sur un appareil iOS 9. Cette stratégie est activée par défaut. La stratégie s’applique à chaque application individuelle et peut être utilisée si vous exécutez XenMobile en mode MDM ou MAM.

Les applications encapsulées avec le MDX Toolkit 10.2 utilisent le cryptage MDX pour les bases de données et le trousseau Sqlite uniquement. Les bases de données Sqlite constituent la base sous-jacente d’Apple Core Data Persistent Storage, un modèle plus complexe. Les autres modèles Apple Core Data dépendent des objets fichier dans le système de fichier Apple du sandbox des applications.

Autres stratégies et iOS 9 :

  • La fonctionnalité d’entropie de l’utilisateur, qui est activée à l’aide de la clé Encrypt secrets using Passcode, n’est pas affectée par iOS 9. Le trousseau et le coffre sécurisé de l’appareil ne sont pas affectés.
  • Sur les appareils iOS 9, la stratégie Activer le chiffrement permet le cryptage de la base de données et du trousseau uniquement. Sur les anciens appareils iOS, la stratégie Activer le chiffrement permet encore le cryptage de fichier MDX.
  • Pour une protection supplémentaire sur les appareils avec un code secret de périphérique activé, le SDK Worx App comprend également un niveau élevé de cryptage iOS pour les fichiers que ces applications stockent sur l’appareil. Le cryptage de fichier iOS possède plusieurs niveaux de protection des données. La nouvelle stratégie Classe de protection des données minimum vous permet de spécifier une classe de protection qui est utilisée pour les données d’applications sauf si un niveau de protection des données plus élevé a déjà été spécifié dans iOS. Les valeurs de stratégie sont :

Complète sauf si le fichier a déjà été ouvert : si un fichier est ouvert lorsqu’un appareil est verrouillé, le fichier continue d’être accessible par l’application. Cette valeur correspond à la classe NSFileProtectionCompleteUnlessOpen. Valeur par défaut.

Complète : lorsqu’un appareil est verrouillé, les fichiers deviennent indisponibles. Cette valeur correspond à NSFileProtectionComplete.

Jusqu’au premier déverrouillage : lorsqu’un appareil redémarre, les fichiers sont verrouillés et ne peuvent pas être lus tant que l’utilisateur n’a pas déverrouillé l’appareil pour la première fois. Cette valeur correspond à NSFileProtectionCompleteUntilFirstUserAuthentication.

Aucune : les fichiers ne sont dotés d’aucune protection spéciale et sont accessibles en lecture ou écriture à tout moment. Cette valeur correspond à NSFileProtectionNone.

Important : les développeurs doivent veiller à tester les applications encapsulées qui effectuent un traitement en arrière-plan, tel que l’actualisation du contenu sur un appareil verrouillé ou les synchronisations en arrière-plan.

Cette stratégie est masquée. Pour rendre la stratégie visible dans XenMobile, ouvrez le fichier policymetadata.xml pour l’application (dans Applications/Citrix/MDXToolkit/data) et, dans la section MinimumDataProtectionClass, modifiez la valeur de PolicyHidden sur false. Après avoir encapsulé votre application, la stratégie s’affiche lorsque vous ajoutez l’application à XenMobile.

Expérience utilisateur :

  • Lorsqu’un utilisateur effectue une mise à niveau vers une application encapsulée avec MDX Toolkit 10.2, puis démarre l’application, Worx invite l’utilisateur à créer un code secret de périphérique, si aucun n’existe. Worx décrypte ensuite les fichiers cryptés avec MDX existants et utilise le cryptage de fichier iOS pour sécuriser les fichiers.
  • Si les utilisateurs essaient d’ouvrir sur iOS 9 des applications qui ont été encapsulées avec le MDX Toolkit 10.0.x, ils ne pourront pas mettre à niveau ces applications et devront réinstaller une version de ces applications encapsulées avec le MDX Toolkit 10.2.

Assurer la compatibilité du cryptage de données

L’une des fonctionnalités principales de MDX est que toutes les données conservées sont cryptées de façon transparente. Vous n’avez pas besoin de modifier votre application pour bénéficier de cette fonctionnalité, et en fait, vous ne pouvez pas directement l’éviter. L’administrateur XenMobile a la possibilité de désactiver le cryptage de manière sélective ou complètement, mais pas l’application.

Ceci est l’un des aspects plus complexes de MDX et il est important de comprendre les points suivants :

  • Le cryptage de fichier est présent pour l’ensemble du code natif qui s’exécute dans les processus gérés.

    La mise en œuvre du cryptage des données de fichier concerne l’ensemble du code natif et pas seulement le code des applications utilisant les infrastructures Apple et l’exécution d’Apple Objective-C. Tout cryptage de données de fichier mis en œuvre dans et uniquement pour l’exécution d’Objective-C peut être facilement détourné.

  • Certaines API d’infrastructure, telles que la classe AVPlayer, la classe UIWebView et QLPreviewController, sont en fait mises en œuvre par les processus de service iOS dans un contexte d’exécution différent du processus d’application gérée de l’utilisateur.

    Ces processus de service ne sont pas capables de déchiffrer les données de fichier cryptées par MDX, donc l’application gérée doit fournir le processus de service avec une copie temporaire non cryptée des données qui est ensuite supprimée par l’application au bout de 5 secondes. Il est important que vous connaissiez cette limitation si vous utilisez ces classes car nous perdons le contrôle de la contention des données fournies à ces classes à cause de la mise en œuvre par Apple de ces classes spécifiques.

  • Le mappage de mémoire est problématique pour le cryptage XenMobile car il implique l’appel par l’application des interfaces d’appel du système E/S du fichier.

    Une fois qu’un fichier est mappé en mémoire, les requêtes E/S pour le fichier sont gérées en dehors du contexte de l’application utilisateur, ignorant le cryptage de XenMobile. Tous les appels mmap(2) POSIX par une application gérée sont mappés comme MAP_PRIVATE et MAP_ANON et ne sont pas associés à une description de fichier. Une tentative de lecture de toutes les données mappées lors de l’appel mmap échoue pour toutes les données si une description de fichier est spécifiée car toute pagination suivante des données par le système d’exploitation entraîne la lecture des données cryptées sans qu’elles soient décryptées par XenMobile. Cette technique a réussi dans toutes les applications qui ont été testées avec XenMobile car le volume de données qui est mappé en mémoire est faible sans récupération des pages mémoire dans l’application.

  • Le cryptage ajoute une charge significative. Les développeurs devraient optimiser le traitement E/S disque pour empêcher la dégradation des performances. Par exemple, si vous lisez et écrivez de manière répétée les mêmes informations, il se peut que vous souhaitiez mettre en place un cache au niveau de l’application.

  • XenMobile crypte uniquement les instances de la libsqlite.dylib d’Apple. Si l’application établit un lien direct et/ou incorpore une version privée de la libsqlite.dylib, les instances de bases de données de cette bibliothèque privée ne seront pas cryptés par XenMobile.

  • Les bases de données Apple SQLite sont cryptées par XenMobile à l’aide de la couche VFS de SQLite.

    Vous pouvez rencontrer un problème de performance. La taille du cache de base de données standard est 2 000 pages ou 8 Mo. Si votre base de données est volumineuse, il peut être nécessaire qu’un développeur spécifie une commande pragma SQLite pour augmenter la taille du cache de la base de données. Dans Objective-C Core Data Framework, la commande pragma SQLite peut être ajoutée en tant que dictionnaire d’options lors de l’ajout de l’objet Persistent Store à l’objet Persistent Store Controller.

  • Le mode SQLite WAL n’est pas pris en charge car la bibliothèque est de nouveau liée aux interfaces E/S de fichier et en interne utilise le mappage de mémoire de façon extensive.

  • NSURLCache DiskCache est mis en œuvre par iOS à l’aide d’une base de données SQLite. XenMobile désactive le cache disque associé, car cette base de données est référencée par des processus de service iOS non gérés.

  • Le tableau suivant dresse la liste des modèles de nom de chemin d’accès de fichier exclus codés en dur :

       
    .plist Exclu en raison d’un accès par les processus système iOS en dehors du contexte de processus.
    .app Sous-chaîne d’ancienne génération dans le nom du bundle de l’application. Cette sous-chaîne est obsolète, car un chemin d’accès de bundle d’application explicite est désormais exclu.
    .db Un fichier avec ce suffixe n’est pas crypté si le fichier n’est pas une base de données sqlite.
    /System/Library Les chemins d’accès aux fichiers dans le répertoire sandbox du bundle d’application et les chemins d’accès aux fichiers en dehors du sandbox des données d’application ne peuvent pas être cryptés. Sur iOS, l’application installée est en lecture seule et se trouve dans un répertoire différent de celui des fichiers de données de l’application que l’application produit et stocke lorsqu’elle est exécutée.
    Library/Preferences Les fichiers sont accessibles directement par iOS. Normalement, seuls les fichiers .plist sont présents dans ce répertoire.
    /com.apple.opengl/ Les fichiers sont accessibles directement par iOS.
    csdk.db Base de données Citrix SSLSDK sqlite ancienne version
    /Library/csdk.sql Base de données Citrix SSLSDK sqlite
    CtxLog_ Préfixe du nom du fichier journal Citrix
    CitrixMAM.config Nom de fichier interne MDX
    CitrixMAM.traceLog Nom de fichier interne MDX ancienne version
    CtxMAM.log Nom de fichier interne MDX
    data.999 Nom de fichier interne MDX
    CTXWrapperPersistentData Nom de fichier interne MDX
    /Documents/CitrixLogs Répertoire de journaux MDX
    /Document/CitrixLogs.zip Nom du répertoire de journaux MDX compressés
    Tout fichier dans le chemin d’accès au répertoire du bundle d’application Répertoire en lecture seule des fichiers de l’application
  • XenMobile remplace une instance de la classe XenMobile SecureViewController privée par des instances de la classe d’objet Apple Objective-C QLPreviewController au moment de l’exécution. La classe XenMobile SecureViewController est dérivée de la classe d’objet Apple Objective-C UIWebView. La classe d’objet QLPreviewController prend en charge en mode natif quelques formats de fichier que la classe d’objet UIWebView ne prend pas en charge en mode natif, tels que les types audio et pdf.

  • Pour obtenir les meilleures performances, les requêtes E/S de fichier doivent être émises à des offsets de fichier qui sont un multiple de 4 096 octets et doivent être émises pour une longueur qui est également un multiple de 4 096 octets.

  • L’indicateur de mode de fichier O_NONBLOCK n’est pas pris en charge par le cryptage XenMobile. Cet indicateur est supprimé de la liste des modes lors du traitement par XenMobile.

Entropie utilisateur

Une option de cryptage XenMobile nécessite que l’utilisateur entre un code PIN avant que la clé de cryptage puisse être générée. Cette option est appelée entropie utilisateur. Elle peut entraîner un problème particulier pour les applications.

Plus spécifiquement, aucun accès fichier ou base de données ne peut être effectué jusqu’à ce que l’utilisateur entre un code PIN. Si une telle opération E/S est présente à un emplacement qui s’exécute avant que l’interface utilisateur du code PIN puisse être affichée, elle échouera toujours.

Pour vous assurer que ce problème ne concerne pas votre application, testez-la avec l’entropie utilisateur activée. La propriété du client XenMobile, Encrypt secrets using Passcode, ajoute l’entropie utilisateur. Vous pouvez configurer cette propriété de client, qui est désactivée par défaut, dans la console XenMobile, sous Configurer > Paramètres > Plus > Propriétés du client.

Compatibilité de la contention des données

  • Les contrôleurs d’affichage à distance n’ont pas de contention de sécurité (par exemple, le cryptage de données, le blocage de la stratégie copier/couper/coller, et ainsi de suite) car un contrôleur d’affichage à distance s’exécute dans un contexte de processus différent de l’application gérée par MDX.
  • L’action Copier est la seule action prise en charge depuis UIResponder. Les autres actions, telles que Couper et Supprimer, ne sont pas prises en charge.
  • Airdrop est intercepté uniquement au niveau de l’interface utilisateur, et non pas à un niveau inférieur.
  • MFI et Bluetooth ne sont pas interceptés.

Prise en charge des fichiers d’icônes

L’encapsulation MDX requiert la présence d’au moins une icône qui peut être utilisée comme icône springboard ou icône d’application. Les développeurs d’applications peuvent ajouter leurs icônes au catalogue de logiciels, ou utiliser les clés CFBundleIcons ou CFBundleIconFiles du fichier Info.plist.

Le MDX Toolkit choisira la première clé dans la liste des emplacements plist connus du fichier Info.plist :

  • CFBundleIcons
  • CFBundlePrimaryIcon
  • CFBundleIconFiles
  • UINewsstandIcon
  • CFBundleDocumentTypes

Si aucune de ces clés n’est trouvée dans Info.plist, le MDX Toolkit identifiera l’une des icônes suivantes dans le dossier racine du bundle d’application :

  • Icon.png
  • Icon-60@2x.png
  • Icon-72.png
  • Icon-76.png

Réseau et micro VPN

MDX gère actuellement uniquement les appels réseau directement émis par une application. Certaines requêtes DNS sont émises directement par l’infrastructure Apple et ne sont donc pas gérées par MDX.

Les administrateurs disposent de plusieurs options de stratégie XenMobile pour le réseau. La stratégie Accès réseau empêche, permet ou redirige l’activité réseau de l’application comme suit :

  • Par défaut, le réseau est complètement bloqué pour une application. Si la stratégie Accès réseau est définie sur Bloqué, les API de réseau utilisées par votre application échouent. Conformément à la recommandation précédente, vous devriez traiter un tel échec de façon appropriée.
  • Si la stratégie Accès réseau est définie sur Non restreint, tous les appels réseau ont un accès direct et ne sont pas tunnélisés.
  • Si la stratégie Accès réseau est définie sur Tunnélisé vers le réseau interne, tous les appels réseau sont tunnélisés via NetScaler Gateway. Dans cette stratégie, le tunneling est contrôlé par la stratégie Mode VPN préféré.

La stratégie Mode VPN préféré définit le mode initial des connexions qui sont tunnelisées sur le réseau interne.

  • Si la stratégie Mode VPN préféré est définie sur Navigation sécurisée, l’URL http/https est réécrite. Le mode Navigation sécurisée peut uniquement tunnéliser le trafic http et https. Un avantage important de Navigation sécurisée est l’authentification unique (SSO) pour le trafic http et https ainsi que l’authentification PKINIT. Sur Android, Navigation sécurisée a une charge de configuration faible et il s’agit donc de l’option préférée pour les opérations de type navigation Web.
  • Si la stratégie Mode VPN préféré est définie sur Tunnel VPN complet, tout le trafic provenant de l’application gérée est tunnélisé via NetScaler Gateway.

Limitations :

  • WkWebView n’est pas pris en charge.
  • Les utilisateurs ne peuvent pas lire de vidéos hébergées sur des sites Web internes dans les applications iOS MDX encapsulées car les vidéos sont lues dans un processus de lecteur multimédia sur l’appareil que MDX n’intercepte pas.
  • Le téléchargement en arrière-plan NSURLSession (NSURLSessionConfiguration backgroundSessionConfigurationWithIdentifier) n’est pas pris en charge.
  • Nous bloquons le trafic UDP si la stratégie Accès réseau est définie sur Bloqué. Nous ne tunnélisons pas le trafic UDP si la stratégie Accès réseau est définie sur Tunnélisé vers le réseau interne.
  • Les applications encapsulées par MDX ne peuvent pas ajouter un serveur socket qui écoute les connexions entrantes. Toutefois, les applications encapsulées par MDX peuvent utiliser un socket client pour se connecter à un serveur.

Prise en charge des bibliothèques tierces

Certaines infrastructures d’applications ont des problèmes de compatibilité avec XenMobile :

  • Les applications développées avec l’environnement de développement multi-plateformes Xamarin sont prises en charge. Citrix ne déclare pas officiellement la prise en charge d’autres environnements de développement multi-plateformes en raison d’exemples insuffisants d’utilisation et de test.
  • SQLCipher ne fonctionne pas avec le cryptage car il utilise le mappage de mémoire. Une solution consiste à ne pas utiliser SQLCipher. Une autre solution consiste à exclure le fichier de base de données du cryptage à l’aide d’une stratégie d’exclusion de cryptage. Un administrateur XenMobile doit configurer la stratégie dans la console XenMobile.
  • Les bibliothèques d’applications et tierces qui lient directement aux bibliothèques OpenSSL libcrypto.a et libssl.a peuvent entraîner une erreur de lien en raison d’un manque de symboles et des erreurs de lien en raison de définitions de symbole multiples.
  • Les applications nécessitant une prise en charge du service de notification push d’Apple devront suivre les étapes spécifiques requises par Apple.
  • XenMobile définit de manière explicite la version de la base de données SQLite sur 1 pour désactiver la prise en charge des fichiers WAL (Write Ahead Logging) et des fichiers mappés en mémoire dans les bases de données SQLite. Toute tentative d’accéder directement aux interfaces SQLite version 2 ou 3 échoue.