Também estou tendo este problema, estamos usando: Xamarin.Forms 3.6.0.539721

Cada versão do Forms terá isso porque WebViewRenderer no iOS implementa UIWebView e o arquivo permanece mesmo se você alternar o WkWebViewRenderer. Não sei se existe uma maneira de vincular esse arquivo durante a compilação.

@ swansca79 - era

Qual é o prazo da Apple para este requisito? Não consegui encontrar nenhum ...

Estou supondo que isso afeta todos os aplicativos, independentemente de serem novos envios ou atualizações. Se for esse o caso, de que adianta vincular o renderizador antigo? Deve ser removido do código-fonte. Além disso, precisamos descobrir se este é um requisito do iOS 13 ou não ...

Mesmo problema aqui. Estou usando o Xamarin.Forms 4.2.0.709249

Eu adicionei a seguinte linha no AssemblyInfo.cs do projeto iOS, mas isso não muda nada:

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

Também gostaria de saber o prazo da Apple para o envio do aplicativo.

Mesmo problema aqui.
Alguém sabe o prazo da Apple para este req? Ou se Xamarin está trabalhando nesta atualização

O UIWebView ainda está na versão beta do iOS13, então provavelmente estará até o iOS14.

Se você olhar a pasta de renderizadores Xamarin.Forms.iOS, verá que eles adicionaram WKWebViewRender 2 meses atrás. Suponho que você possa criar seu próprio WebView herdado desse renderizador (se não tiver a última versão do XF em seu projeto, você pode copiar / colar o código) para corrigir esse problema com seus WebViews

WkWebViewRenderer.cs

Pessoal, achei algo estranho, mudei o identificador do pacote de aplicativos e enviei para a app store novamente, e não recebi o e-mail de aviso da apple.
E a minha situação: há três dias, não recebi nenhum e-mail de aviso da apple depois de enviar ipa para testflight, e aí recebo o e-mail depois de fazer algumas alterações que não têm relação com webview, aí tento encontrar por que das seguintes maneiras:
1. Tente substituir UIWebViewRenderer por WKWebViewRenderer;
2.Remove WebView;
3.Remova a lib nuget de terceiros (eu adicionei recentemente);
Mas eles são inúteis sobre o aviso (ainda recebo o e-mail de aviso).
Não sei como o ipa foi verificado pela apple, existe a possibilidade de eles cometerem algum erro?

Percebi que essa situação aparece com flutter e react-native recentemente. (Os desenvolvedores também encontram os problemas.)

@ Carl-Wen, isso também acontece com aplicativos Ionic

Recebi a mesma mensagem do Apple Store Connect hoje. O estranho é que meu aplicativo não tem nenhuma visualização da web. Eu também tentei olhar os plug-ins Xamarin para ver se algum deles usa, mas parecia que nenhum deles estava usando UIWebView (embora não seja 100% certo porque também existem dependências de dependências).
Alguém sabe como identificar o uso de UIWebView no aplicativo?

A mesma coisa acontece comigo. Primeira tentativa de enviar um aplicativo

Recebi o mesmo aviso do iTunesConnect hoje

Eu também recebo o mesmo erro alguns dias atrás. Existe alguma solução alternativa?

Por favor, verifique minha resposta aqui, eu tenho um projeto no Xamarin.Forms 3.6.x e ele usa alguns webviews, então eu criei um renderizador personalizado para WebView apenas para iOS e mudei a herança de UIWebViewRenderer para WKWebViewRenderer . Ontem carreguei a aplicação na loja e não recebi nenhum aviso.

o mesmo problema

@FabriBertani Você poderia compartilhar seu código de renderização personalizada, por favor?

Eu tenho o mesmo problema, mas meu aplicativo NÃO usa nenhum Web Views. Estou assumindo que a Apple está detectando o uso na biblioteca Xamarin.iOS.

Você tem alguma solução ou solução alternativa para este? Também aconteceu quando carregamos nosso aplicativo. Também não usamos WebViews e parece que @dhewitson está certo que é por causa do UIWebView na biblioteca Xamarin.

Supondo que você não tenha nenhum pacote que use UIWebView que você não pode controlar, isso deve ser o suficiente. Em seguida, basta usar o renderizador personalizado em vez do XF WebView regular

namespace YourAppNameSpace
{
    public class CustomWebView : WebView
    {
    }
}

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

Mesmo problema, alguém tem uma atualização sobre isso?

Ei pessoal! Obrigado por relatar e sua pesquisa.

