Freigeben über

iOS 9-Kompatibilität

Auch wenn Sie ihrer App nicht sofort iOS 9-Features hinzufügen möchten, sollten Sie Ihre Apps mit der neuesten Version von Xamarin neu erstellen.

Wichtig

Die Informationen auf dieser Seite richten sich an Kunden mit Apps, die sich bereits im App Store für iOS 8 oder früher befinden und noch keine Updates für die iOS 9-Kompatibilität übermittelt haben. Wenn Sie bereits die neuesten Versionen – Xcode 7 und Xamarin.iOS 9 – für ihre App-Entwicklung verwenden, besuchen Sie die Einführung in iOS 9.

Als die ersten Betaversionen von iOS 9 erschienen sind, haben wir zwei Probleme mit älteren Versionen von Xamarin identifiziert, die sich als ältere Apps manifestierten, die unter iOS 9 nicht gestartet werden können:

  • Apps, die für iOS 8 oder früher erstellt werden, können nicht auf 32-Bit-Geräten gestartet werden (einschließlich Apps, die mit der einheitlichen API erstellt wurden).
  • P/Invoke-Fehler mit dem vollständigen Pfad ist nicht angegeben.

Wenn Sie Ihre Xamarin-Installation auf das neueste Stable Channel-Release aktualisieren und dann Ihre Apps neu erstellen und erneut bereitstellen, werden diese beiden Probleme behoben.

Auch wenn Sie nicht planen, Ihre App sofort mit iOS 9-Features zu aktualisieren, empfiehlt es sich, die neueste Version von Xamarin neu zu erstellen und erneut an die App Store zu übermitteln.

Dadurch wird sichergestellt, dass Ihre App nach dem Upgrade Ihrer Kunden unter iOS 9 ausgeführt wird. Sie können iOS 8 weiterhin unterstützen. Die Neuerstellung mit dem neuesten Release wirkt sich nicht auf die Zielversion der Anwendung aus.

Wenn Sie weitere Probleme beim Testen Ihrer vorhandenen Apps unter iOS 9 haben, lesen Sie den Abschnitt Verbesserung der Kompatibilität weiter unten.

Aktualisieren mit Visual Studio

Es wird empfohlen, explizit zu überprüfen, ob Visual Studio auf die neueste Stable-Version aktualisiert wurde.

Was ist mit Komponenten, NuGets und anderen Bibliotheken?

Sie müssen nicht auf neue Versionen von Komponenten oder NuGets warten, die Sie verwenden, um die beiden oben genannten Probleme zu beheben. Diese Probleme werden behoben, indem Sie Ihre App einfach mit der neuesten Stable-Version von Xamarin.iOS neu erstellen.

Ebenso müssen Komponentenhersteller und NuGet-Autoren keine neuen Builds übermitteln, nur um die beiden oben genannten Probleme zu beheben. Wenn jedoch eine Komponente oder NuGet Ansichten aus Xib-Dateien verwendet UICollectionView oder lädt, ist möglicherweise ein Update erforderlich, um die unten aufgeführten iOS 9-Kompatibilitätsprobleme zu beheben.

Verbessern der Kompatibilität in Ihrem Code

Es gibt einige Fälle von Codemustern, die früher in älteren Versionen von iOS funktionierten, die in iOS 9 unterbrochen wurden. Im Folgenden finden Sie einige mögliche Probleme (und deren Lösungen), die beim Testen unter iOS 9 auftreten können:

UICollectionViewCell.ContentView ist in Konstruktoren NULL

Grund: In iOS 9 ist der initWithFrame: Konstruktor jetzt erforderlich, da sich das Verhalten in iOS 9 geändert hat, wie es in der UICollectionView-Dokumentation heißt. Wenn Sie eine Klasse für den angegebenen Bezeichner registriert haben und eine neue Zelle erstellt werden muss, wird die Zelle nun durch Aufrufen der - initWithFrame: Methode initialisiert.

Lösung: Fügen Sie den initWithFrame: Konstruktor wie folgt hinzu:

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

Verwandte Beispiele: MotionGraph, TextKitDemo

UIView kann beim Laden einer Ansicht aus einem Xib/Nib nicht mit coder initieren.

Grund: Der initWithCoder: Konstruktor wird aufgerufen, wenn eine Ansicht aus einer Xib-Datei des Schnittstellen-Generators geladen wird. Wenn dieser Konstruktor nicht exportiert wird, kann nicht verwalteter Code unsere verwaltete Version davon nicht aufrufen. Zuvor (z. B. in iOS 8) wurde der Konstruktor aufgerufen, um die IntPtr Ansicht zu initialisieren.

Lösung: Erstellen und exportieren Sie den initWithCoder: Konstruktor wie folgt:

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

Verwandtes Beispiel: Chat

Dyld Message: kein Cacheimage mit Namen...

Es kann zu einem Absturz mit den folgenden Informationen im Protokoll kommen:

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

Grund: Dies ist ein Fehler im nativen Linker von Apple, der auftritt, wenn ein privates Framework öffentlich gemacht wird (JavaScriptCore wurde in iOS 7 öffentlich gemacht, davor war es ein privates Framework), und das Bereitstellungsziel der App ist für eine iOS-Version, wenn das Framework privat war. In diesem Fall wird der Linker von Apple mit der privaten Version des Frameworks und nicht mit der öffentlichen Version verknüpft.

Lösung: Dies wird für iOS 9 behandelt, aber es gibt eine einfache Problemumgehung, die Sie in der Zwischenzeit selbst anwenden können: Verwenden Sie einfach eine spätere iOS-Version in Ihrem Projekt (In diesem Fall können Sie iOS 7 ausprobieren). Andere Frameworks können ähnliche Probleme aufweisen, z. B. das WebKit-Framework wurde in iOS 8 veröffentlicht (daher führt die Ausrichtung auf iOS 7 zu diesem Fehler. Sie sollten iOS 8 als Ziel verwenden, um WebKit in Ihrer App zu verwenden).

  • Last updated on