Je reçois également ce problème, nous utilisons: Xamarin.Forms 3.6.0.539721

Chaque version de Forms l'obtiendra car WebViewRenderer dans iOS implémente UIWebView, et le fichier reste même si vous basculez sur WkWebViewRenderer. Je ne sais pas s'il existe un moyen de lier ce fichier pendant la construction.

@ swansca79 - c'est à peu près ce dont j'avais peur. J'espère que nous pourrons le relier comme vous le dites.

Quelle est la date limite d'Apple pour cette exigence? Je n'ai pas pu en trouver ...

Je suppose que cela affecte toutes les applications, qu'il s'agisse de nouvelles soumissions ou de mises à jour. Si tel est le cas, quel est l'intérêt de relier l'ancien moteur de rendu? Il doit être supprimé du code source. En outre, nous devons savoir s'il s'agit d'une exigence iOS 13 ou non ...

Même problème ici. J'utilise Xamarin.Forms 4.2.0.709249

J'ai ajouté la ligne suivante dans AssemblyInfo.cs du projet iOS mais cela ne change rien:

[assembly: ExportRenderer(typeof(WebView), typeof(Xamarin.Forms.Platform.iOS.WkWebViewRenderer))]

J'aimerais également connaître la date limite de soumission des applications d'Apple.

Même problème ici.
Quelqu'un connaît la date limite d'Apple pour cette demande? Ou si Xamarin travaille sur cette mise à jour

UIWebView est toujours dans les bêtas iOS13, donc probablement jusqu'à iOS14.

Si vous regardez le dossier des rendus Xamarin.Forms.iOS, vous verrez qu'ils ont ajouté WKWebViewRender il y a 2 mois. Je suppose que vous pouvez créer votre propre WebView qui hérite de ce moteur de rendu (si vous n'avez pas la dernière version de XF sur votre projet, vous pouvez copier / coller le code) pour résoudre ce problème avec vos WebViews

WkWebViewRenderer.cs

Les gars, je trouve quelque chose de bizarre, j'ai changé l'identifiant du bundle d'applications et l'ai soumis à nouveau à l'App Store, et je n'ai pas reçu l'e-mail d'avertissement d'Apple.
Et ma situation: il y a trois jours, je n'ai reçu aucun e-mail d'avertissement d'Apple après avoir soumis ipa à testflight, puis je reçois l'e-mail après avoir apporté des modifications qui n'ont aucun rapport avec la vue Web, puis j'essaye de trouver pourquoi avec les moyens suivants:
1. essayez de remplacer UIWebViewRenderer par WKWebViewRenderer;
2. supprimer WebView;
3.Supprimez la bibliothèque de nuget tierce (que j'ai ajoutée récemment);
Mais ils sont inutiles sur l'avertissement (je reçois toujours l'e-mail d'avertissement).
Je ne sais pas comment l'ipa a été vérifiée par Apple, y a-t-il une possibilité qu'ils commettent des erreurs?

J'ai remarqué que cette situation apparaît récemment avec des scintillements et des réactions natives.

@ Carl-Wen, cela se produit aussi avec les applications Ionic

J'ai reçu le même message d'Apple Store Connect aujourd'hui. Ce qui est étrange, c'est que mon application ne contient aucune vue Web. J'ai également essayé de regarder les plugins Xamarin pour voir si l'un d'entre eux l'utilisait, mais il semblait qu'aucun d'entre eux n'utilise UIWebView (pas sûr à 100% car il existe également des dépendances de dépendances).
Quelqu'un sait-il comment identifier l'utilisation d'UIWebView dans l'application?

La même chose m'arrive. Première tentative de soumission d'une application

J'ai reçu le même avertissement d'iTunesConnect aujourd'hui

Je reçois également la même erreur il y a quelques jours, existe-t-il une solution de contournement?

Veuillez vérifier ma réponse ici, j'ai un projet sur Xamarin.Forms 3.6.x et il utilise des vues Web, j'ai donc créé un moteur de rendu personnalisé pour WebView uniquement pour iOS et changé l'héritage de UIWebViewRenderer à WKWebViewRenderer . Hier, j'ai téléchargé l'application dans le magasin et je n'ai reçu aucun avertissement.

le même problème

@FabriBertani Pourriez-vous partager votre code de rendu personnalisé s'il vous plaît?

J'ai le même problème, mais mon application n'utilise aucune vue Web. Je suppose qu'Apple détecte l'utilisation dans la bibliothèque Xamarin.iOS.

Avez-vous des solutions ou des contournements pour celui-ci? Il s'est également produit lorsque nous avons téléchargé notre application. Nous n'utilisons pas non plus WebViews et il semble que @dhewitson a raison de dire que c'est à cause de l'UIWebView sur la bibliothèque Xamarin.

En supposant que vous ne disposez d'aucun package utilisant UIWebView que vous ne pouvez pas contrôler, cela devrait suffire. Ensuite, utilisez simplement votre rendu personnalisé à la place de XF WebView standard

namespace YourAppNameSpace
{
    public class CustomWebView : WebView
    {
    }
}

[assembly: ExportRenderer(typeof(CustomWebView), typeof(CustomWebViewRenderer))]
namespace YourAppNameSpace.iOS
{
    public class CustomWebViewRenderer : WkWebViewRenderer
    {
    }
}

Même problème, est-ce que quelqu'un a une mise à jour à ce sujet?

Salut tout le monde! Merci pour vos rapports et vos recherches.

Nous suivons cela et un moteur de rendu pour WkWebView est déjà en place depuis un certain temps. J'ai avancé sur un PR faisant de ce moteur de rendu par défaut et dépréciant le UIWebView one. Avec cela, cette erreur devrait disparaître.

J'attends des critiques et des commentaires sur mon PR de la part du reste de l'équipe, mais j'espère que cela devrait être résolu bientôt.

Salut @jfversluis serait-il possible que le correctif puisse être appliqué à une ancienne version de XamarinForms?
J'utilise 3.4.0.1009999 et la mise à niveau vers la dernière version de Xamarin.Forms demanderait beaucoup d'efforts.

@ngoquoc, nous pourrions rétroporter ceci vers des versions antérieures, mais je suis sceptique que nous le

@jfversluis merci pour la réponse
Je suis tout à fait d'accord qu'il vaut la peine de passer à une version plus récente, mais la situation est qu'elle est vraiment proche de la date limite de sortie prévue. Et nous avons de nombreuses dépendances héritées (qui ne prennent en charge que jusqu'à XF 3.x) ainsi que des utilisations des changements de rupture de la nouvelle version.