Estamos rastreando isso e um renderizador para WkWebView já está no lugar por um tempo. Avancei em um PR, tornando esse renderizador o padrão e descontinuando o UIWebView one. Com isso, esse erro deve desaparecer.

Espero alguns comentários e feedback sobre meu PR do resto da equipe, mas espero que isso seja resolvido em breve.

Olá @jfversluis, seria possível que a correção pudesse ser aplicada a uma versão mais antiga do XamarinForms?
Estou usando 3.4.0.1009999 e seria muito trabalhoso atualizar para a versão mais recente do Xamarin.Forms.

@ngoquoc, podemos

@jfversluis, obrigado pela resposta
Eu concordo totalmente que vale a pena atualizar para uma versão mais recente, mas a situação é que está muito perto do nosso prazo de lançamento planejado. E temos muitas dependências legadas (que só suportam até XF 3.x), bem como usos de alterações de interrupção de versões mais recentes.

@ngoquoc Sem problemas! Eu entendo completamente! No entanto, para o seu próximo lançamento, acho sensato procurar uma atualização. Pode haver mais APIs que serão obsoletas ou obsoletas em breve. Se houver algo que possamos fazer para melhorar sua experiência de atualização, entre em contato!

Esperamos que possamos aplicar a correção desse problema no 3.4. Atualizar para 4.x está absolutamente em nosso plano e entraremos em contato com a equipe se precisarmos de ajuda (espero que não: D). Agradeço muito seu apoio!

@ngoquoc Em qualquer caso, como escrito acima, enquanto você pode fazer o upload do seu ipa, e no iOS13 esta classe ainda está lá.
Então, isso vai funcionar por algum tempo

@KSemenenko , você quis dizer que o aplicativo "avisado" também pode ser publicado na loja da Apple?
Se for esse o caso, ótimo, podemos nos acalmar e adiar a mudança para WKWebView por mais algum tempo: D
Minha única preocupação é se a Apple aprova tal aplicativo com avisos.
Encontrei as informações publicadas sobre suspensão de uso aqui, mas nenhum prazo oficial / política de análise da Apple Store foi especificada: https://developer.apple.com/documentation/uikit/uiwebview

@ngoquoc Historicamente, sim, eles ainda aprovarão esses aplicativos por enquanto. O aviso basicamente diz "ei, vamos aprovar seu aplicativo por enquanto, mas no futuro não vamos, então você deve mudar o mais rápido possível". Contanto que você publique antes que eles decidam mudar isso para um erro, você está bem.

Obrigado. Vou tentar enviar o aplicativo agora e voltar para vocês com o resultado talvez alguns dias após a Apple analisá-lo :)

@ngoquoc ontem consegui carregar o ipa na AppStore.

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

Meu pensamento atual seria descobrir por que esses renderizadores não estão sendo vinculados (no qual estou trabalhando um pouco). Se RenderWith não está resultando em Renderers sendo vinculados, então eu não acho e toda a coisa de Forwarders serve a qualquer propósito (certo?)

Nesse caso, poderíamos mudar o tipo padrão (como neste PR) e, em seguida, deixar o WebViewRenderer ativado. Se as pessoas precisarem reverter para o WebViewRenderer, elas podem adicionar o Export para ele, mas se as pessoas não estiverem usando, esperançosamente ele será vinculado Fora.

Um motivo que descobri é que nossos conjuntos de plataforma têm o
PreserveAttribute especificado no nível da montagem, que procura forçar a montagem a reter todos os tipos

Eu testei adicionando uma classe fictícia ao nosso projeto de plataforma e com o PreserveAttribute a classe permanece, mas sem ela o PreserveAttribute vai embora.

Os renderizadores ainda estão por aí :-) mas é um passo de bebê

Eu fiz um teste rápido com a classe CheckboxRendererDesigner (porque ela não é usada em lugar nenhum)

E se eu remover essas duas linhas 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

Em seguida, ele é conectado.

Parece que a finalidade pretendida de RenderWith nesses projetos de encaminhamento
https://github.com/xamarin/Xamarin.Forms/blob/bcf1d857f70c2d521fdbf59bd73445c7e77fe1fc/Stubs/Xamarin.Forms.Platform.cs#L112

Não estão fornecendo a conexão fraca o suficiente que se esperava

Parece que isso está acontecendo porque o próprio Checkbox (elemento de formulários) não está sendo vinculado, o que faz com que o atributo RenderWith mantenha o Renderer por perto.

