También tengo este problema, estamos usando: Xamarin.Forms 3.6.0.539721

Cada versión de Forms obtendrá esto porque WebViewRenderer en iOS implementa UIWebView, y el archivo permanece incluso si cambia el WkWebViewRenderer. No sé si hay una forma de vincular ese archivo durante la compilación.

@ swansca79 - eso es más o menos lo que temía. Espero que podamos vincularlo como usted dice.

¿Cuál es la fecha límite de Apple para este requisito? No pude encontrar ninguna ...

Supongo que esto afecta a todas las aplicaciones, independientemente de si se trata de nuevas presentaciones o actualizaciones. Si ese es el caso, ¿cuál es el punto de vincular el antiguo renderizador? Debe eliminarse del código fuente. Además, necesitamos averiguar si este es un requisito de iOS 13 o no ...

El mismo problema aqui. Estoy usando Xamarin.Forms 4.2.0.709249

Agregué la siguiente línea en AssemblyInfo.cs del proyecto iOS, pero eso no cambia nada:

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

También me gustaría saber la fecha límite de Apple para el envío de aplicaciones.

El mismo problema aqui.
¿Alguien sabe la fecha límite de Apple para este requisito? O si Xamarin está trabajando en esta actualización

UIWebView todavía está en las versiones beta de iOS13, por lo que probablemente lo haya hecho hasta iOS14.

Si observa la carpeta de representadores de Xamarin.Forms.iOS, verá que agregaron WKWebViewRender hace 2 meses. Supongo que puede crear su propio WebView que herede de ese renderizador (si no tiene la última versión de XF en su proyecto, puede copiar / pegar el código) para solucionar este problema con sus WebViews

WkWebViewRenderer.cs

Chicos, encuentro algo extraño, cambié el identificador del paquete de aplicaciones y lo envié a la tienda de aplicaciones nuevamente, y no recibí el correo electrónico de advertencia de Apple.
Y mi situación: hace tres días, no recibí ningún correo electrónico de advertencia de Apple después de enviar ipa a testflight, y luego recibí el correo electrónico después de realizar algunos cambios que no tienen relación con webview, luego trato de encontrar por qué con las siguientes formas:
1.Intente reemplazar UIWebViewRenderer con WKWebViewRenderer;
2.Eliminar WebView;
3.Elimine la biblioteca nuget de terceros (que agregué recientemente);
Pero son inútiles con la advertencia (todavía recibo el correo electrónico de advertencia).
No sé cómo Apple revisó el ipa, ¿hay alguna posibilidad de que cometan algún error?

Noté que esta situación aparece con flutter y react-native recientemente (los desarrolladores también resuelven los problemas).

@ Carl-Wen esto también sucede con las aplicaciones Ionic

Recibí el mismo mensaje de Apple Store Connect hoy. Lo extraño es que mi aplicación no tiene ninguna vista web. También intenté mirar los complementos de Xamarin para ver si alguno de ellos usa, pero parece que ninguno de ellos usa UIWebView (aunque no estoy 100% seguro porque también hay dependencias de dependencias).
¿Alguien sabe cómo identificar el uso de UIWebView en la aplicación?

A mí me pasa lo mismo. Primera vez que intento enviar una aplicación

Hoy recibí la misma advertencia de iTunesConnect

También recibí el mismo error hace unos días, ¿hay alguna solución?

Verifique mi respuesta aquí, tengo un proyecto en Xamarin.Forms 3.6.xy usa algunas vistas web, así que creé un representador personalizado para WebView solo para iOS y cambié la herencia de UIWebViewRenderer a WKWebViewRenderer . Ayer subí la aplicación a la tienda y no recibí ninguna advertencia.

el mismo problema

@FabriBertani ¿Podría compartir su código de render personalizado, por favor?

Tengo el mismo problema, pero mi aplicación NO usa ninguna vista web. Supongo que Apple está detectando el uso en la biblioteca Xamarin.iOS.

¿Tiene alguna solución o solución alternativa para este? También sucedió cuando subimos nuestra aplicación. Tampoco usamos WebViews y parece que @dhewitson tiene razón en que se debe a UIWebView en la biblioteca de Xamarin.

Suponiendo que no tiene ningún paquete que use UIWebView que no pueda controlar, esto debería ser suficiente. Luego, use su renderizador personalizado en lugar de XF WebView normal

namespace YourAppNameSpace
{
    public class CustomWebView : WebView
    {
    }
}

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

El mismo problema, ¿alguien tiene una actualización sobre esto?

