Compatibilité iOS 9

Même si vous n’envisagez pas d’ajouter immédiatement des fonctionnalités iOS 9 à votre application, vous devez reconstruire vos applications avec la dernière version de Xamarin.

Lorsque les premières versions bêta d’iOS 9 sont apparues, nous avons identifié deux problèmes liés aux anciennes versions de Xamarin qui se manifestaient comme des applications plus anciennes ne pouvant pas démarrer sur iOS 9 :

• Les applications générées pour iOS 8 ou version antérieure ne peuvent pas démarrer sur les appareils 32 bits (y compris les applications créées avec l’API unifiée).
• P/Invoke défaillant avec le chemin d’accès complet n’est pas spécifié.

La mise à jour de votre installation de Xamarin vers la dernière version du canal stable, puis la reconstruction et le redéploiement de vos applications corrigent ces deux problèmes.

Même si vous n’envisagez pas de mettre à jour votre application avec les fonctionnalités iOS 9 immédiatement, nous vous recommandons de regéner avec la dernière version de Xamarin et de le soumettre à nouveau à l’App Store.

Cela garantit que votre application s’exécutera sur iOS 9 après la mise à niveau de vos clients. Vous pouvez continuer à prendre en charge iOS 8 . La reconstruction avec la dernière version n’affecte pas la version cible de l’application.

Si vous rencontrez d’autres problèmes lors du test de vos applications existantes sur iOS 9, lisez la section Amélioration de la compatibilité ci-dessous.

Mise à jour avec Visual Studio

Il est recommandé de case activée explicitement que Visual Studio est mis à jour vers la dernière version stable.

Qu’en est-il des composants, des nugets et d’autres bibliothèques ?

Vous n’avez pas besoin d’attendre les nouvelles versions des composants ou des nugets que vous utilisez pour résoudre les deux problèmes mentionnés ci-dessus. Ces problèmes sont résolus simplement en regénérant votre application avec la dernière version Stable de Xamarin.iOS.

De même, les fournisseurs de composants et les auteurs NuGet ne sont pas tenus de soumettre de nouvelles builds uniquement pour résoudre les deux problèmes mentionnés ci-dessus. Toutefois, si un composant ou NuGet utilise UICollectionView ou charge des vues à partir de fichiers Xib , une mise à jour peut être nécessaire pour résoudre les problèmes de compatibilité iOS 9 mentionnés ci-dessous.

Amélioration de la compatibilité dans votre code

Il existe quelques cas de modèles de code qui fonctionnaient dans les versions antérieures d’iOS cassant dans iOS 9. Voici quelques problèmes possibles (et leurs solutions) qui peuvent survenir lors du test sur iOS 9 :

UICollectionViewCell.ContentView a la valeur Null dans les constructeurs

Raison: Dans iOS 9, le initWithFrame: constructeur est désormais requis, en raison des changements de comportement dans iOS 9, comme indiqué dans la documentation UICollectionView. Si vous avez inscrit une classe pour l’identificateur spécifié et qu’une nouvelle cellule doit être créée, la cellule est maintenant initialisée en appelant sa initWithFrame: méthode.

Difficulté: Ajoutez le initWithFrame: constructeur comme suit :

[Export ("initWithFrame:")]
public YourCellClassName (CGRect frame) : base (frame)
{
    Initialize (); // refactor initialize code into a method
}

Exemples connexes : MotionGraph, TextKitDemo

UIView ne parvient pas à s’init avec le codeur lors du chargement d’une vue à partir d’un Xib/Nib

Raison: Le initWithCoder: constructeur est celui appelé lors du chargement d’une vue à partir d’un fichier Xib du générateur d’interface. Si ce constructeur n’est pas exporté, le code non managé ne peut pas appeler notre version managée de celui-ci. Auparavant (par exemple, dans iOS 8), le IntPtr constructeur était appelé pour initialiser la vue.

Difficulté: Créez et exportez le initWithCoder: constructeur comme suit :

[Export ("initWithCoder:")]
public YourClassName (NSCoder coder) : base (coder)
{
    Initialize (); // refactor initialize code into a method
}

Exemple connexe : Conversation

Message Dyld : aucune image de cache avec nom...

Vous pouvez rencontrer un blocage avec les informations suivantes dans le journal :

Dyld Error Message:
Dyld Message: no cache image with name (/System/Library/PrivateFrameworks/JavaScriptCore.framework/JavaScriptCore)

Raison: Il s’agit d’un bogue dans l’éditeur de liens natif d’Apple, qui se produit lorsqu’ils rendent une infrastructure privée publique (JavaScriptCore a été rendu public dans iOS 7, avant qu’il s’agissait d’une infrastructure privée), et que la cible de déploiement de l’application est pour une version iOS lorsque l’infrastructure était privée. Dans ce cas, l’éditeur de liens d’Apple sera lié à la version privée de l’infrastructure au lieu de la version publique.

Difficulté: Cela sera résolu pour iOS 9, mais il existe une solution de contournement facile que vous pouvez appliquer vous-même en attendant : il vous suffit de cibler une version iOS ultérieure dans votre projet (vous pouvez essayer iOS 7 dans ce cas). D’autres frameworks peuvent présenter des problèmes similaires, par exemple l’infrastructure WebKit a été rendue publique dans iOS 8 (et le ciblage d’iOS 7 entraîne donc cette erreur ; vous devez cibler iOS 8 pour utiliser WebKit dans votre application).

Liens associés

• Informations sur la version de compatibilité iOS 9
• Introduction à iOS 9
• Mise à jour de vos applications Xamarin.iOS vers iOS9 (vidéo)