Se eu mudar o CheckboxRendererDesigner para atribuir alguma classe não existente
`` `C #
[RenderWith (typeof (CheckBoxRenderer))]
classe interna _CheckBoxRenderer {}

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

`` `

Então ele é conectado ...

Então, preciso descobrir como vincular o CheckBox

Outras pessoas viram o aviso desaparecer ao fazer isso?

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

@PureWeen

Não funcionou para mim, eu tenho o renderizador e a entrada no arquivo de montagem e ainda recebo o aviso.

Você quis dizer que apenas adicionar WKWebViewRenderer não é suficiente para este e-mail de aviso?

@PureWeen

Não funcionou para mim, eu tenho o renderizador e a entrada no arquivo de montagem e ainda recebo o aviso.

Nesse caso, talvez você tenha qualquer outro pacote que usa UIWebView, eu apenas uso essa solução alternativa e não recebo nenhum aviso da App Store :)

Olá, @ngoquoc, você já teve sorte com o processo de revisão?

gostaria apenas de saber se o prazo do nosso aplicativo será cumprido se o enviar para revisão independentemente do 'aviso'

Acho que precisamos saber quando a Apple começará a considerar esse motivo para rejeitar um arquivo IPA. Temo que eles não anunciem isso publicamente.

Hoje recebi uma carta informando que meu aplicativo foi aprovado na revisão da apple
então, por enquanto, funciona :)

A revisão do aplicativo funciona normalmente. Meu novo aplicativo acabou de ser publicado normalmente. Talvez apenas um aviso para lançamento futuro.

Normalmente, os avisos são apenas avisos e dão-lhe muito tempo. No caso do Google, eles dão cerca de 2 anos. Minha suposição aqui é que o aviso é para dizer a você que eles irão removê-lo do iOS 14 (meu palpite) e que eles realmente querem que você pare de usá-lo. Embora se você ligasse o botão ou se ele estivesse ativado por padrão, você não o usaria de qualquer maneira. Portanto, a menos que eles liguem o interruptor e cometam um erro, o que eu não acho que fariam porque algumas pessoas ainda precisam oferecer suporte a dispositivos mais antigos.

OK, aqui está o que fiz para verificar o que está acontecendo.

Criei um aplicativo fictício que enviei para a Apple com o pacote Xamarin.Forms estável mais recente e o aplicativo mostrando apenas um WebView. Logo depois de fazer o upload, recebi este aviso. Para verificar se o aviso apaga todas as vezes e, assim, para verificar, podemos assumir que, quando o aviso não vem, corrigimos o problema, criei outro binário sem alterações além do número da versão. A mensagem de aviso veio novamente. Isso confirma: sempre que você para de receber o aviso, aparentemente o problema está corrigido.

Então, fui em frente e implementei um renderizador personalizado com o código exato que @FabriBertani forneceu aqui . A mensagem ainda veio. Portanto, isso não parece ser uma solução.

Em seguida, peguei este branch e apenas excluí o WebRenderer e removi efetivamente todas as referências ao UIWebView. Isso teve o efeito desejado. A Apple agora não me envia mais o aviso.

Tudo isso parece apontar para o fato de que, enquanto fizermos referência a UIWebView em nosso código (leia-se: enquanto o UIWebViewRenderer ainda estiver instalado), a Apple o detectará e, por fim, parará de aceitar o aplicativo. Para obter o máximo de compatibilidade com versões anteriores, precisamos investigar por que o vinculador não remove o WebViewRenderer quando ele não está mais sendo usado. Se consertarmos isso , meu PR faz sentido e deve resolver o problema de uma vez por todas.

Como James (e outros) mencionaram, é apenas um aviso por enquanto, então, mesmo que você receba a mensagem, neste ponto não há nada com que se preocupar e funcionará. Mas é claro que precisamos estar preparados para quando a Apple decidir parar de permitir a antiga API UIWebView.

Então, depois de verificar com a equipe do iOS, parece que qualquer coisa que herde de NSObject nunca será vinculada, então a promessa de RenderWith de vincular renderizadores, tenho certeza de que nunca funcionou no iOS

Considerando que vamos ter que excluir o renderizador completamente e quebrar todos

Ou seja astuto com um nuget separado e algum tipo de encaminhamento

Eu também tenho o mesmo problema. alguma atualização disso?

Olá @ Mikilll94 , estamos trabalhando ativamente nisso, mas uma solução completa não estará disponível tão cedo. Com uma "solução completa", quero dizer que o aviso deixará de vir da Apple sempre que você enviar um aplicativo Xamarin.Forms para a loja.