¡Hola a todos! Gracias por informar y su investigación.

Estamos rastreando esto y un renderizador para WkWebView ya está en su lugar por un tiempo. He avanzado en un PR haciendo que ese renderizador sea el predeterminado y desaprovechando el UIWebView one. Con eso, este error debería desaparecer.

Espero algunas revisiones y comentarios sobre mi RP del resto del equipo, pero espero que esto se resuelva pronto.

Hola @jfversluis, ¿sería posible que la solución se pueda aplicar a una versión anterior de XamarinForms?
Estoy usando 3.4.0.1009999 y sería un gran esfuerzo actualizar a la versión más reciente de Xamarin.Forms.

@ngoquoc, podríamos

@jfversluis gracias por la respuesta ultrarrápida: D
Estoy absolutamente de acuerdo en que vale la pena actualizar a una versión más nueva, pero la situación es que está muy cerca de nuestra fecha límite de lanzamiento planificada. Y tenemos muchas dependencias heredadas (que solo admiten hasta XF 3.x), así como el uso de cambios importantes de la versión más reciente.

@ngoquoc ¡ No hay problema! ¡Lo entiendo completamente! Sin embargo, para su próxima versión, creo que es aconsejable buscar actualizaciones. Es posible que haya más API que se desaprobarán o desaprobarán pronto. Si hay algo que podamos hacer para mejorar su experiencia de actualización, comuníquese con nosotros.

Con suerte, podemos aplicar la solución de este problema en 3.4. Actualizar a 4.x está absolutamente en nuestro plan y nos comunicaremos con el equipo si necesitamos ayuda (con suerte no: D). ¡Realmente aprecio su apoyo!

@ngoquoc En cualquier caso, como se escribió anteriormente, aunque puede cargar su ipa, y en iOS13 esta clase todavía está allí.
Entonces, esto funcionará por algún tiempo

@KSemenenko ¿quiso decir que la aplicación "advertida" también se puede publicar en la tienda de Apple?
Si ese es el caso, genial, podemos calmarnos y posponer el cambio a WKWebView por un tiempo más: D
Mi única preocupación es si Apple aprueba dicha aplicación con advertencias.
Encontré la información publicada sobre la desaprobación aquí, pero no se especifica ninguna fecha límite oficial / política de revisión de la tienda de Apple: https://developer.apple.com/documentation/uikit/uiwebview

@ngoquoc Históricamente, sí, todavía aprobarán esas aplicaciones por ahora. Básicamente, la advertencia dice "oye, aprobaremos tu aplicación por ahora, pero en el futuro no lo haremos, así que debes cambiar lo antes posible". Siempre y cuando publique antes de que decidan cambiar eso a un error, está bien.

Gracias. Intentaré enviar la aplicación ahora y les responderé con el resultado tal vez unos días después de que Apple la revise :)

@ngoquoc ayer pude subir ipa a AppStore.

Copiado de
https://github.com/xamarin/Xamarin.Forms/pull/7367#issuecomment -527558598

Mi pensamiento actual sería averiguar por qué esos renderizadores no se vinculan (en lo que he estado trabajando un poco). Si RenderWith no da como resultado que los renderizadores estén vinculados, entonces no lo creo y todo el asunto de los reenviadores sirve para algún propósito (¿verdad?)

En ese caso, podríamos cambiar el tipo predeterminado (como en este PR) y luego dejar el WebViewRenderer adentro. Si las personas necesitan volver a WebViewRenderer, pueden agregar la exportación, pero si las personas no lo están usando, es de esperar que se vincule. fuera.

Una de las razones por las que he descubierto es que nuestros ensamblajes de plataforma tienen la
PreserveAttribute especificado en el nivel de ensamblaje que busca forzar al ensamblaje a retener todos los tipos

Probé agregando una clase ficticia a nuestro proyecto de plataforma y con PreserveAttribute la clase permanece pero sin ella, PreserveAttribute desaparece.

Los renderizadores todavía se quedan :-) pero es un pequeño paso

Ejecuté una prueba rápida con la clase CheckboxRendererDesigner (porque realmente no se usa en ninguna parte)

Y si elimino ambas líneas de código
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

Luego se vincula.

Parece que el propósito previsto de RenderWith en estos proyectos de reenviador
https://github.com/xamarin/Xamarin.Forms/blob/bcf1d857f70c2d521fdbf59bd73445c7e77fe1fc/Stubs/Xamarin.Forms.Platform.cs#L112

No están proporcionando la conexión lo suficientemente débil que se esperaba