@ngoquoc Pas de problème! Je comprends totalement! Pour votre prochaine version, je pense qu'il est sage de rechercher une mise à niveau. Il se peut que d'autres API deviendront obsolètes ou deviendront bientôt obsolètes. Si nous pouvons faire quelque chose pour améliorer votre expérience de mise à niveau, veuillez nous contacter!

J'espère que nous pourrons appliquer le correctif de ce problème sur 3.4. La mise à niveau vers 4.x est absolument dans notre plan et nous contacterons l'équipe si nous avons besoin d'aide (j'espère que non: D). J'apprécie vraiment votre soutien!

@ngoquoc Dans tous les cas, comme écrit ci-dessus, alors que vous pouvez télécharger votre ipa, et dans iOS13 cette classe est toujours là.
Donc, cela fonctionnera pendant un certain temps

@KSemenenko vouliez -vous dire que l'application "avertie" peut également être publiée sur l'Apple Store?
Si tel est le cas, très bien, nous pouvons nous calmer et reporter le passage à WKWebView pendant un certain temps: D
Ma seule préoccupation est de savoir si Apple approuve une telle application avec des avertissements.
J'ai trouvé les informations publiées sur la dépréciation ici, mais aucune date limite officielle / politique d'examen de l'Apple Store n'est spécifiée: https://developer.apple.com/documentation/uikit/uiwebview

@ngoquoc Historiquement, oui, ils approuveront toujours ces applications pour le moment. L'avertissement dit essentiellement "hé, nous approuverons votre application pour le moment, mais à l'avenir nous n'allons pas le faire, vous devriez donc changer au plus vite". Tant que vous publiez avant qu'ils ne décident de changer cela en erreur, vous êtes bon.

Merci. J'essaierai de soumettre l'application maintenant et je vous répondrai peut-être dans quelques jours après que Apple l'ait examinée :)

@ngoquoc hier, j'ai pu télécharger ipa sur l'AppStore.

Copié depuis
https://github.com/xamarin/Xamarin.Forms/pull/7367#issuecomment -527558598

Ma pensée actuelle serait de comprendre pourquoi ces moteurs de rendu ne sont pas liés (sur lesquels j'ai travaillé un peu). Si RenderWith n'entraîne pas la liaison des Renderers, je ne le pense pas et tout le truc des Forwarders sert à quelque chose (non?)

Dans ce cas, nous pourrions changer le type par défaut (comme dans ce PR) et laisser le WebViewRenderer dedans. Si les gens ont besoin de revenir à WebViewRenderer, ils peuvent ajouter l'exportation pour cela, mais si les gens ne l'utilisent pas, j'espère qu'il sera lié en dehors.

L'une des raisons pour lesquelles j'ai trouvé est que nos assemblys de plateforme ont tous deux
PreserveAttribute spécifié au niveau de l'assembly qui cherche à forcer l'assembly à conserver tous les types

J'ai testé en ajoutant une classe factice à notre projet de plate-forme et avec PreserveAttribute, la classe reste mais sans elle, PreserveAttribute disparaît.

Les moteurs de rendu restent tous :-) mais c'est un petit pas

J'ai effectué un test rapide avec la classe CheckboxRendererDesigner (car elle n'est vraiment utilisée nulle part)

Et si je supprime ces deux lignes de code
https://github.com/xamarin/Xamarin.Forms/blob/d56942c5bee0a7c56255febc8bbcc6bc33d5e1cb/Xamarin.Forms.Platform.Android/AppCompat/FormsAppCompatActivity.cs#L128

https://github.com/xamarin/Xamarin.Forms/blob/bcf1d857f70c2d521fdbf59bd73445c7e77fe1fc/Stubs/Xamarin.Forms.Platform.cs#L112

Ensuite, il est lié.