Para interromper a mensagem de aviso, precisamos remover o WebViewRenderer atual da fonte completamente. Como esse renderizador é o padrão agora e está na origem desde sempre, essa é uma alteração importante. Com o PR associado a este problema, estamos mudando o renderizador padrão para WKWebViewRenderer que usará efetivamente o novo WKWebView . Os usuários finais do Xamarin.Forms não devem notar nada sobre esta mudança. Com essa mudança, também estamos marcando o WebViewRenderer como obsoleto para dar aos usuários do Xamarin.Forms a possibilidade de fazer as alterações necessárias em seu código. Por exemplo, se eles têm renderizadores personalizados que dependem de WebViewRenderer .

No entanto, como WebViewRenderer ainda está vinculado à fonte, isso ainda é algo que a Apple pega enquanto verifica seu aplicativo. Em uma versão posterior do Xamarin.Forms, que é a versão 4.5 mais antiga, vamos descartar WebViewRenderer inteiramente e com isso as mensagens de aviso da Apple devem parar.

Dito isso, há duas coisas a tirar:

1. A mensagem da Apple é apenas um aviso por enquanto, não há nada que impeça você de enviar novas versões e elas devem ser aceitas na App Store muito bem. Isso provavelmente continuará a ser assim até o iOS 14, o que nos dá (pelo menos) um ano.
2. Novamente, descartar WebViewRenderer da fonte é uma alteração importante que preferiríamos não fazer, mas não temos escolha neste momento. Portanto, precisamos levar algum tempo para avisar os usuários sobre isso e gradualmente mudar para a nova implementação primeiro e só então remover essa classe do código-fonte. Este é um processo demorado, mas deve acontecer bem antes do lançamento do iOS 14.

Espero que isso aborde todas as suas preocupações sobre isso, se não, por favor me avise. Terei prazer em responder a quaisquer perguntas que você possa ter sobre isso.

Obrigado pela compreensão e pela sua paciência!

@jfversluis
Obrigado por esta resposta brilhante :)

@jfversluis Obrigado pela sua resposta
Por favor, você pode me dizer como retirar o WebViewRenderer da fonte?

@NehalOsama a única maneira de fazer isso é clonar este repositório XamForms, deletar o arquivo WebViewRenderer.cs do projeto Platforms.iOS, mudar todas as referências para apontar para WKWebViewRenderer e construir suas próprias DLLs e use isso em seu aplicativo.

Eu recomendo fortemente contra isso . Isso significa que você não pode atualizar para as versões que lançaremos, então você nunca receberá nenhuma correção de bugs ou qualquer coisa sem perder a alteração personalizada. Ou, você precisaria repetir esse processo novamente para cada vez que deseja atualizar.

Se você não se importa que eu pergunte; porque não esperar? A mensagem da Apple é apenas um aviso e faremos isso bem antes que a Apple comece a rejeitar aplicativos. Não há nada com que se preocupar neste momento.

@jfversluis
Muito obrigado, Apesar de remover as referências e o aviso, o motivo é que nosso cliente insiste em nos integrar com outro aplicativo usando o webkit
Fiz como https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -527294907,
mas como posso ter certeza de que meu renderizador personalizado é WKWebViewRenderer e não UIWebView?!
Existe alguma diferença óbvia entre eles ou algo que possa provar isso para o cliente?

É meio que o ponto que você não deveria ver nenhuma diferença entre eles se fizéssemos nosso trabalho direito 😉

Não tenho certeza de quanta prova eles precisariam. Você pode entrar em contato com inspetores ou coisas do UITest para descobrir os tipos reais que estão sendo gerados. A maneira mais fácil, porém, é simplesmente definir um ponto de interrupção em seu renderizador personalizado que você criou e ver se ele é atingido. Em caso afirmativo, WKWebView está sendo usado. Além disso, você pode implementar um pequeno mecanismo em seu renderizador personalizado que carregue uma determinada página da plataforma nativa, novamente, você pode colocar um ponto de interrupção e verificar se ele usará WKWebView vez de UIWebView .

Se você quiser mudar todos os controles WebView regulares para WKWebViewRenderer sem ter que criar um renderizador personalizado e apenas usar WebView vez de uma herança, você pode adicionar esta linha ao AssemblyInfo.cs em seu projeto iOS:

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

O binário do meu aplicativo foi rejeitado hoje por causa disso. Já estou 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