Parece que esto está sucediendo porque la casilla de verificación (elemento de formularios) en sí no se está vinculando, lo que hace que el atributo RenderWith mantenga el renderizador.

Si cambio CheckboxRendererDesigner para atribuir alguna clase inexistente
`` C #
[RenderWith (typeof (CheckBoxRenderer))]
clase interna _CheckBoxRenderer {}

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

''

Luego se vincula ...

Así que necesito descubrir cómo vincular el CheckBox

¿Han visto otros desaparecer la advertencia al hacer esto?

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

@PureWeen

No funcionó para mí, tengo tanto el renderizador como la entrada en el archivo de ensamblaje y todavía recibo la advertencia.

¿Quiso decir que simplemente agregar WKWebViewRenderer no es suficiente para este correo electrónico de advertencia?

@PureWeen

No funcionó para mí, tengo tanto el renderizador como la entrada en el archivo de ensamblaje y todavía recibo la advertencia.

En ese caso, tal vez tenga algún otro paquete que use UIWebView, solo uso esa solución y no recibo ninguna advertencia de la App Store :)

Hola @ngoquoc, ¿ya tienes suerte con el proceso de revisión?

solo quisiera saber si se cumplirá el plazo de nuestra aplicación si se envía para revisión independientemente de la 'advertencia'

Supongo que necesitamos saber cuándo Apple comenzará a considerar este motivo para rechazar un archivo IPA. Me temo que no lo anunciarán públicamente.

Hoy recibí una carta de que mi aplicación pasó la revisión de Apple
así que por ahora funciona :)

La revisión de la aplicación funciona como de costumbre. Mi nueva aplicación se acaba de publicar normalmente. Quizás solo una advertencia para un lanzamiento futuro.

Por lo general, las advertencias son solo advertencias y le dan mucho tiempo. En el caso de Google te dan unos 2 años. Mi suposición aquí es que la advertencia es para decirle que lo eliminarán de iOS 14 (supongo) y que realmente quieren que deje de usarlo. Aunque si acciona el interruptor o si está activado de forma predeterminada, no lo usaría de todos modos. Entonces, a menos que activen el interruptor y lo conviertan en un error, lo que no creo que sucedan porque algunas personas aún necesitan admitir dispositivos más antiguos.

Bien, esto es lo que hice para verificar lo que está pasando.

Creé una aplicación ficticia que subí a Apple con el último paquete estable de Xamarin.Forms y la aplicación muestra solo un WebView. Poco después de que lo subí, recibí esta advertencia. Para verificar que la advertencia se apaga cada vez, y así verificar podemos asumir que cuando la advertencia no llega hemos solucionado el problema, he creado otro binario sin cambios además del número de versión. El mensaje de advertencia llegó de nuevo. Entonces eso confirma: cada vez que deja de recibir la advertencia, aparentemente el problema está solucionado.

Luego seguí adelante e implementé un renderizador personalizado con el código exacto que @FabriBertani proporcionó aquí . El mensaje aún llegó. Entonces esto no parece ser una solución.

Luego tomé esta rama y simplemente eliminé WebRenderer y eliminé efectivamente todas las referencias a UIWebView. Esto tuvo el efecto deseado. Apple ya no me envió la advertencia.

Todo esto parece apuntar al hecho de que mientras hagamos referencia a UIWebView en nuestro código (léase: mientras UIWebViewRenderer todavía esté en su lugar) Apple lo detectará y finalmente dejará de aceptar la aplicación. Para obtener la máxima compatibilidad con versiones anteriores, debemos investigar por qué el enlazador no elimina WebViewRenderer cuando ya no se usa. Si solucionamos eso , mi PR tiene sentido y debería solucionar este problema de una vez por todas.

Como James (y otros) mencionaron, es solo una advertencia por ahora, por lo que incluso si recibe el mensaje, en este punto no hay nada de qué preocuparse y funcionará. Pero, por supuesto, debemos estar preparados para cuando Apple decida dejar de permitir la antigua API UIWebView.

Entonces, después de consultar con el equipo de iOS, parece que cualquier cosa que herede de NSObject nunca se vinculará, por lo que la promesa de RenderWith de vincular renderizadores, estoy bastante seguro de que nunca funcionó en iOS.

Dado que solo tendremos que eliminar el renderizador por completo y romper todos

O sea astuto con un nuget separado y algún tipo de reenvío

También tengo el mismo problema. ¿Algún avance en esto?