Il semble que l'objectif de RenderWith sur ces projets de transitaire
https://github.com/xamarin/Xamarin.Forms/blob/bcf1d857f70c2d521fdbf59bd73445c7e77fe1fc/Stubs/Xamarin.Forms.Platform.cs#L112

Ne fournissent pas la connexion assez faible espérée

Il semble que cela se produise parce que la case à cocher (élément de formulaires) elle-même n'est pas liée, ce qui oblige l'attribut RenderWith à conserver le rendu.

Si je change le CheckboxRendererDesigner pour attribuer une classe inexistante
`` C #
[RenderWith (typeof (CheckBoxRenderer))]
classe interne _CheckBoxRenderer {}

[RenderWith(typeof(CheckBoxDesignerRenderer))]
internal class _CheckBoxRendererIsMyNameo { }

''

Ensuite, il est lié ...

Il faut donc savoir comment lier la CheckBox

D'autres ont-ils vu l'avertissement disparaître en faisant cela?

https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -527294907

@PureWeen

Cela n'a pas fonctionné pour moi, j'ai à la fois le moteur de rendu et l'entrée dans le fichier d'assemblage et je reçois toujours l'avertissement.

Vouliez-vous dire que simplement ajouter WKWebViewRenderer n'est pas suffisant pour cet e-mail d'avertissement?

@PureWeen

Cela n'a pas fonctionné pour moi, j'ai à la fois le moteur de rendu et l'entrée dans le fichier d'assemblage et je reçois toujours l'avertissement.

Dans ce cas, vous avez peut-être un autre package qui utilise UIWebView, j'utilise simplement cette solution de contournement et je ne reçois aucun avertissement de l'App Store :)

Salut @ngoquoc, avez-vous encore de la chance avec le processus de révision?

aimerait simplement savoir si la date limite de notre application sera respectée si vous soumettez pour examen, indépendamment de l '«avertissement».

Je suppose que nous devons savoir quand Apple commencera à considérer ce motif pour rejeter un fichier IPA. J'ai peur qu'ils ne l'annoncent pas publiquement.

Aujourd'hui, j'ai reçu une lettre indiquant que mon application a passé l'examen Apple
donc pour l'instant ça marche :)

La révision des applications fonctionne comme d'habitude. Ma nouvelle application vient de publier normalement. Peut-être juste un avertissement pour une prochaine version.

Habituellement, les avertissements ne sont que des avertissements et ils vous laissent beaucoup de temps. Dans le cas de Google, ils vous donnent environ 2 ans. Je suppose ici que l'avertissement est de vous dire qu'ils vont le supprimer d'iOS 14 (je suppose) et qu'ils veulent vraiment que vous arrêtiez de l'utiliser. Bien que si vous inversiez le commutateur ou s'il était activé par défaut, vous ne l'utiliseriez pas de toute façon. Donc, à moins qu'ils ne basculent le commutateur et en font une erreur, ce que je ne pense pas qu'ils feraient, car certaines personnes doivent encore prendre en charge des appareils plus anciens.

OK, voici ce que j'ai fait pour vérifier ce qui se passe.

J'ai créé une application factice que j'ai téléchargée sur Apple avec le dernier package Xamarin.Forms stable et l'application affichant uniquement une WebView. Peu de temps après l'avoir téléchargé, j'ai reçu cet avertissement. Pour vérifier que l'avertissement s'éteint à chaque fois, et donc pour vérifier, nous pouvons supposer que lorsque l'avertissement ne vient pas, nous avons résolu le problème, j'ai créé un autre binaire sans changement en plus du numéro de version. Le message d'avertissement est revenu. Cela confirme: chaque fois que vous arrêtez de recevoir l'avertissement, le problème est apparemment résolu.

Puis je suis allé de l' avant et mettre en œuvre un moteur de rendu personnalisé avec le code exact que @FabriBertani fourni ici . Le message est toujours venu. Cela ne semble donc pas être une solution.

J'ai ensuite pris cette branche et j'ai simplement supprimé le WebRenderer et effectivement supprimé toutes les références à UIWebView. Cela a eu l'effet escompté. Apple ne m'a plus envoyé d'avertissement.

Tout cela semble indiquer que tant que nous référencerons UIWebView dans notre code (lire: tant que UIWebViewRenderer est toujours en place), Apple le détectera et arrêtera finalement d'accepter l'application. Pour obtenir une compatibilité ascendante maximale, nous devons rechercher pourquoi l'éditeur de liens ne supprime pas le WebViewRenderer lorsqu'il n'est plus utilisé. Si nous corrigeons cela , mon PR a du sens et devrait résoudre ce problème une fois pour toutes.