Apesar dessa linguagem passiva ("vai parar de aceitar"), meu binário não foi processado e disponibilizado para o lançamento.

Isso agora é crítico. Não consigo lançar nenhuma nova versão do aplicativo do meu cliente.

Qual é o ETA para essa correção?

Olá @joehanna, obrigado por reportar. Você tem certeza absoluta? A própria mensagem diz que a entrega foi bem-sucedida e não há razão para supor que haja algo diferente de quando esse problema foi aberto pela primeira vez. Leva algum tempo até que a Apple processe todo o binário depois de enviar uma mensagem como esta.

Vejo que seu comentário é de cerca de uma hora atrás, ele deve aparecer no portal do desenvolvedor agora. Você poderia verificar se realmente não foi processado?

Além disso

meu binário não foi processado e disponibilizado para o lançamento.

como você verificou isso? Se você for para a definição do aplicativo, então Activity, em All Builds, você não o vê?

Obrigado pela sua resposta rápida @jfversluis. Não recebi o email de confirmação nem aparece nas compilações disponíveis. Eu acho que pode haver um backlog de processamento? Na minha experiência, o binário é processado em menos de 20 minutos. Vou verificar novamente daqui a pouco e relatar de volta.

Ah, é um bom ponto que você está tocando aí. Pode haver alguma atividade extra com o iOS 13 chegando e pessoas enviando um monte de compilações para isso. Acabei de criar uma nova versão do aplicativo fictício que você pode ver acima e a enviei também, apenas para verificar e ver o que acontece.

Vou atualizá-lo assim que eu ver algo.

Obrigado pelo relatório em qualquer caso!

@joehanna Recebi o aviso primeiro e em poucos minutos obtive a segunda imagem. Portanto, não tenho certeza do que está acontecendo com sua construção, mas não parece estar relacionado com o uso de UIWebView

Finalmente veio. Desculpe pelo drama. Nunca demorou tanto antes. Obrigado por acompanhar.

SDK_Bug

O problema é porque o compilador não está removendo arquivos de classe ou bibliotecas indesejados.
As equipes de desenvolvimento da Xamarin precisam consultar as políticas de desenvolvimento da apple mais recentes.

@jfversluis Estamos enfrentando o mesmo problema com projetos Xamarin.iOS. Embora este tópico esteja sob o Xamarin.Forms, a causa raiz é a mesma? A correção irá abordar o Xamarin.iOS e o Xamarin.Forms?

Obrigado!
CompaNova LLC

@dmitrymal existem algumas causas

O Xamarin.iOS resolverá sua causa e, em seguida, vamos construir em cima disso para resolver a nossa

Temos algumas soluções sendo trabalhadas e atualizaremos esse problema à medida que progredirmos

Por que este tópico ainda está marcado como não verificado?

Não, não é @taublast 🤡

Embora eu ache que essa correção ainda está um pouco fora do lugar e não é urgente no momento, quando for concluída, ela será portada para as versões anteriores do XF? Temos um grande pacote de aplicativos integrado ao 3.4 e, devido a vários problemas de dependência, sempre falhamos ao tentar atualizar para o XF 4.0 ou superior.

@ 1888games Acho que é altamente improvável, também dependendo de qual será a solução final.

https://github.com/xamarin/Xamarin.Forms/pull/7367 foi mesclado, mas é apenas uma peça do quebra-cabeça, então não espere que o aviso desapareça

Ele ainda vai exigir correções de linker dentro do Xamarin.Forms SDK e Xamarin.IOS SDK

• https://github.com/xamarin/Xamarin.Forms/tree/ios_linker
• E então algumas correções de linker adicionais dentro do próprio SDK Xamarin.iOS

Então, qual versão do XamarinForms isso corrigiu?

@ s-bhavin-shah, precisamos passar por vários estágios e etapas para consertar isso e deixar isso de lado para sempre. Portanto, isso não foi corrigido em uma determinada versão do Xamarin.Forms neste momento. Só quero reiterar que não há motivo para preocupação neste momento. A mensagem da Apple é apenas um aviso por enquanto e será um aviso para um bom momento que virá.

No momento em que o aviso se tornar a Apple rejeitando aplicativos por esse motivo, teremos certeza de estar pronto. Vamos mantê-lo atualizado sobre este assunto. O que aconteceu agora é que encontramos uma maneira de fazer o vinculador realmente remover os objetos Xamarin (do núcleo) que não são usados. Além disso, meu PR foi mesclado, o que tornará WKWebViewRenderer o padrão.