Hola @ Mikilll94 , estamos trabajando activamente en esto, sin embargo, una solución completa no estará disponible pronto. Con una "solución completa" me refiero a que la advertencia dejará de venir de Apple cada vez que envíe una aplicación Xamarin.Forms a la tienda.

Para detener el mensaje de advertencia, debemos eliminar completamente el WebViewRenderer actual de la fuente. Dado que ese renderizador es el predeterminado en este momento y ha estado en la fuente desde siempre, este es un cambio importante. Con el PR asociado a este problema, estamos cambiando el renderizador predeterminado a WKWebViewRenderer que utilizará efectivamente el nuevo WKWebView . Los usuarios finales de Xamarin.Forms no deberían notar nada sobre este cambio. Con este cambio, también estamos marcando el WebViewRenderer como obsoleto para dar a los usuarios de Xamarin.Forms la posibilidad de realizar los cambios necesarios en su código. Por ejemplo, si tienen representadores personalizados que se basan en WebViewRenderer .

Sin embargo, debido a que WebViewRenderer todavía está vinculado en la fuente, esto sigue siendo algo que Apple detecta mientras escanea su aplicación. En una versión posterior de Xamarin.Forms, que es la versión 4.5 más antigua, eliminaremos el WebViewRenderer completo y con eso los mensajes de advertencia de Apple deberían detenerse.

Dicho esto, hay dos cosas para quitar:

1. El mensaje de Apple es solo una advertencia por el momento, no hay nada que le impida enviar nuevas versiones y deberían ser aceptadas en la App Store sin problemas. Esto probablemente seguirá siendo así hasta iOS 14 que nos da (al menos) un año.
2. Nuevamente, eliminar el WebViewRenderer de la fuente es un cambio importante que preferiríamos no hacer, pero no tenemos otra opción en este momento. Por lo tanto, debemos tomarnos un tiempo para advertir a los usuarios sobre esto y cambiar gradualmente a la nueva implementación primero y solo luego eliminar esa clase de la fuente. Este es un proceso largo, pero debería suceder mucho antes del lanzamiento de iOS 14.

Espero que esto resuelva todas sus inquietudes acerca de esto, si no, hágamelo saber. Me complace responder cualquier pregunta que pueda tener sobre esto.

¡Gracias por tu comprensión y tu paciencia!

@jfversluis
Gracias por esta brillante respuesta :)

@jfversluis Gracias por tu respuesta
¿Puede decirme cómo eliminar WebViewRenderer de la fuente?

@NehalOsama, la única forma de hacerlo es clonar este repositorio de XamForms, eliminar el archivo WebViewRenderer.cs del proyecto Platforms.iOS, cambiar todas las referencias para que apunten al WKWebViewRenderer y crear sus propias DLL y usa eso en tu aplicación.

Recomiendo encarecidamente no hacerlo . Hacer esto significa que no puede actualizar a las versiones que lanzaremos, por lo que nunca recibirá ninguna corrección de errores ni nada sin perder el cambio personalizado. O deberá repetir este proceso nuevamente cada vez que desee actualizar.

Si no le importa que pregunte; ¿por qué no esperar? El mensaje de Apple es solo una advertencia y lo haremos mucho antes de que Apple comience a rechazar aplicaciones. No hay nada de qué preocuparse en este momento.

@jfversluis
Muchas gracias. Independientemente de eliminar las referencias y la advertencia, la razón es que nuestro cliente insiste en que integremos con otra aplicación usando el webkit
Hice como https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -527294907,
pero ¿cómo puedo asegurarme de que mi renderizador personalizado sea WKWebViewRenderer y no UIWebView?
¿Hay alguna diferencia obvia entre ellos o algo que pueda demostrarlo al cliente?

Es una especie de punto que no debería ver ninguna diferencia entre ellos si hicimos nuestro trabajo bien 😉

No estoy seguro de cuántas pruebas necesitarían. Puede investigar con inspectores o cosas de UITest para descubrir los tipos reales que se están generando. Sin embargo, la forma más fácil es simplemente establecer un punto de interrupción en su renderizador personalizado que ha creado y ver si se alcanza. Si es así, se está utilizando WKWebView . Además, puede implementar un pequeño mecanismo en su renderizador personalizado que carga una determinada página desde la plataforma nativa, nuevamente puede poner un punto de interrupción y verificar que usará WKWebView lugar de UIWebView .

Si desea cambiar todos los controles WebView regulares a WKWebViewRenderer sin tener que crear un renderizador personalizado y simplemente usar WebView lugar de una herencia, puede agregar esta línea al AssemblyInfo.cs en su proyecto de iOS:

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