Comme James (et d'autres) l'ont mentionné, ce n'est qu'un avertissement pour le moment, donc même si vous recevez le message, à ce stade, il n'y a rien à craindre et cela fonctionnera. Mais bien sûr, nous devons être préparés au moment où Apple décidera d'arrêter d'autoriser l'ancienne API UIWebView.

Donc, après avoir vérifié avec l'équipe iOS, il semble que tout ce qui hérite de NSObject ne sera jamais lié, donc la promesse de RenderWith de relier les moteurs de rendu, je suis presque sûr qu'elle n'a jamais fonctionné sur iOS

Étant donné que nous allons simplement devoir supprimer complètement le moteur de rendu et casser tout le monde

Ou soyez astucieux avec une nuget séparée et un transfert de type

J'ai aussi le même problème. Une mise à jour pour ceci?

Salut @ Mikilll94 , nous y travaillons activement, mais une solution complète ne sera pas disponible de sitôt. Avec une «solution complète», je veux dire que l'avertissement cessera de venir d'Apple chaque fois que vous soumettez une application Xamarin.Forms au magasin.

Pour arrêter le message d'avertissement, nous devons supprimer complètement le WebViewRenderer actuel de la source. Étant donné que ce moteur de rendu est actuellement la valeur par défaut et qu'il est dans la source depuis toujours, il s'agit d'un changement majeur. Avec le PR associé à ce problème, nous basculons le moteur de rendu par défaut sur WKWebViewRenderer qui utilisera efficacement le nouveau WKWebView . Les utilisateurs finaux de Xamarin.Forms ne doivent rien remarquer à propos de cette modification. Avec ce commutateur, nous marquons également le WebViewRenderer comme obsolète pour donner aux utilisateurs de Xamarin.Forms la possibilité d'apporter les modifications nécessaires dans leur code. Par exemple, s'ils ont des moteurs de rendu personnalisés en place qui reposent sur le WebViewRenderer .

Cependant, comme le WebViewRenderer est toujours lié à la source, c'est toujours quelque chose qu'Apple récupère lors de l'analyse de votre application. Dans une version ultérieure de Xamarin.Forms, qui en est à sa toute première version 4.5, nous supprimerons entièrement le WebViewRenderer et avec cela les messages d'avertissement d'Apple devraient s'arrêter.

Cela dit, il y a deux choses à retenir:

1. Le message d'Apple n'est qu'un avertissement pour le moment, rien ne vous empêche de soumettre de nouvelles versions et elles devraient être acceptées dans l'App Store très bien. Cela continuera probablement jusqu'à iOS 14 qui nous donne (au moins) un an.
2. Encore une fois, supprimer le WebViewRenderer de la source est un changement majeur que nous préférerions ne pas faire, mais nous n'avons pas le choix à ce stade. Par conséquent, nous devons prendre un certain temps pour avertir les utilisateurs à ce sujet et passer progressivement à la nouvelle implémentation en premier, puis supprimer cette classe de la source. C'est un processus long mais qui devrait se produire bien avant la sortie d'iOS 14.

J'espère que cela répond à toutes vos préoccupations à ce sujet, sinon, faites-le moi savoir. Je serai ravi de répondre à toutes vos questions à ce sujet.

Merci de votre compréhension et de votre patience!

@jfversluis
Merci pour cette réponse brillante :)

@jfversluis Merci pour votre réponse
Pouvez-vous me dire comment supprimer le WebViewRenderer de la source?

@NehalOsama, la seule façon de le faire est de cloner ce référentiel XamForms, de supprimer le fichier WebViewRenderer.cs du projet Platforms.iOS, de modifier toutes les références pour qu'elles pointent vers le WKWebViewRenderer et de créer vos propres DLL et utilisez cela dans votre application.

Je déconseille vivement cela . Cela signifie que vous ne pouvez pas mettre à niveau vers les versions que nous publierons, donc vous ne recevrez jamais de corrections de bogues ou quoi que ce soit sans perdre la modification personnalisée. Ou, vous devrez répéter ce processus à chaque fois que vous souhaitez mettre à niveau.

Si cela ne vous dérange pas de me demander; pourquoi ne pas attendre? Le message d'Apple n'est qu'un avertissement et nous l'aurons bien fait avant qu'Apple ne commence réellement à rejeter les applications. Il n'y a rien à craindre à ce stade.

@jfversluis
Merci beaucoup, Indépendamment de la suppression des références et de l'avertissement, la raison est que notre client nous insiste pour intégrer une autre application utilisant le webkit
J'ai fait comme https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -527294907,
mais comment puis-je m'assurer que mon moteur de rendu personnalisé est WKWebViewRenderer et non UIWebView?!
Y a-t-il une différence évidente entre eux ou quelque chose qui peut le prouver au client?!

C'est un peu le fait que vous ne devriez voir aucune différence entre eux si nous avons bien fait notre travail 😉

Je ne sais pas de combien de preuves ils auraient besoin. Vous pouvez creuser avec des inspecteurs ou des trucs UITest pour découvrir les types réels qui sont générés. Le moyen le plus simple consiste simplement à définir un point d'arrêt dans votre moteur de rendu personnalisé que vous avez créé et à voir si cela est atteint. Si c'est le cas, le WKWebView est utilisé. De plus, vous pouvez implémenter un petit mécanisme dans votre moteur de rendu personnalisé qui charge une certaine page à partir de la plate-forme native, encore une fois, vous pouvez mettre un point d'arrêt et vérifier qu'il utilisera WKWebView au lieu de UIWebView .

Si vous voulez changer tous les contrôles normaux WebView en WKWebViewRenderer sans avoir à créer un moteur de rendu personnalisé et utiliser simplement WebView au lieu d'un héritage, vous pouvez ajouter cette ligne au AssemblyInfo.cs dans votre projet iOS:

[assembly: ExportRenderer(typeof(Xamarin.Forms.WebView), typeof(Xamarin.Forms.Platform.iOS.WKWebViewRenderer))] .

Le binaire de mon application a été rejeté aujourd'hui à cause de cela. J'utilise déjà le WkWebViewRenderer

Dear Developer,
We identified one or more issues with a recent delivery for your app, [REDACTED]. 
Your delivery was successful, but you may wish to correct the following issues in 
your next delivery:ITMS-90809: Deprecated API Usage - Apple will stop accepting 
submissions of apps that use UIWebView APIs.
See https://developer.apple.com/documentation/uikit/uiwebview for more information.

After you’ve corrected the issues, you can use Xcode or Application Loader to upload
a new binary to App Store Connect.
Best regards,
The App Store Team

Malgré ce langage passif ("cessera d'accepter"), mon binaire n'a pas été traité et mis à disposition pour la publication.

C'est maintenant critique. Je ne peux publier aucune nouvelle version de l'application de mon client.

Quelle est l'ETA pour ce correctif?

Salut @joehanna merci pour le rapport. Etes-vous absolument sûr? Le message lui-même indique que la livraison a réussi et il n'y a aucune raison de supposer que quelque chose est différent de la première ouverture de ce problème. Cela prend un certain temps avant qu'Apple ne traite l'intégralité du binaire après l'envoi d'un message comme celui-ci.

Je vois que votre commentaire date d'il y a environ une heure, il devrait apparaître sur le portail des développeurs maintenant Seriez-vous en mesure de vérifier que cela n'a vraiment pas abouti?

Également

mon binaire n'a pas été traité et mis à disposition pour la publication.

comment avez-vous vérifié cela? Si vous accédez à la définition de l'application, puis à Activité, sous Toutes les versions, vous ne la voyez pas?

Merci pour votre réponse rapide @jfversluis. Je n'ai pas reçu l'e-mail de confirmation et il n'apparaît pas dans les versions disponibles. Je suppose qu'il pourrait y avoir un arriéré de traitement? D'après mon expérience, le binaire est traité en moins de 20 minutes. Je vais le vérifier à nouveau dans un peu de temps et faire un rapport.

Ah, c'est un bon point que vous abordez là-dessus. Il peut y avoir une activité supplémentaire avec l'arrivée d'iOS 13 et les personnes soumettant de nombreuses versions pour cela. Je viens de créer une nouvelle version de l'application factice que vous pouvez voir ci-dessus et de la soumettre également, juste pour vérifier et voir ce qui se passe.

Je vous mettrai à jour dès que je verrai quelque chose.

Merci pour le rapport en tout cas!

@joehanna J'ai reçu l'avertissement en premier et en quelques minutes, j'ai eu la deuxième image. Donc, je ne sais pas ce qui se passe avec votre build, mais cela ne semble pas être lié à l'utilisation de UIWebView

Il est finalement arrivé. Désolé pour le drame. Jamais cela n'avait pris si longtemps. Merci d'avoir suivi.

SDK_Bug

Le problème est dû au fait que le compilateur ne supprime pas les fichiers de classe ou les bibliothèques indésirables.
Les équipes de développement Xamarin doivent se référer aux dernières politiques de développement Apple.

@jfversluis Nous rencontrons le même problème avec les projets Xamarin.iOS. Alors que ce thread est sous Xamarin.Forms, la cause principale est-elle la même? Le correctif va-t-il adresser à la fois Xamarin.iOS et Xamarin.Forms?

Merci!
CompaNova LLC

@dmitrymal il y a quelques causes

Xamarin.iOS résoudra leur cause, puis nous allons construire sur cela pour résoudre la nôtre

Nous travaillons sur quelques solutions et nous mettrons à jour ce problème au fur et à mesure que nous progressons

Comment se fait-il que ce fil soit toujours étiqueté s / non vérifié?

Non, ce n'est pas @taublast 🤡

Bien que j'apprécie que ce correctif est un certain temps et n'est pas actuellement urgent, quand il sera fait, sera-t-il rétroporté sur les versions précédentes de XF? Nous avons une grande suite d'applications construites en 3.4 et en raison de divers problèmes de dépendance, nous avons toujours échoué lors de la mise à niveau vers XF 4.0 ou une version ultérieure.

@ 1888games Je pense que c'est hautement improbable, également en fonction de ce que sera le correctif final éventuel.

https://github.com/xamarin/Xamarin.Forms/pull/7367 a été fusionné mais ce n'est qu'une pièce du puzzle, alors ne vous attendez pas à ce que l'avertissement disparaisse

Il faudra toujours des correctifs de l'éditeur de liens dans le SDK Xamarin.Forms et le SDK Xamarin.IOS

• https://github.com/xamarin/Xamarin.Forms/tree/ios_linker
• Et puis quelques correctifs d'éditeur de liens supplémentaires dans le SDK Xamarin.iOS lui-même

Quelle version de XamarinForms a-t-elle résolu ce problème?