Com isso implementado, basicamente a última etapa é lançar a solução de "vinculação do iOS". Quando isso acontece, WKWebViewRenderer sendo o padrão e WebViewRenderer não sendo mais usado em seu código deve resultar na exclusão do binário resultante que é enviado para a Apple. Dito isto; lançar a solução de vinculação do iOS é mais fácil de falar do que fazer e levará mais algum tempo.

A vantagem aqui é que provavelmente não teremos que ir com a solução de mudança significativa, mas podemos fazer a transição gradual de todos para essa solução.

Espero que isso responda a todas as suas perguntas neste momento. Se não, por favor me avise!

Ao descontinuar o UIWebView e substituí-lo por WkWebView, você deve considerar este problema
https://github.com/xamarin/Xamarin.Forms/issues/8028

Você pode quebrar os aplicativos das pessoas se apenas substituir UIWebView por WkWebView

@ Mikilll94 Embora o ponto seja válido, o simples fato é que a Apple começará a rejeitar binários que ainda usam UIWebView. Portanto, mesmo que o Xamarin não fizesse nada, seria uma alteração significativa de qualquer maneira, porque a Apple (provavelmente nos próximos 9 meses) não permitirá que você atualize seu aplicativo sem fazer essa alteração de qualquer maneira.

@ cabal95
Está certo.

Mas eu queria mostrar que há um problema com o WkWebView que é crucial e afetará muitos desenvolvedores e, no momento, não há solução para ele.

O mesmo problema ! Qualquer trabalho perfeito?

Olá @samirgcofficial, obrigado por relatar suas descobertas. Você viu o comentário a que nos referimos na parte superior: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -542363338?

Isso deve explicar muito bem o status atual :)

Resumo: não há solução alternativa ou alternativa no momento, estamos trabalhando nisso. Mas esta mensagem da Apple é apenas um aviso e você deve poder enviar seus aplicativos sem problemas, apenas esta mensagem de aviso.

Se houver alguma dúvida, por favor me avise!

@jfversluis @samirgcofficial
De acordo com minha experiência, a Apple não aceita mais nenhum aplicativo que mostre UIWebView em seu binário. Não podemos mais enviar nossos aplicativos Xamarin para a App Store. Portanto, não é apenas uma mensagem de advertência, é uma questão muito importante.
Se por outro lado você tem uma solução sobre como publicar nossos aplicativos, por favor, diga-nos como?

@JawadJaber Sim, é um problema sério! Não consigo fazer testes externos do meu aplicativo na app store para teste de voo. Mas o teste interno do aplicativo é possível e este WebView nunca afeta o dos testes internos.
O cenário era gerar link externo e compartilhar, o que não pode ser feito no voo de teste. Qualquer solução ?

@JawadJaber se você está recebendo uma mensagem diferente da Apple dizendo que eles rejeitaram seu binário em vez de apenas avisar, poste uma captura de tela ou algo assim para fornecer mais detalhes. Enviei com sucesso um binário para a Apple na sexta-feira, sem nenhum problema além do e-mail de aviso.

Acabei de enviar um binário e recebo apenas um e-mail de aviso

@JawadJaber @samirgcofficial, poderia me dizer por que acha que seu binário foi rejeitado por esse motivo? Não temos nenhuma razão para pensar que outra coisa senão isso ainda é um aviso. Muitas pessoas estão confirmando isso e o texto de aviso na mensagem de e-mail não mudou desde que esse problema foi criado.

Concordamos que esta é uma questão muito importante, por isso estamos trabalhando arduamente em uma solução e somos tão claros e transparentes quanto poderíamos ser neste momento.

Anteriormente neste tópico, houve outra pessoa que pensou que seu binário foi rejeitado, mas o processamento demorou um pouco mais. Será que este também é o seu caso?

Ok, admito que agora está funcionando bem com a Apple.
Embora, três semanas atrás, ele foi rejeitado, e eu entrei em contato com a equipe de suporte da App Store e eles disseram o mesmo (sua política).
Mas agora está funcionando. Acho que a Apple acabou de mudar suas políticas para este caso. Obrigado @jfversluis , @ martijn00 @ cabal95

Ok, recebi outra mensagem da equipe da app store informando que estava restringindo o acesso de todos os usuários ao aplicativo e permitindo que certas pessoas da região verificassem OTP usando o TWILO. Devo excluir as restrições, isso é tudo, e o aplicativo está em teste beta agora :). Isso é tudo. Obrigado a todos.

mesmos problemas