El binario de mi aplicación fue rechazado hoy debido a esto. Ya estoy usando 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

A pesar de este lenguaje pasivo ("dejará de aceptar"), mi binario no se procesó y no se puso a disposición para el lanzamiento.

Ahora esto es crítico. No puedo lanzar ninguna versión nueva de la aplicación de mi cliente.

¿Cuál es la ETA para esta solución?

Hola @joehanna, gracias por informarnos. ¿Estás absolutamente seguro? El mensaje en sí dice que la entrega se realizó correctamente y no hay razón para suponer que algo es diferente de cuando se abrió este problema por primera vez. Se necesita un tiempo antes de que Apple procese todo el binario después de enviar un mensaje como este.

Veo que su comentario es de hace aproximadamente una hora, ya debería aparecer en el portal para desarrolladores. ¿Podrías verificar que realmente no pasó?

también

mi binario no fue procesado y disponible para el lanzamiento.

¿Cómo verificaste esto? Si va a la definición de la aplicación, luego Actividad, en Todas las compilaciones, ¿no la ve?

Gracias por tu rápida respuesta @jfversluis. No he recibido el correo electrónico de confirmación ni aparece en las versiones disponibles. Supongo que podría haber una acumulación de procesamiento. En mi experiencia, el binario se procesa en menos de 20 minutos. Lo comprobaré de nuevo en un rato e informaré.

Ah, ese es un buen punto que estás tocando allí. Puede haber algo de actividad adicional con iOS 13 entrando y personas que envían muchas compilaciones para eso. Acabo de crear una nueva versión de la aplicación ficticia que puede ver arriba y la envié también, solo para verificar y ver qué sucede.

Te actualizaré tan pronto como vea algo.

¡Gracias por el informe en cualquier caso!

@joehanna Recibí la advertencia primero y en minutos obtuve la segunda imagen. Entonces, no estoy seguro de lo que está sucediendo con su compilación, pero no parece estar relacionado con el uso de UIWebView

Finalmente llegó. Perdón por el drama. Nunca había tardado tanto antes. Gracias por seguirlo.

SDK_Bug

El problema se debe a que el compilador no está eliminando bibliotecas o archivos de clases no deseados.
Los equipos de desarrollo de Xamarin deben consultar las últimas políticas de desarrollo de Apple.

@jfversluis Estamos experimentando el mismo problema con los proyectos de Xamarin.iOS. Si bien este hilo está bajo Xamarin.Forms, ¿la causa raíz es la misma? ¿La corrección va a abordar tanto Xamarin.iOS como Xamarin.Forms?

¡Gracias!
CompaNova LLC

@dmitrymal hay algunas causas

Xamarin.iOS resolverá su causa y luego vamos a construir sobre eso para resolver la nuestra

Tenemos algunas soluciones en las que estamos trabajando y actualizaremos este problema a medida que avancemos.

¿Cómo es que este hilo todavía está etiquetado como no verificado?

No, no es @taublast 🤡

Aunque me doy cuenta de que esta solución está un tiempo fuera de servicio y no es urgente, cuando esté lista, ¿se actualizará a las versiones anteriores de XF? Tenemos un gran conjunto de aplicaciones integradas en 3.4 y, debido a varios problemas de dependencia, siempre fallamos al intentar actualizar a XF 4.0 o superior.

@ 1888games Creo que es muy poco probable, también dependiendo de cuál será la solución final final.

https://github.com/xamarin/Xamarin.Forms/pull/7367 se ha fusionado, pero es solo una pieza del rompecabezas, así que no espere que la advertencia desaparezca

Todavía va a requerir correcciones del vinculador dentro de Xamarin.Forms SDK y Xamarin.IOS SDK

• https://github.com/xamarin/Xamarin.Forms/tree/ios_linker
• Y luego, algunas correcciones adicionales del enlazador dentro del propio SDK de Xamarin.iOS

Entonces, ¿qué versión de XamarinForms tiene esto arreglado?

@ s-bhavin-shah, tenemos que pasar por varias etapas y pasos para solucionar este problema y dejarlo de lado para siempre. Por lo tanto, esto no está arreglado en una determinada versión de Xamarin.Forms en este momento. Solo quiero reiterar que no hay motivo de preocupación en este momento. El mensaje de Apple es solo una advertencia por ahora y será una advertencia para un buen momento por venir.