@ s-bhavin-shah, nous devons passer par plusieurs étapes et étapes pour résoudre ce problème et mettre cela de côté pour de bon. Par conséquent, cela n'est pas résolu dans une certaine version de Xamarin.Forms à ce stade. Je veux simplement répéter qu'il n'y a aucune raison de s'inquiéter à ce stade. Le message d'Apple n'est qu'un avertissement pour le moment et sera un avertissement pour le bon moment à venir.

Au moment où l'avertissement devient Apple rejetant les applications pour cette raison, nous nous assurerons d'être prêts. Nous vous tiendrons au courant de ce numéro. Ce qui s'est passé maintenant, c'est que nous avons trouvé un moyen de faire en sorte que l'éditeur de liens supprime réellement les objets Xamarin (principaux) qui ne sont pas utilisés. De plus, mon PR a fusionné, ce qui fera du WKWebViewRenderer la valeur par défaut.

Une fois cela en place, la dernière étape consiste essentiellement à publier la solution de «liaison iOS». Lorsque cela se produit, WKWebViewRenderer étant la valeur par défaut et WebViewRenderer n'est plus utilisé dans votre code devrait entraîner la suppression du binaire résultant qui est envoyé à Apple. Cela étant dit; publier la solution de liaison iOS est plus facile à dire qu'à faire et prendra un peu plus de temps.

L'avantage ici est que nous n'allons probablement pas devoir opter pour la solution complète de changement de rupture, mais nous pouvons progressivement faire passer tout le monde dans cette solution.

J'espère que cela répondra à toutes vos questions pour le moment. Sinon, faites-le moi savoir!

Lors de la désapprobation de UIWebView et de son remplacement par WkWebView, vous devez tenir compte de ce problème
https://github.com/xamarin/Xamarin.Forms/issues/8028

Vous pouvez interrompre les applications des utilisateurs si vous remplacez simplement UIWebView par WkWebView

@ Mikilll94 Bien que le point soit valable, le fait est qu'Apple commencera à rejeter les binaires qui utilisent encore UIWebView. Ainsi, même si Xamarin ne faisait rien, ce serait de toute façon un changement radical car Apple ne vous laissera pas (probablement dans les 9 prochains mois) mettre à jour votre application sans effectuer ce changement de toute façon.

@ cabale95
C'est ça.

Mais je voulais montrer qu'il y a un problème avec WkWebView qui est très crucial et affectera de nombreux développeurs et pour le moment, il n'y a pas de solution de contournement.

Même problème ! Un travail parfait autour?

Hey @samirgcofficial merci d'avoir signalé vos résultats. Avez-vous vu le commentaire auquel nous faisons référence tout en haut: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -542363338?

Cela devrait expliquer à peu près l'état actuel :)

Résumé: il n'y a pas de solution de contournement ou de solution pour le moment, nous y travaillons. Mais ce message d'Apple n'est qu'un avertissement et vous devriez pouvoir soumettre vos applications sans aucun problème, juste ce message d'avertissement.

S'il y a des questions, faites-le moi savoir!

@jfversluis @samirgcofficial
D'après mon expérience, Apple n'accepte plus aucune application qui affiche UIWebView dans son binaire. Nous ne pouvons plus envoyer nos applications Xamarin à l'App Store. Ainsi, ce n'est pas seulement un message d'avertissement, c'est une question très importante.
Si d'un autre côté vous avez une solution sur la façon de publier nos applications, merci de nous le faire savoir?

@JawadJaber Oui, c'est un problème sérieux! Je ne peux pas effectuer de test externe de mon application dans l'App Store pour un vol d'essai. Mais le test interne de l'application est possible et cette WebView n'affecte jamais les tests internes.
Le scénario consistait à générer un lien externe et à partager ce qui ne peut pas être fait dans Test Flight. Toute solution ?

@JawadJaber si vous recevez un message différent d'Apple indiquant qu'ils ont rejeté votre binaire plutôt que de simplement avertir, veuillez poster une capture d'écran ou quelque chose pour donner plus de détails. Vendredi, j'ai soumis avec succès un binaire à Apple sans autre problème que l'e-mail d'avertissement.

Je viens de soumettre un binaire et je n'ai reçu qu'un e-mail d'avertissement

@JawadJaber @samirgcofficial pouvez-vous me dire pourquoi vous pensez que votre binaire est rejeté à cause de cette raison? Nous n'avons aucune raison de penser que quelque chose d'autre que cela reste un avertissement. Beaucoup de gens le confirment et le texte d'avertissement dans le message électronique n'a pas changé depuis la création de ce problème.

Nous convenons qu’il s’agit d’une question très importante, c’est pourquoi nous travaillons dur pour trouver une solution et nous sommes aussi clairs et transparents que possible à ce stade.

Plus tôt dans ce fil, une autre personne pensait que son binaire était rejeté, mais le traitement prenait juste un peu plus de temps. Se pourrait-il que ce soit également le cas pour vous?

Ok, j'avoue que cela fonctionne correctement maintenant avec Apple.
Bien que, il y a 3 semaines, cela ait été rejeté, j'ai contacté l'équipe de support de l'App Store et ils ont dit la même chose (leur politique).
Mais maintenant, cela fonctionne. Je pense qu'Apple vient de changer ses politiques dans ce cas. Merci @jfversluis , @ martijn00 @ cabal95