é muito difícil explicar aos clientes que nosso aplicativo está absolutamente ok, é apenas um aviso, etc ((

Eu entendo perfeitamente @YuliaLoyko. Infelizmente, estamos nos movendo o mais rápido que podemos.

esperando por 4,4

@ prasannamca1107 apenas para deixar claro e não ter muitas esperanças. Isso não será corrigido no 4.4. Também dependemos de uma alteração no Xamarin.iOS aqui, isso não pode ser corrigido apenas pela equipe do Xamarin.Forms.

Pelo lado bom, eu vi uma correção funcionando, como mencionei: estamos trabalhando nisso, mas vai demorar um pouco antes que tudo se alinhe e possamos colocá-lo em suas mãos.

Até agora, nada com o que se preocupar, a mensagem da Apple continua sendo apenas um aviso!

Eu estava seguindo um tópico no fórum xamarin e encontrei este link que deve funcionar, eu acho.

nenhum mesmo aviso que eu tentei

@softsan , obrigado por compartilhar! Infelizmente, essa não é uma solução atualmente. No momento, não há solução (fácil). A única coisa que você poderia fazer, o que eu recomendo fortemente , é construir seus próprios pacotes Xamarin.Forms com o UIWebViewRenderer excluído da solução.

Ainda estamos trabalhando muito em uma solução, não se preocupe! :)

Eu enviei um novo aplicativo na sexta-feira passada, recebi o mesmo aviso, mas era apenas isso: Um aviso.
O aplicativo é aprovado e listado nas lojas de aplicativos sem nenhum problema.

@jfversluis , @softsan eu escrevi meu próprio renderizador para o WebView, que retorna um WKWebView. Testei o código e publiquei na loja e ainda recebo o aviso. Meu renderizador segue o padrão típico de um renderizador, mas aqui está um breve trecho do código relevante:

if (Control == null)
{
_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 = novo WKWebView (cgRect, config)
{
NavigationDelegate = new WKNavigationDelegate ()
};

                    SetNativeControl(_wKWebView);
                }

Existe apenas um lugar no meu código que usa um navegador da web e eu depurei esse código e inspecionei os tipos de dados e verifiquei que estão corretos, mas recebi o erro da Apple. Enviei uma contenção de revisão para a equipe de revisão e estou aguardando uma resposta.

@seanstilson , será inútil. Conforme indicado anteriormente neste problema, mesmo se você criar um renderizador customizado que usa o WKWebView, o UIWebViewRenderer ainda será incluído nos binários do Xamarin.Forms por causa de como ele funciona agora. Estamos trabalhando para mudar isso, mas até que o façamos, não há nada que você possa fazer para mudar isso neste momento.

A Apple provavelmente irá simplesmente dizer que há uma referência a UIWebView. Não em seu código, mas por meio do código Xamarin.Forms ainda dentro de seu aplicativo.

Tendo isso dito; vamos nos certificar de consertá-lo de uma forma ou de outra antes que a Apple realmente pare de aceitar binários por causa disso.

Desculpe, eu perdi a postagem anterior sobre o UIWebViewRenderer sendo construído
nos binários @jfversluis , mal. Obrigado pela resposta!

Em quinta-feira, 14 de novembro de 2019 às 11h54 Gerald Versluis [email protected]
escrevi:

@seanstilson https://github.com/seanstilson não terá utilidade. Como
indicado anteriormente neste problema, mesmo se você criar um renderizador personalizado que
usa o WKWebView, o UIWebViewRenderer ainda será incluído no
Binários do Xamarin.Forms por causa de como ele funciona agora. Estamos trabalhando em
mudando isso, mas até que o façamos, não há nada que você possa fazer para mudar isso
Neste momento.

A Apple provavelmente irá simplesmente dizer que há uma referência a UIWebView. Não
em seu código, mas por meio do código Xamarin.Forms ainda dentro de seu aplicativo.

Tendo isso dito; vamos nos certificar de consertá-lo de uma forma ou de outra antes
A Apple realmente para de aceitar binários por causa disso.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/xamarin/Xamarin.Forms/issues/7323?email_source=notifications&email_token=AMVYZVVKIGZKMMH5XOS2QATQTWGF5A5CNFSM4ISLFU32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEECWXMI#issuecomment-554003377 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AMVYZVUT5A73R4SXSQFRDMDQTWGF5ANCNFSM4ISLFU3Q
.

@seanstilson não se preocupe com isso. Há muita ação aqui, posso imaginar que você sente falta de alguma coisa :)