Para cuando la advertencia se convierta en Apple rechazando aplicaciones por este motivo, nos aseguraremos de estar listos. Lo mantendremos informado sobre este tema. Lo que sucedió ahora es que encontramos una manera de hacer que el vinculador elimine los objetos de Xamarin (núcleo) que no se usan. Además, mi PR se fusionó, lo que hará que WKWebViewRenderer el predeterminado.

Con eso en su lugar, básicamente el último paso es lanzar la solución de "vinculación de iOS". Cuando eso sucede, WKWebViewRenderer es el valor predeterminado y WebViewRenderer no se usa en su código, debería resultar en ser eliminado del binario resultante que se envía a Apple. Habiendo dicho eso; lanzar la solución de enlace de iOS es más fácil de decir que de hacer y llevará más tiempo.

La ventaja aquí es que probablemente no vamos a tener que ir con la solución de cambio completo, pero podemos hacer la transición gradualmente a todos a esta solución.

Espero que esto responda a todas sus preguntas en este momento. ¡Si no es así, por favor hágamelo saber!

Al desaprobar UIWebView y reemplazarlo con WkWebView, debe considerar este problema
https://github.com/xamarin/Xamarin.Forms/issues/8028

Puede romper las aplicaciones de las personas si simplemente reemplaza UIWebView con WkWebView

@ Mikilll94 Si bien el punto es válido, el simple hecho es que Apple comenzará a rechazar los binarios que todavía usan UIWebView. Entonces, incluso si Xamarin no hiciera nada, sería un cambio importante de todos modos porque Apple (probablemente en los próximos 9 meses) no le permitirá actualizar su aplicación sin hacer ese cambio de todos modos.

@ cabal95
Así es.

Pero quería mostrar que hay un problema con WkWebView que es muy importante y afectará a muchos desarrolladores y, en este momento, no existe una solución alternativa.

¡Mismo problema! ¿Algún trabajo perfecto?

Hola @samirgcofficial, gracias por informar tus hallazgos. ¿Viste el comentario al que nos referimos en la parte superior: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -542363338?

Eso debería explicar el estado actual bastante :)

Resumen: no hay ninguna solución alternativa en este momento, estamos trabajando en ello. Pero este mensaje de Apple es solo una advertencia y debería poder enviar sus aplicaciones sin ningún problema, solo este mensaje de advertencia.

Si tiene alguna pregunta, hágamelo saber.

@jfversluis @samirgcofficial
Según mi experiencia, Apple ya no acepta ninguna aplicación que muestre UIWebView en su binario. Ya no podemos enviar nuestras aplicaciones de Xamarin a App Store. Por lo tanto, no es solo un mensaje de advertencia, es un tema muy importante.
Si, por otro lado, tiene una solución sobre cómo publicar nuestras aplicaciones, háganos saber cómo.

@JawadJaber Sí, ¡es un problema grave! No puedo realizar pruebas externas de mi aplicación en la tienda de aplicaciones para el vuelo de prueba. Pero las pruebas internas de la aplicación son posibles y este WebView nunca afecta las pruebas internas.
El escenario era generar un enlace externo y compartir, lo que no se puede hacer en el vuelo de prueba. Alguna solución ?

@JawadJaber si

Acabo de enviar un binario y solo recibí un correo electrónico de advertencia

@JawadJaber @samirgcofficial, ¿ podría decirme por qué cree que su binario es rechazado por esta razón? No tenemos ninguna razón para pensar que otra cosa que no sea esto sigue siendo una advertencia. Mucha gente está confirmando esto y el texto de advertencia en el mensaje de correo electrónico no ha cambiado desde que se creó este problema.

Estamos de acuerdo en que este es un tema muy importante, por eso estamos trabajando duro en una solución y somos lo más claros y transparentes que podríamos ser en este momento.

Anteriormente en este hilo, había otra persona que pensó que su binario había sido rechazado, pero el procesamiento tomó un poco más de tiempo. ¿Podría ser que este también sea tu caso?

Ok, admito que ahora está funcionando correctamente con Apple.
Aunque, hace 3 semanas, fue rechazado, y me comuniqué con el equipo de soporte de la App Store y dijeron lo mismo (su política).
Pero ahora está funcionando. Creo que Apple acaba de cambiar sus políticas para este caso. Gracias @jfversluis , @ martijn00 @ cabal95

Ok, recibí otro mensaje del equipo de la tienda de aplicaciones de que estaba restringiendo el acceso de todos los usuarios a la aplicación y permitiendo que ciertas personas de la región realicen la verificación de OTP usando TWILO. Debería excluir las restricciones, eso es todo y la aplicación está en prueba beta en este momento :). Eso es todo. Gracias a todos.