Ok, j'ai reçu un autre message de l'équipe de l'App Store indiquant que je limitais l'accès de tous les utilisateurs à l'application et autorisais certaines personnes de la région à vérifier OTP à l'aide de TWILO. Je devrais exclure les restrictions, c'est tout et l'application est en test bêta en ce moment :). C'est tout. Merci tout le monde.

mêmes problèmes

il est assez difficile d'expliquer aux clients que notre application est absolument correcte, c'est juste un avertissement, etc. ((

Je comprends totalement @YuliaLoyko. Malheureusement, nous avançons aussi vite que possible.

en attente de 4,4

@ prasannamca1107 juste pour être clair et ne pas donner d'espoir. Cela ne sera pas corrigé dans la version 4.4. Nous dépendons également d'une modification de Xamarin.iOS ici, cela ne peut pas être résolu uniquement par l'équipe Xamarin.Forms.

Du bon côté, j'ai vu un correctif fonctionnel, donc comme je l'ai mentionné: nous y travaillons, mais il faudra un certain temps avant que tout s'aligne et que nous puissions le remettre entre vos mains.

Jusqu'à présent, toujours pas d'inquiétude, le message d'Apple n'est encore qu'un avertissement!

Je suivais un fil dans le j'ai trouvé ce lien qui devrait fonctionner je pense.

pas le même avertissement que j'ai essayé

@softsan , merci pour le partage! Malheureusement, ce n’est pas une solution actuellement. Pour le moment, il n'y a pas de solution (facile). La seule chose que vous pouvez faire, que je déconseille vivement , est de créer vos propres packages Xamarin.Forms avec UIWebViewRenderer supprimé de la solution.

Nous travaillons toujours dur sur une solution, pas de soucis! :)

J'ai soumis une nouvelle application vendredi dernier, j'ai reçu le même avertissement, mais c'était juste ça: un avertissement.
L'application est approuvée et répertoriée dans les magasins d'applications sans aucun problème.

@jfversluis , @softsan J'ai écrit mon propre moteur de rendu pour WebView, qui renvoie un WKWebView. J'ai testé le code et l'ai publié dans le magasin et je reçois toujours l'avertissement. Mon moteur de rendu suit le modèle typique d'un moteur de rendu, mais voici un bref extrait du code correspondant:

if (Contrôle == null)
{
_contentController = nouveau WKUserContentController ();
var frame = UIApplication.SharedApplication.Delegate.GetWindow (). Bounds;
var cgRect = new CoreGraphics.CGRect (frame.X, frame.Y, frame.Width, frame.Height);
var config = new WKWebViewConfiguration {UserContentController = _contentController};
_wKWebView = nouveau WKWebView (cgRect, config)
{
NavigationDelegate = nouveau WKNavigationDelegate ()
};

                    SetNativeControl(_wKWebView);
                }

Il n'y a qu'un seul endroit dans mon code qui utilise un navigateur Web et j'ai débogué ce code, inspecté les types de données et vérifié qu'il est correct, mais j'ai reçu l'erreur d'Apple. J'ai soumis une contestation de révision à l'équipe de révision et j'attends une réponse.

@seanstilson ce ne sera d'aucune utilité. Comme indiqué précédemment dans ce problème, même si vous créez un moteur de rendu personnalisé qui utilise le WKWebView, UIWebViewRenderer sera toujours inclus dans les binaires Xamarin.Forms en raison de son fonctionnement actuel. Nous travaillons à changer cela, mais tant que nous ne le ferons pas, vous ne pourrez rien faire pour le moment.

Apple vous dira probablement simplement qu'il existe une référence à UIWebView. Pas dans votre code, mais via le code Xamarin.Forms toujours dans votre application.

Cela dit; nous nous assurerons de le résoudre d'une manière ou d'une autre avant qu'Apple arrête vraiment d'accepter les binaires à cause de cela.

Désolé, j'ai manqué le post plus tôt sur la construction de UIWebViewRenderer
dans les binaires @jfversluis , mon mauvais. Merci pour la réponse!

Le jeu.14 nov.2019 à 11:54 Gerald Versluis [email protected]
a écrit:

@seanstilson https://github.com/seanstilson cela ne sera d'aucune utilité. Comme
indiqué précédemment dans ce numéro, même si vous créez un moteur de rendu personnalisé
utilise WKWebView, l'UIWebViewRenderer sera toujours inclus dans le
Les binaires Xamarin.Forms en raison de leur fonctionnement actuel. Nous travaillons sur
changer cela, mais tant que nous ne le faisons pas, vous ne pouvez rien faire pour changer cela
en ce moment.

Apple vous dira probablement simplement qu'il existe une référence à UIWebView. ne pas
dans votre code, mais via le code Xamarin.Forms toujours à l'intérieur de votre application.

Cela dit; nous nous assurerons de le réparer d'une manière ou d'une autre avant
Apple arrête vraiment d'accepter les binaires à cause de cela.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/xamarin/Xamarin.Forms/issues/7323?email_source=notifications&email_token=AMVYZVVKIGZKMMH5XOS2QATQTWGF5A5CNFSM4ISLFU32YY3PNVWWWK3TULHS4DF ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AMVYZVUT5A73R4SXSQFRDMDQTWGF5ANCNFSM4ISLFU3Q
.

@seanstilson ne vous en faites pas. Il y a beaucoup d'action ici, je peux imaginer que vous manquez quelque chose :)

Salut les amis, nous allons verrouiller ce problème pour le moment en attendant les résultats de l'équipe Xamarin.iOS avant de pouvoir continuer. De cette façon, nous serons en mesure de suivre correctement ce problème, et les personnes rencontrées pourront trouver directement les informations les plus pertinentes au lieu de devoir passer par toute la conversation ici. Chaque fois qu'il y a quelque chose de nouveau à signaler, nous le ferons certainement.

Pour un bon résumé de ce qui se passe, veuillez lire ce commentaire ici: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -532228577

Les derniers progrès en ce moment peuvent être trouvés ici: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -542363338

L'essentiel est que nous travaillons sur le problème d'une manière qui sera rétrocompatible et nous serons prêts, d'une manière ou d'une autre, avant qu'Apple ne commence réellement à rejeter des applications à cause de cela.

Pour le moment, la seule chose à faire est que vous recevez un message d'avertissement d'Apple qui peut être ignoré en toute sécurité pour le moment.

Merci pour votre compréhension et votre patience!

Petite mise à jour à ce sujet: # 8001 a été fusionné comme première étape du correctif proposé. Cependant, cela ne signifie pas que le problème aura encore disparu dans une version à venir.

Comme nous l'avons mentionné précédemment, il y a également quelque chose qui doit être modifié dans Xamarin.iOS pour que cela fonctionne. Chaque fois qu'ils feront cela, la bonne version de Xamarin.iOS avec ce code (à partir de 4.5), cela disparaîtra finalement.

Pour être parfaitement clair: la version 4.5 de Xamarin.Forms seule ne résoudra PAS ce problème. Chaque fois que le correctif complet est à l'horizon, je ne manquerai pas de le mettre à jour à nouveau.

Merci!

Apple a publié une brève déclaration dans laquelle ils donnent plus de clarté sur leurs projets de dépréciation de UIWebView . Je pense que la pièce la plus importante est la suivante:

L'App Store n'acceptera plus les nouvelles applications utilisant UIWebView à partir d'avril 2020 et les mises à jour d'applications utilisant UIWebView à partir de décembre 2020.

Cela signifie que nous avons encore du temps pour trouver une solution, quelle qu'elle soit. Dans l'intervalle, nous avons étudié notre solution préférée. En collaboration avec l'équipe Xamarin.iOS, nous avons réussi à soumettre une application au magasin qui ne déclenche pas l'avertissement tout en restant compatible avec les versions antérieures. Cela signifie ne pas abandonner l'héritage (maintenant) WebViewRenderer . Nous décidons toujours si c'est la solution en fonction de quelques facteurs, mais nous y travaillons toujours et nous nous assurerons que nous sommes prêts. Au moins maintenant, nous savons quand être prêts 😄Merci de votre patience!

Bonne nouvelle à tous! Il existe un correctif final qui devrait être bientôt disponible.

Cela nécessite un peu de travail de votre part, je travaille actuellement sur un peu de documentation qui décrit ce que c'est. Ne vous inquiétez pas, ce n'est pas si compliqué!

Chaque fois que cela est en direct et que tous les bits sont également disponibles pour vous, je le posterai ici. Pas de promesses solides, mais cela devrait être assez tôt et bien avant la date limite d'avril.

Encore une fois, merci de rester avec nous là-dessus!

La solution est là!

Tous les bits sont en place, temps de solution! TL; DR: tout est décrit dans cette documentation ici .

Assurez-vous que vous utilisez le dernier Visual Studio (pour Mac) sur le canal stable, cela devrait vous mettre sur la bonne voie. Pour le moment, vous devrez utiliser la version préliminaire de Xamarin.Forms 4.5-pre1. Je comprends que ce n'est peut-être pas une option pour vous tous, mais soyez assurés que le paquet stable sortira bien avant la date limite. La stabilité de 4,5 est prévue de la mi à la fin février.

Enfin, placez l'indicateur --optimize=experimental-xforms-product-type dans votre paramètre d'arguments mtouch supplémentaires iOS et vous devriez vous débarrasser de l'avertissement d' UIWebView bien sûr 🙂

Je voudrais vous demander d'essayer ceci dans les meilleurs délais. Peut-être ne pas publier une nouvelle version réelle dans le magasin en fonction du package de prévisualisation Forms, mais au moins télécharger une version pour vérifier que cette solution fonctionne correctement. Chaque fois que vous le faites, vous pouvez simplement mettre à jour vers le package stable 4.5 et publier une nouvelle version en toute confiance.

Si vous rencontrez quelque chose avec cette solution, n'hésitez pas à me contacter directement (gerald.versluis [a avec une longue queue] microsoft.com) ou à ouvrir un nouveau numéro sur le référentiel. Bien sûr, les commentaires positifs sont toujours appréciés également 😉

Merci encore!