Olá amigos, vamos bloquear esse problema por enquanto enquanto aguardamos os resultados da equipe do Xamarin.iOS antes de prosseguirmos. Dessa forma, poderemos rastrear esse problema adequadamente e as pessoas que encontrarem isso poderão encontrar as informações mais relevantes diretamente, em vez de ter que passar por toda a conversa aqui. Sempre que houver algo novo para relatar, com certeza o faremos.

Para um bom resumo do que está acontecendo, leia este comentário aqui: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -532228577

O progresso mais recente neste momento pode ser encontrado aqui: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -542363338

O ponto principal é: estamos trabalhando no problema de uma forma que seja compatível com as versões anteriores e estaremos prontos, de uma forma ou de outra, antes que a Apple realmente comece a rejeitar aplicativos por causa disso.

No momento, a única coisa que você recebe é uma mensagem de aviso da Apple que pode ser ignorada com segurança por enquanto.

Obrigado por sua compreensão e paciência!

Pequena atualização sobre isso: # 8001 foi mesclado como uma primeira etapa para a correção proposta. No entanto, isso não significa que o problema será resolvido na próxima versão ainda.

Como mencionamos antes, também há algo que precisa ser alterado no Xamarin.iOS para que isso funcione. Sempre que eles fizerem isso, a versão certa do Xamarin.iOS junto com este código (a partir de 4.5), isso finalmente irá embora.

Para ser perfeitamente claro: a versão 4.5 do Xamarin.Forms por si só NÃO vai resolver esse problema. Sempre que a correção completa estiver no horizonte, com certeza atualizarei novamente.

Obrigado!

A Apple divulgou um breve comunicado onde dá mais clareza sobre seus planos para descontinuar UIWebView . Acho que a peça mais importante é esta:

A App Store não aceitará mais novos aplicativos usando UIWebView a partir de abril de 2020 e atualizações de aplicativos usando UIWebView a partir de dezembro de 2020.

Isso significa que ainda temos algum tempo para encontrar uma solução, seja ela qual for. Nesse ínterim, procuramos nossa solução preferida. Juntamente com a equipe Xamarin.iOS, conseguimos enviar um aplicativo para a loja que não aciona o aviso, mas permanece compatível com as versões anteriores. Isso significa não descartar o (agora) legado WebViewRenderer . Ainda estamos decidindo se essa é _a_ solução com base em alguns fatores, mas ainda estamos trabalhando nisso e teremos certeza de que estamos prontos. Pelo menos agora sabemos quando estar prontos 😄obrigado pela paciência!

Boas notícias a todos! Há uma solução final que deve estar disponível para você usar em breve.

É necessário um pouco de trabalho da sua parte. Atualmente, estou trabalhando em uma pequena documentação que descreve o que é. Não se preocupe, não é tão complicado!

Sempre que for ao vivo e todos os bits estiverem disponíveis para você também, irei postar aqui. Nenhuma promessa sólida, mas deve ser muito em breve e bem antes do prazo de abril.

Mais uma vez, obrigado por permanecer conosco nisso!

A solução está aqui!

Todos os bits estão no lugar, hora da solução! TL; DR: tudo é descrito nesta peça de documentação aqui .

Certifique-se de estar usando o Visual Studio mais recente (para Mac) no canal estável, que deve colocá-lo no caminho certo. No momento, você precisará usar a versão de visualização do Xamarin.Forms 4.5-pre1. Eu entendo que isso pode não ser uma opção para todos vocês, mas fiquem tranquilos, o pacote estável será lançado bem antes do prazo. O Stable 4.5 está planejado para meados de fevereiro.

Por último, coloque o sinalizador --optimize=experimental-xforms-product-type em sua configuração de argumentos mtouch adicionais do iOS e você deve se livrar do aviso de depreciação da Apple. Se você não tiver nenhuma referência própria a UIWebView claro 🙂

Eu gostaria de pedir que você experimente isso o mais rápido possível. Talvez não para lançar uma nova versão real para a loja com base no pacote de visualização do Forms, mas pelo menos fazer upload de um build para verificar se essa solução funciona corretamente. Sempre que você fizer isso, basta atualizar para o pacote estável 4.5 e lançar uma nova versão com confiança.

Se você se deparar com alguma coisa com esta solução, sinta-se à vontade para entrar em contato comigo diretamente (gerald.versluis [a with a long tail] microsoft.com) ou abra um novo problema no repositório. É claro que feedback positivo também é sempre apreciado 😉

Obrigado de novo!