mismos problemas

es bastante difícil explicar a los clientes que nuestra aplicación está absolutamente bien, es solo una advertencia, etc. ((

Entiendo totalmente a @YuliaLoyko. Desafortunadamente, nos estamos moviendo tan rápido como podemos.

esperando 4.4

@ prasannamca1107 solo para ser claro y no hacerte ilusiones. Esto no se solucionará en 4.4. También dependemos de un cambio en Xamarin.iOS aquí, esto no puede ser solucionado solo por el equipo de Xamarin.Forms.

En el lado positivo, he visto una solución que funciona, así que como mencioné: estamos trabajando en eso, pero tomará un tiempo antes de que todo se alinee y podamos ponerlo en sus manos.

Hasta ahora, todavía no hay nada de qué preocuparse, ¡el mensaje de Apple sigue siendo solo una advertencia!

Estaba siguiendo un hilo en el foro de xamarin y encontré este enlace que creo que debería funcionar.

sin la misma advertencia que intenté

@softsan , ¡gracias por compartir! Desafortunadamente, esa no es una solución actualmente. En este momento, no hay una solución (fácil). Lo único que puede hacer, lo que recomiendo encarecidamente , es crear sus propios paquetes de Xamarin.Forms con UIWebViewRenderer eliminado de la solución.

Todavía estamos trabajando duro para encontrar una solución, ¡no te preocupes! :)

Envié una nueva aplicación el viernes pasado, recibí la misma advertencia, pero fue solo eso: una advertencia.
La aplicación está aprobada y listada en las tiendas de aplicaciones sin ningún problema.

@jfversluis , @softsan Escribí mi propio renderizador para WebView, que devuelve un WKWebView. Probé el código y lo publiqué en la tienda y todavía recibo la advertencia. Mi renderizador sigue el patrón típico de un renderizador, pero aquí hay un breve fragmento del código relevante:

si (Control == nulo)
{
_contentController = new 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 = nuevo WKWebView (cgRect, config)
{
NavigationDelegate = nuevo WKNavigationDelegate ()
};

                    SetNativeControl(_wKWebView);
                }

Solo hay un lugar en mi código que usa un navegador web y depuré este código, inspeccioné los tipos de datos y verifiqué que es correcto, pero recibí el error de Apple. Envié un reclamo de revisión al equipo de revisión y estoy esperando recibir una respuesta.

@seanstilson no servirá de nada. Como se indicó anteriormente en este número, incluso si crea un representador personalizado que usa WKWebView, UIWebViewRenderer seguirá estando incluido en los binarios de Xamarin.Forms debido a cómo funciona en este momento. Estamos trabajando para cambiar eso, pero hasta que lo hagamos, no hay nada que pueda hacer para cambiar esto en este momento.

Apple probablemente simplemente le dirá que hay una referencia a UIWebView. No en su código, sino a través del código de Xamarin.Forms aún dentro de su aplicación.

Habiendo dicho esto; Nos aseguraremos de solucionarlo de una forma u otra antes de que Apple realmente deje de aceptar binarios debido a esto.

Lo siento, me perdí la publicación anterior sobre la construcción de UIWebViewRenderer
en los binarios @jfversluis , mi mal. ¡Gracias por la respuesta!

El jueves 14 de noviembre de 2019 a las 11:54 a. M. Gerald Versluis [email protected]
escribió:

@seanstilson https://github.com/seanstilson no será de utilidad. Como
indicado anteriormente en este número, incluso si crea un renderizador personalizado que
utiliza el WKWebView, el UIWebViewRenderer seguirá estando incluido en el
Binarios de Xamarin.Forms debido a cómo funciona en este momento. Estamos trabajando en
cambiando eso, pero hasta que lo hagamos, no hay nada que pueda hacer para cambiar esto
en este momento.

Apple probablemente simplemente le dirá que hay una referencia a UIWebView. No
en su código, pero a través del código de Xamarin.Forms aún dentro de su aplicación.

Habiendo dicho esto; nos aseguraremos de arreglarlo de una forma u otra antes
Apple realmente deja de aceptar binarios debido a esto.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/xamarin/Xamarin .
o darse de baja
https://github.com/notifications/unsubscribe-auth/AMVYZVUT5A73R4SXSQFRDMDQTWGF5ANCNFSM4ISLFU3Q
.

@seanstilson no se preocupe por eso. Hay mucha acción aquí, me imagino que te pierdes algo :)

Hola amigos, bloquearemos este problema por ahora mientras esperamos los resultados del equipo de Xamarin.iOS antes de poder continuar. De esta manera, podremos rastrear este problema correctamente, y las personas que se encuentren con esto podrán encontrar la información más relevante directamente en lugar de tener que revisar toda la conversación aquí. Siempre que haya algo nuevo que informar, definitivamente lo haremos.

Para obtener un buen resumen de lo que está sucediendo, lea este comentario aquí: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -532228577

El último progreso en este momento se puede encontrar aquí: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -542363338

La esencia es: estamos trabajando en el problema de una manera que sea compatible con versiones anteriores y estaremos listos, de una forma u otra, antes de que Apple comience a rechazar aplicaciones debido a esto.

En este momento, lo único es que recibe un mensaje de advertencia de Apple que puede ignorarse con seguridad por ahora.

¡Gracias por su comprensión y paciencia!

Pequeña actualización sobre esto: # 8001 se ha combinado como un primer paso para la solución propuesta. Sin embargo, esto no significa que el problema desaparecerá en una próxima versión.

Como mencionamos anteriormente, también hay algo que debe cambiarse en Xamarin.iOS para que esto funcione. Siempre que hagan eso, la versión correcta de Xamarin.iOS junto con este código (a partir de la 4.5), finalmente desaparecerá.

Para ser perfectamente claro: la versión 4.5 de Xamarin.Forms por sí sola NO solucionará este problema. Siempre que la solución completa esté en el horizonte, me aseguraré de actualizar esto nuevamente.

¡Gracias!

Apple ha publicado una breve declaración en la que dan más claridad sobre sus planes para desaprobar UIWebView . Creo que la pieza más importante es esta:

La App Store ya no aceptará nuevas aplicaciones que usen UIWebView a partir de abril de 2020 y actualizaciones de aplicaciones que usen UIWebView a partir de diciembre de 2020.

Eso significa que todavía tenemos algo de tiempo para encontrar una solución, sea la que sea. Mientras tanto, hemos estado investigando nuestra solución preferida. Junto con el equipo de Xamarin.iOS, hemos logrado enviar una aplicación a la tienda que no activa la advertencia y sigue siendo compatible con versiones anteriores. Eso significa no eliminar el (ahora) legado WebViewRenderer . Todavía estamos decidiendo si esa es _la_ solución basándonos en un par de factores, pero todavía estamos trabajando en ella y nos aseguraremos de estar listos. Al menos ahora sabemos cuándo estar listos, ¡gracias por su paciencia!

¡Buenas noticias a todos! Hay una solución final que debería estar disponible para que la uses pronto.

Necesita un poco de trabajo de su lado, actualmente estoy trabajando en un poco de documentación que describe lo que es. ¡No te preocupes, no es tan complicado!

Siempre que esté en vivo y todos los bits estén disponibles para usted también, lo publicaré aquí. No hay promesas sólidas, pero debería ser bastante pronto y mucho antes de la fecha límite de abril.

Nuevamente, gracias por seguir con nosotros en esto.

¡La solución está aquí!

¡Todos los bits están en su lugar, tiempo de solución! TL; DR: todo se describe en esta pieza de documentación aquí .

Asegúrese de estar utilizando la última versión de Visual Studio (para Mac) en el canal estable, que debería ponerlo en el camino correcto. Por el momento, deberá usar la versión preliminar de Xamarin.Forms 4.5-pre1. Entiendo que esta puede no ser una opción para todos ustedes, pero tenga la seguridad de que el paquete estable saldrá mucho antes de la fecha límite. Stable 4.5 está previsto para mediados o finales de febrero.

Por último, coloque el indicador --optimize=experimental-xforms-product-type en su configuración de argumentos mtouch adicionales de iOS y debería deshacerse de la advertencia de desaprobación de Apple. Si no tiene ninguna referencia propia a UIWebView por supuesto 🙂

Me gustaría pedirle que pruebe esto lo antes posible. Tal vez no para lanzar una nueva versión real a la tienda basada en el paquete de vista previa de Forms, pero al menos cargue una compilación para verificar que esta solución funciona correctamente. Siempre que lo haga, puede actualizar al paquete estable 4.5 y lanzar una nueva versión con confianza.

Si encuentra algo con esta solución, no dude en comunicarse conmigo directamente (gerald.versluis [a with a long tail] microsoft.com) o abra un nuevo número en el repositorio. Por supuesto, los comentarios positivos siempre también se agradecen 😉

¡Gracias de nuevo!