У меня тоже возникает эта проблема, мы используем: Xamarin.Forms 3.6.0.539721

Каждая версия Forms получит это, потому что WebViewRenderer в iOS реализует UIWebView, и файл останется, даже если вы переключите WkWebViewRenderer. Я не знаю, есть ли способ связать этот файл во время сборки.

@ swansca79 - вот чего я и боялся. Я надеюсь, что мы сможем связать это, как вы говорите.

Каков крайний срок Apple по этому требованию? Я не мог найти ...

Я предполагаю, что это влияет на все приложения, независимо от того, являются ли они новыми материалами или обновлениями. Если это так, то какой смысл связывать старый рендерер? Его следует удалить из исходного кода. Также нам нужно выяснить, является ли это требованием iOS 13 или нет ...

Здесь та же проблема. Я использую Xamarin.Forms 4.2.0.709249

Я добавил следующую строку в AssemblyInfo.cs проекта iOS, но это ничего не меняет:

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

Я также хотел бы знать крайний срок Apple для отправки приложений.

Здесь та же проблема.
Кто-нибудь знает крайний срок Apple для этого запроса? Или если Xamarin работает над этим обновлением

UIWebView все еще находится в бета-версии iOS13, поэтому, вероятно, будет до iOS14.

Если вы посмотрите на папку рендереров Xamarin.Forms.iOS, вы увидите, что они добавили WKWebViewRender 2 месяца назад. Я предполагаю, что вы можете создать свой собственный WebView, который наследуется от этого средства визуализации (если у вас нет последней версии XF в вашем проекте, вы можете скопировать / вставить код), чтобы исправить эту проблему с помощью ваших WebView.

WkWebViewRenderer.cs

Ребята, я обнаружил что-то странное, я изменил идентификатор пакета приложений и снова отправил его в магазин приложений, и я не получил электронное письмо с предупреждением от Apple.
И моя ситуация: три дня назад я не получил никаких предупреждений по электронной почте от Apple после отправки ipa в testflight, а затем я получаю электронное письмо после внесения некоторых изменений, которые не связаны с веб-просмотром, затем я пытаюсь найти почему следующими способами:
1. Попытайтесь заменить UIWebViewRenderer на WKWebViewRenderer;
2. удалить WebView;
3. Удалите стороннюю библиотеку nuget lib (я недавно добавил);
Но они бесполезны в отношении предупреждения (я все еще получаю предупреждение по электронной почте).
Не знаю, как проверил ipa яблоком, есть ли вероятность, что они ошибаются?

Я заметил, что в последнее время такая ситуация появляется с flutter и react-native (разработчики тоже сталкиваются с проблемами).

@ Carl-Wen, это тоже происходит с приложениями Ionic

Сегодня я получил такое же сообщение от Apple Store Connect. Странно то, что в моем приложении нет веб-представления. Я также попытался взглянуть на плагины Xamarin, чтобы узнать, используются ли какие-либо из них, но, похоже, ни один из них не использует UIWebView (хотя не на 100% уверен, потому что также существуют зависимости зависимостей).
Кто-нибудь знает, как определить использование UIWebView в приложении?

То же самое происходит и со мной. Первая попытка отправить приложение

Сегодня я получил такое же предупреждение от iTunesConnect

Я также получаю ту же ошибку несколько дней назад, есть ли способ решения?

Пожалуйста, проверьте мой ответ здесь, у меня есть проект на Xamarin.Forms 3.6.x, и он использует некоторые веб-просмотры, поэтому я создал настраиваемое средство визуализации для WebView только для iOS и изменил наследование с UIWebViewRenderer на WKWebViewRenderer . Вчера загрузил приложение в магазин и предупреждений не получил.

та же проблема

@FabriBertani Не могли бы вы поделиться своим кодом рендеринга?

У меня такая же проблема, но мое приложение НЕ ИСПОЛЬЗУЕТ веб-представления. Я предполагаю, что Apple обнаруживает использование в библиотеке Xamarin.iOS.

У вас есть какие-либо решения или обходные пути для этого? Также произошло, когда мы загрузили наше приложение. Мы также не используем WebView, и кажется, что @dhewitson прав, потому что это из-за UIWebView в библиотеке Xamarin.

Предполагая, что у вас нет пакета, который использует UIWebView, которым вы не можете управлять, этого должно быть достаточно. Затем просто используйте свой собственный рендерер вместо обычного XF WebView

namespace YourAppNameSpace
{
    public class CustomWebView : WebView
    {
    }
}

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

Та же проблема, есть ли у кого-нибудь обновления по этому поводу?

Всем привет! Спасибо за отчет и ваше исследование.

Мы отслеживаем это, и средство визуализации для WkWebView уже существует. Я продвинулся вперед в PR, сделав этот рендерер по умолчанию и отказавшись от UIWebView one. При этом эта ошибка должна исчезнуть.

Я ожидаю некоторых обзоров и отзывов о моем PR от остальной команды, но надеюсь, что это скоро будет решено.

Привет, @jfversluis , возможно ли, что исправление будет применено к более старой версии XamarinForms?
Я использую 3.4.0.1009999, и было бы очень сложно обновить до последней версии Xamarin.Forms.

@ngoquoc, мы могли бы перенести это обратно на более ранние версии, но я скептически отношусь к тому, что мы

@jfversluis спасибо за молниеносный ответ: D
Я абсолютно согласен с тем, что стоит перейти на более новую версию, но ситуация такова, что приближается к запланированному сроку выпуска. И у нас есть много устаревших зависимостей (которые поддерживают только до XF 3.x), а также использование критических изменений более новой версии.

@ngoquoc Нет проблем! Я полностью понимаю! Тем не менее, для вашего следующего выпуска, я думаю, будет разумно поискать обновления. Возможно, скоро появятся другие API-интерфейсы, которые устарят или станут устаревшими. Если мы можем что-то сделать, чтобы улучшить процесс обновления, свяжитесь с нами!

Надеюсь, мы сможем исправить эту проблему в версии 3.4. Обновление до 4.x абсолютно входит в наш план, и мы свяжемся с командой, если нам понадобится помощь (надеюсь, нет: D). Очень признателен за вашу поддержку!

@ngoquoc В любом случае, как написано выше, пока можно и ipa закачать, а в iOS13 этот класс еще есть.
Итак, это будет работать некоторое время

@KSemenenko , вы имели в виду, что "предупрежденное" приложение тоже может быть опубликовано в магазине Apple?
Если это так, отлично, мы можем успокоиться и отложить переход на WKWebView еще на некоторое время: D
Меня беспокоит только то, одобряет ли Apple такое приложение с предупреждениями.
Я нашел здесь опубликованную информацию об устаревании, но не указан официальный крайний срок / политика проверки в магазине Apple: https://developer.apple.com/documentation/uikit/uiwebview

@ngoquoc Исторически сложилось так, что они по-прежнему будут одобрять эти приложения. Предупреждение в основном говорит: «Эй, мы утвердим ваше приложение сейчас, но в будущем мы не собираемся этого делать, поэтому вам следует переключиться как можно скорее». Если вы публикуете до того, как они решат переключить это на ошибку, вы в порядке.

Благодарю. Я попробую отправить приложение сейчас и свяжусь с вами, ребята, с результатом, возможно, через несколько дней после того, как Apple его рассмотрит :)

@ngoquoc вчера мне удалось загрузить ipa в AppStore.

Скопировано с
https://github.com/xamarin/Xamarin.Forms/pull/7367#issuecomment -527558598

Моя текущая мысль заключалась в том, чтобы выяснить, почему эти рендеры не связаны (над чем я немного работал). Если RenderWith не приводит к связыванию рендереров, я не думаю, что это, и вся эта штука с пересылками служит какой-то цели (верно?)

В этом случае мы могли бы переключить тип по умолчанию (как в этом PR), а затем оставить WebViewRenderer. Если людям нужно вернуться к WebViewRenderer, они могут добавить для него экспорт, но если люди его не используют, то, надеюсь, он будет связан вне.

Одна из причин, которую я обнаружил, заключается в том, что обе сборки нашей платформы имеют
PreserveAttribute, указанный на уровне сборки, который пытается заставить сборку сохранять все типы

Я протестировал, добавив фиктивный класс к нашему проекту платформы, и с PreserveAttribute класс остается, но без него PreserveAttribute исчезает.

Все рендереры все еще остаются :-), но это еще младенец

Я провел быстрый тест с классом CheckboxRendererDesigner (потому что он нигде не используется)

И если я удалю обе эти строки кода
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

Затем он подключается.

Похоже, что предполагаемая цель RenderWith в этих проектах пересылки
https://github.com/xamarin/Xamarin.Forms/blob/bcf1d857f70c2d521fdbf59bd73445c7e77fe1fc/Stubs/Xamarin.Forms.Platform.cs#L112

Не обеспечивает достаточно слабого соединения, на которое рассчитывали

Похоже, это происходит потому, что сам флажок (элемент формы) не связан, что затем приводит к тому, что атрибут рендерер .

Если я изменю CheckboxRendererDesigner, чтобы
`` С #
[RenderWith (typeof (CheckBoxRenderer))]
внутренний класс _CheckBoxRenderer {}

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

`` ''

Затем он подключается ...

Итак, нужно выяснить, как связать CheckBox

Видели ли другие, что предупреждение исчезло, сделав это?

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

@PureWeen

У меня не сработало, у меня есть и рендерер, и запись в файле сборки, и я все еще получаю предупреждение.

Вы имели в виду, что просто добавить WKWebViewRenderer недостаточно для этого письма с предупреждением?

@PureWeen

У меня не сработало, у меня есть и рендерер, и запись в файле сборки, и я все еще получаю предупреждение.

В этом случае, возможно, у вас есть какой-либо другой пакет, который использует UIWebView, я просто использую этот обходной путь и не получаю никаких предупреждений от App Store :)

Привет, @ngoquoc, еще не повезло с процессом проверки?

просто хотел бы знать, будет ли соблюден крайний срок для нашего приложения при отправке на рассмотрение, независимо от «предупреждения».

Думаю, нам нужно знать, когда Apple начнет считать это основанием для отклонения файла IPA. Боюсь, они не объявят об этом публично.

Сегодня мне пришло письмо, что мое приложение прошло проверку Apple
так что пока работает :)

Обзор приложений работает в обычном режиме. Мое новое приложение опубликовано нормально. Может быть, просто предупреждение для будущего выпуска.

Обычно предупреждения - это просто предупреждения, и они дают вам много времени. В случае с Google дают около 2 лет. Я предполагаю, что предупреждение должно сказать вам, что они собираются удалить его из iOS 14 (я предполагаю) и что они действительно хотят, чтобы вы прекратили его использовать. Хотя, если вы щелкнете выключателем или если он включен по умолчанию, вы все равно не будете его использовать. Так что, если они не повернут переключатель и не сделают ошибку, чего я не думаю, потому что некоторым людям все еще нужна поддержка старых устройств.

Хорошо, вот что я сделал, чтобы проверить, что происходит.

Создал фиктивное приложение, которое я загрузил в Apple с последним стабильным пакетом Xamarin.Forms и приложением, отображающим только WebView. Вскоре после загрузки я получил это предупреждение. Чтобы убедиться, что предупреждение выходит каждый раз, и, таким образом, чтобы убедиться, мы можем предположить, что, когда предупреждение не приходит, мы устранили проблему, я создал другой двоичный файл без изменений, кроме номера версии. Предупреждение пришло снова. Это подтверждает: всякий раз, когда вы перестаете получать предупреждение, очевидно, проблема решена.

Затем я реализовал собственный рендерер с точным кодом, который здесь предоставил @FabriBertani . Сообщение все же пришло. Так что это не похоже на решение.

Затем я взял эту ветку и просто удалил WebRenderer и фактически удалил все ссылки на UIWebView. Это дало желаемый эффект. Apple больше не присылала мне предупреждение.

Все это, похоже, указывает на тот факт, что до тех пор, пока мы ссылаемся на UIWebView в нашем коде (читайте: пока UIWebViewRenderer все еще на месте), Apple обнаружит это и в конечном итоге перестанет принимать приложение. Чтобы получить максимальную обратную совместимость, нам нужно выяснить, почему компоновщик не удаляет WebViewRenderer, когда он больше не используется. Если мы это исправим , мой пиар будет иметь смысл и должен решить эту проблему раз и навсегда.

Как упоминал Джеймс (и другие), на данный момент это просто предупреждение, поэтому, даже если вы получите сообщение, на этом этапе не о чем беспокоиться, и оно будет работать. Но, конечно, мы должны быть готовы к тому, что Apple решит прекратить использование старого UIWebView API.

Итак, после проверки с командой iOS, похоже, что все, что наследуется от NSObject, никогда не будет связано, поэтому обещание RenderWith связывать рендереры я почти уверен, что никогда не работал на iOS.

Учитывая, что нам просто нужно полностью удалить рендерер и сломать всех

Или станьте хитрее с отдельным nuget и некоторой переадресацией типов

У меня тоже такая же проблема. Есть новости по этому поводу?

Привет, @ Mikilll94 , мы активно работаем над этим, однако полное решение будет недоступно в ближайшее время. Под «полным решением» я подразумеваю, что предупреждение перестанет поступать от Apple, когда вы отправите приложение Xamarin.Forms в магазин.

Чтобы отключить предупреждающее сообщение, нам нужно полностью удалить текущий WebViewRenderer из источника. Поскольку этот рендерер сейчас используется по умолчанию и всегда присутствует в источнике, это серьезное критическое изменение. С PR, связанным с этой проблемой, мы переключаем рендерер по умолчанию на WKWebViewRenderer который будет эффективно использовать новый WKWebView . Конечные пользователи Xamarin.Forms не должны ничего замечать об этом изменении. С помощью этого переключателя мы также отмечаем исходный WebViewRenderer как устаревший, чтобы дать пользователям Xamarin.Forms возможность внести необходимые изменения в свой код. Например, если у них есть собственные средства визуализации, которые полагаются на WebViewRenderer .

Однако, поскольку WebViewRenderer все еще привязан к источнику, Apple по-прежнему обнаруживает это при сканировании вашего приложения. В более поздней версии Xamarin.Forms, которая является самой ранней версией 4.5, мы полностью удалим WebViewRenderer и при этом предупреждающие сообщения от Apple должны прекратиться.

Сказав это, есть две вещи, которые нужно вынести:

1. Сообщение от Apple на данный момент является просто предупреждением, вам ничего не мешает отправлять новые версии, и они должны быть приняты в App Store. Вероятно, так будет до iOS 14, что даст нам (как минимум) год.
2. Опять же, удаление WebViewRenderer из источника является серьезным критическим изменением, которое мы бы не хотели делать, но на данный момент у нас нет выбора. Поэтому нам нужно потратить некоторое время, чтобы предупредить пользователей об этом и сначала постепенно переключиться на новую реализацию, а только затем удалить этот класс из источника. Это длительный процесс, но он должен произойти задолго до выпуска iOS 14.

Я надеюсь, что это решит все ваши опасения по этому поводу, если нет, дайте мне знать. Я буду рад ответить на любые ваши вопросы по этому поводу.

Спасибо за понимание и терпение!

@jfversluis
Спасибо за блестящий ответ :)

@jfversluis Спасибо за ответ
Подскажите, пожалуйста, как удалить WebViewRenderer из исходников?

@NehalOsama единственный способ сделать это - клонировать этот репозиторий XamForms, удалить файл WebViewRenderer.cs из проекта Platforms.iOS, изменить все ссылки так, чтобы они указывали на WKWebViewRenderer и создать свои собственные библиотеки DLL и используйте это в своем приложении.

Я настоятельно не рекомендую этого делать . Это означает, что вы не можете обновиться до версий, которые мы выпустим, поэтому вы никогда не получите никаких исправлений ошибок или чего-либо еще, не потеряв сделанное вами изменение. Или вам придется повторять этот процесс каждый раз, когда вы хотите обновить.

Если вы не возражаете, я спрошу; почему бы не подождать? Сообщение от Apple - это просто предупреждение, и мы сделаем это задолго до того, как Apple фактически начнет отклонять приложения. Здесь не о чем беспокоиться.

@jfversluis
Большое спасибо, несмотря на удаление ссылок и предупреждения, причина в том, что наш клиент настаивает на интеграции с другим приложением с помощью webkit.
Я сделал как https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -527294907,
но как я могу убедиться, что моим настраиваемым средством визуализации является WKWebViewRenderer, а не UIWebView ?!
Есть ли между ними очевидная разница или что-нибудь, что может доказать это клиенту ?!

Дело в том, что вы не должны видеть между ними никакой разницы, если бы мы сделали свою работу правильно 😉

Я не уверен, сколько доказательств им понадобится. Вы можете копаться в инспекторах или материалах UITest, чтобы выяснить, какие именно типы порождаются. Однако самый простой способ - просто установить точку останова в созданном вами пользовательском рендерере и посмотреть, будет ли оно выполнено. Если это так, то используется WKWebView . Кроме того, вы можете реализовать небольшой механизм в своем настраиваемом рендерере, который загружает определенную страницу с собственной платформы, снова вы можете установить точку останова и убедиться, что она будет использовать WKWebView вместо UIWebView .

Если вы хотите переключить все обычные элементы управления WebView на WKWebViewRenderer без необходимости создавать настраиваемый рендерер и просто использовать WebView вместо наследования, вы можете добавить эту строку в AssemblyInfo.cs в вашем проекте iOS:

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

Бинарный файл моего приложения был отклонен сегодня из-за этого. Я уже использую 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

Несмотря на этот пассивный язык («перестанет принимать»), мой двоичный файл не был обработан и не стал доступным для выпуска.

Это сейчас критично. Я не могу выпускать новые версии своего клиентского приложения.

Какое время прибытия для этого исправления?

Привет, @joehanna, спасибо за сообщение. Вы абсолютно уверены? В самом сообщении говорится, что доставка прошла успешно, и нет причин предполагать, что что-то отличается от того, когда эта проблема была впервые открыта. Пройдет некоторое время, прежде чем Apple обработает весь двоичный файл после отправки такого сообщения.

Я вижу, что ваш комментарий был написан около часа назад, теперь он должен появиться на портале разработчика. Сможете ли вы убедиться, что он действительно не прошел?

Также

мой двоичный файл не был обработан и не стал доступен для выпуска.

как ты это проверил? Если перейти к определению приложения, затем «Активность» в разделе «Все сборки», вы его не увидите?

Спасибо за быстрый ответ @jfversluis. Я не получил письмо с подтверждением, и оно не отображается в доступных сборках. Я предполагаю, что может быть задержка обработки? По моему опыту, двоичный файл обрабатывается менее чем за 20 минут. Я проверю это еще раз через некоторое время и доложу.

Ах, это хороший момент, о котором вы здесь говорите. С выходом iOS 13 может возникнуть некоторая дополнительная активность, и люди будут отправлять множество сборок для этого. Я только что создал новую версию фиктивного приложения, которое вы можете увидеть выше, и отправил его, просто чтобы проверить и посмотреть, что происходит.

Я сообщу вам, как только что-нибудь увижу.

Спасибо за отчет в любом случае!

@joehanna Сначала я получил предупреждение, а через несколько минут получил второе изображение. Итак, не уверен, что происходит с вашей сборкой, но похоже, что это не связано с использованием UIWebView

Наконец-то это произошло. Простите за драму. Никогда раньше это не занимало так много времени. Спасибо, что заметили это.

SDK_Bug

Проблема в том, что компилятор не удаляет ненужные файлы классов или библиотеки.
Команды разработчиков Xamarin должны ссылаться на последние политики разработки для Apple.

@jfversluis У нас

Спасибо!
ООО «КомпаНова»

@dmitrymal есть несколько причин

Xamarin.iOS решит их проблему, а затем мы собираемся надстроить ее, чтобы решить нашу

У нас есть несколько решений, над которыми мы работаем, и мы будем обновлять эту проблему по мере продвижения.

Почему эта ветка все еще помечена как s / unverified?

Нет, это не @taublast 🤡

Хотя я понимаю, что это исправление временно и не срочно, когда оно будет сделано, будет ли оно перенесено на предыдущие версии XF? У нас есть большой набор приложений, созданных в версии 3.4, которые из-за различных проблем с зависимостями всегда терпели неудачу при попытке обновления до XF 4.0 или выше.

@ 1888games Я думаю, что это маловероятно, в том числе в зависимости от того, каким будет окончательное исправление.

https://github.com/xamarin/Xamarin.Forms/pull/7367 был объединен, но это только часть головоломки, поэтому не ждите, что предупреждение исчезнет

Он по-прежнему потребует исправлений компоновщика внутри Xamarin.Forms SDK и Xamarin.IOS SDK.

• https://github.com/xamarin/Xamarin.Forms/tree/ios_linker
• И затем некоторые дополнительные исправления компоновщика внутри самого Xamarin.iOS SDK

Так в какой версии XamarinForms это исправлено?

@ s-bhavin-shah, нам нужно пройти несколько этапов и шагов, чтобы исправить это и убрать это навсегда. Поэтому на данный момент это не исправлено в определенной версии Xamarin.Forms. Я просто хочу повторить, что на данный момент нет причин для беспокойства. Сообщение от Apple - это просто предупреждение на данный момент и будет предупреждением в ближайшее время.

К тому времени, когда появится предупреждение, Apple отклоняет приложения по этой причине, мы обязательно будем готовы. Мы будем держать вас в курсе этого выпуска. Теперь произошло то, что мы нашли способ заставить компоновщик фактически вырезать (основные) объекты Xamarin, которые не используются. Кроме того, мой PR был объединен, что сделало WKWebViewRenderer значением по умолчанию.

После этого последний шаг - выпустить решение «связывание iOS». Когда это происходит, WKWebViewRenderer по умолчанию, а WebViewRenderer не используется в вашем коде, должно привести к удалению из результирующего двоичного файла, который отправляется в Apple. Что, как говорится; легче сказать, чем сделать, выпустить решение для связывания iOS, и это займет больше времени.

Положительным моментом здесь является то, что нам, вероятно, не придется использовать полное решение для критических изменений, но мы можем постепенно перевести всех на это решение.

Надеюсь, сейчас это ответит на все ваши вопросы. Если нет, дайте мне знать!

При отказе от UIWebView и замене его на WkWebView вы должны учитывать эту проблему.
https://github.com/xamarin/Xamarin.Forms/issues/8028

Вы можете сломать приложения людей, если просто замените UIWebView на WkWebView.

@ Mikilll94 Хотя точка зрения верна, простой факт заключается в том, что Apple начнет отклонять двоичные файлы, которые все еще используют UIWebView. Так что, даже если Xamarin ничего не сделает, это все равно будет критическим изменением, потому что Apple (вероятно, в следующие 9 месяцев) не позволит вам обновлять приложение без внесения этого изменения.

@ cabal95
Верно.

Но я хотел показать, что есть проблема с WkWebView, которая очень важна и затронет многих разработчиков, и в настоящее время для нее нет обходного пути.

Та же проблема! Какая-нибудь идеальная работа?

Привет, @samirgcofficial, спасибо, что сообщили о своих выводах. Вы видели комментарий, о котором мы говорим, вверху: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -542363338?

Это должно в значительной степени объяснить текущий статус :)

Резюме: на данный момент нет обходного пути или решения, мы работаем над этим. Но это сообщение от Apple - просто предупреждение, и вы сможете без проблем отправлять свои приложения, просто это предупреждающее сообщение.

Если возникнут вопросы, дайте мне знать!

@jfversluis @samirgcofficial
По моему опыту, Apple больше не принимает приложения, которые показывают UIWebView в своем двоичном формате. Мы больше не можем отправлять наши приложения Xamarin в App Store. Таким образом, это не только предупреждение, это очень важный вопрос.
С другой стороны, если у вас есть решение о том, как опубликовать наши приложения, сообщите нам, как это сделать?

@JawadJaber Да, это серьезная проблема! Я не могу провести внешнее тестирование своего приложения в магазине приложений для тестового полета. Но внутреннее тестирование приложения возможно, и этот WebView никогда не влияет на внутреннее тестирование.
Сценарий заключался в создании внешней ссылки и публикации, что невозможно сделать в тестовом полете. Любое решение?

@JawadJaber, если вы получаете другое сообщение от Apple, в котором говорится, что они отклонили ваш двоичный файл, а не просто предупреждают, отправьте снимок экрана или что-то еще, чтобы предоставить более подробную информацию. Я успешно отправил двоичный файл в Apple в пятницу без каких-либо проблем, кроме предупреждения по электронной почте.

Я просто отправляю двоичный файл и получаю только предупреждение по электронной почте

@JawadJaber @samirgcofficial, не могли бы вы рассказать мне, почему вы думаете, что ваш двоичный файл отклонен по этой причине? У нас нет причин думать, что что-либо, кроме этого, все еще является предупреждением. Многие люди подтверждают это, и текст предупреждения в сообщении электронной почты не изменился с момента создания этой проблемы.

Мы согласны с тем, что это очень важный вопрос, поэтому мы усердно работаем над решением, и мы настолько ясны и прозрачны, насколько могли бы быть на данный момент.

Ранее в этой беседе был другой человек, который думал, что его двоичный файл был отклонен, но обработка заняла немного больше времени. Может быть, это так и для вас?

Хорошо, я признаю, что теперь он работает правильно с Apple.
Хотя 3 недели назад он был отклонен, и я связался со службой поддержки App Store, и они сказали то же самое (их политика).
Но теперь он работает. Я думаю, что Apple просто изменила свою политику в этом случае. Спасибо @jfversluis , @ martijn00 @ cabal95

Хорошо, я получил еще одно сообщение от команды магазина приложений, что я ограничиваю доступ всех пользователей к приложению и разрешаю людям определенного региона для проверки OTP с помощью TWILO. Я должен исключить ограничения, вот и все, и сейчас приложение находится на бета-тестировании :). Это все. Всем спасибо.

те же проблемы

довольно сложно объяснить клиентам, что с нашим приложением все в порядке, это просто предупреждение и т. д. ((

Я полностью понимаю @YuliaLoyko. К сожалению, мы движемся так быстро, как можем.

жду 4.4

@ prasannamca1107 просто для ясности и не

С другой стороны, я видел рабочее исправление, поэтому, как я уже упоминал, мы работаем над этим, но пройдет некоторое время, прежде чем все выровняется и мы сможем передать его вам.

Пока что беспокоиться не о чем, сообщение от Apple по-прежнему является предупреждением!

Я следил за веткой на форуме xamarin и нашел эту ссылку, которая, я думаю, должна работать.

нет такого же предупреждения я пробовал

@softsan , спасибо, что поделились! К сожалению, в настоящее время это не решение. На данный момент нет (простого) решения. Единственное, что вы могли бы сделать, чего я настоятельно не рекомендую , - это создавать собственные пакеты Xamarin.Forms с удаленным из решения UIWebViewRenderer.

Мы все еще усердно работаем над решением, не беспокойтесь! :)

В прошлую пятницу я отправил новое приложение и получил такое же предупреждение, но это было просто предупреждение.
Приложение одобрено и без проблем размещено в магазинах приложений.

@jfversluis , @softsan Я написал свой собственный рендерер для WebView, который возвращает WKWebView. Я протестировал код и опубликовал его в магазине, но до сих пор получаю предупреждение. Мой модуль визуализации следует типичному шаблону для модуля визуализации, но вот краткий фрагмент соответствующего кода:

если (Control == null)
{
_contentController = новый 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 = новый WKWebView (cgRect, config)
{
NavigationDelegate = новый WKNavigationDelegate ()
};

                    SetNativeControl(_wKWebView);
                }

В моем коде есть только одно место, где используется веб-браузер, и я отладил этот код, проверил типы данных и подтвердил, что они верны, но я получил ошибку от Apple. Я отправил заявку на проверку в группу проверки и жду ответа.

@seanstilson это бесполезно. Как указывалось ранее в этой проблеме, даже если вы создаете настраиваемое средство визуализации, которое использует WKWebView, UIWebViewRenderer все равно будет включен в двоичные файлы Xamarin.Forms, поскольку он работает прямо сейчас. Мы работаем над тем, чтобы это изменить, но пока мы этого не сделаем, вы уже ничего не можете сделать, чтобы это изменить.

Apple, вероятно, просто скажет вам, что есть ссылка на UIWebView. Не в вашем коде, а через код Xamarin.Forms, который все еще находится внутри вашего приложения.

Сказав это; мы обязательно исправим это так или иначе, прежде чем Apple действительно перестанет принимать двоичные файлы из-за этого.

Извините, я пропустил ранее сообщение о создании UIWebViewRenderer
в двоичные файлы @jfversluis , плохо. Спасибо за ответ!

В четверг, 14 ноября 2019 г., в 11:54 Джеральд Верслуис [email protected]
написал:

@seanstilson https://github.com/seanstilson это бесполезно. Так как
указано ранее в этом выпуске, даже если вы создаете настраиваемое средство визуализации,
использует WKWebView, UIWebViewRenderer по-прежнему будет включен в
Двоичные файлы Xamarin.Forms из-за того, как они работают прямо сейчас. Мы работаем над
изменить это, но пока мы этого не сделаем, вы ничего не можете сделать, чтобы изменить это
в это время.

Apple, вероятно, просто скажет вам, что есть ссылка на UIWebView. Не
в вашем коде, но через код Xamarin.Forms все еще внутри вашего приложения.

Сказав это; мы обязательно исправим это так или иначе, прежде чем
Apple действительно перестает принимать двоичные файлы из-за этого.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/xamarin/Xamarin.Forms/issues/7323?email_source=notifications&email_token=AMVYZVVKIGZKMMH5XOS2QATQTWGF5A5CNFSM4ISLFU32YY3PNVWWK3TREXWMWWWK3TREXWMWWWWK3TREXMWMWWWWK3TREXMXWMWWWWK3TREXMWWWWWWK3TREXCMWMXVMXWMXWMXWMXWMXWMXVMXWM8
или отписаться
https://github.com/notifications/unsubscribe-auth/AMVYZVUT5A73R4SXSQFRDMDQTWGF5ANCNFSM4ISLFU3Q
.

@seanstilson , не беспокойтесь об этом. Здесь много действий, представляю, вы что-то упускаете :)

Привет, друзья, пока мы заблокируем эту проблему, пока мы ждем результатов от команды Xamarin.iOS, прежде чем мы сможем продолжить. Таким образом, мы сможем должным образом отследить эту проблему, и люди, столкнувшиеся с ней, смогут найти наиболее актуальную информацию напрямую, вместо того, чтобы проходить здесь весь разговор. Когда будет что-то новое, мы обязательно сообщим.

Чтобы получить хорошее представление о том, что происходит, прочитайте этот комментарий здесь: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -532228577

Последний прогресс на данный момент можно найти здесь: https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -542363338

Суть в том, что мы работаем над этой проблемой таким образом, чтобы обеспечить обратную совместимость, и мы будем готовы, так или иначе, до того, как Apple фактически начнет отклонять приложения из-за этого.

Прямо сейчас единственное, что вы получаете предупреждающее сообщение от Apple, которое пока можно спокойно игнорировать.

Спасибо за понимание и терпение!

Небольшое обновление по этому поводу: # 8001 был объединен в качестве первого шага к предлагаемому исправлению. Однако это не означает, что проблема исчезнет в следующей версии.

Как мы уже упоминали ранее, в Xamarin.iOS нужно кое-что изменить, чтобы это работало. Всякий раз, когда они это сделают, правильная версия Xamarin.iOS вместе с этим кодом (начиная с 4.5), наконец, исчезнет.

Для ясности: одна только версия Xamarin.Forms 4.5 НЕ устранит эту проблему. Когда на горизонте появится полное исправление, я обязательно обновлю его снова.

Спасибо!

Apple выпустила короткое заявление, в котором разъясняет свои планы по прекращению поддержки UIWebView . Я думаю, что самое важное:

Магазин приложений больше не будет принимать новые приложения, использующие UIWebView, с апреля 2020 года и обновления приложений с использованием UIWebView с декабря 2020 года.

Это означает, что у нас еще есть время, чтобы найти решение, каким бы оно ни было. Тем временем мы изучаем предпочтительное решение. Вместе с командой Xamarin.iOS нам удалось отправить приложение в магазин, которое не вызывает предупреждения, но при этом сохраняет обратную совместимость. Это означает, что нельзя отказываться от (теперь) устаревшего WebViewRenderer . Мы все еще решаем, является ли это решение _the_, основываясь на нескольких факторах, но мы все еще работаем над ним и будем уверены, что мы готовы. По крайней мере, теперь мы знаем, когда нужно быть готовым - спасибо за терпение!

Всем отличные новости! Есть последнее исправление, которое вы скоро должны будете использовать.

Это действительно требует небольшой работы с вашей стороны, в настоящее время я работаю над небольшой документацией, которая описывает, что это такое. Не волнуйтесь, это не так уж сложно!

Когда это будет в прямом эфире и все биты будут доступны для вас, я опубликую его здесь. Никаких твердых обещаний, но это должно произойти довольно скоро и задолго до крайнего срока в апреле.

Еще раз спасибо, что остались с нами в этом вопросе!

Решение здесь!

Все биты на месте, время решения! TL; DR: все описано в этой части документации здесь .

Убедитесь, что вы используете последнюю версию Visual Studio (для Mac) на стабильном канале, что должно указать вам правильный путь. На данный момент вам нужно будет использовать предварительную версию Xamarin.Forms 4.5-pre1. Я понимаю, что это может быть вариант не для всех, но будьте уверены, стабильный пакет будет выпущен задолго до крайнего срока. Стабильная 4.5 запланирована на середину-конец февраля.

Наконец, установите флаг --optimize=experimental-xforms-product-type в настройку дополнительных аргументов mtouch iOS, и вы должны избавиться от предупреждения Apple об устаревании. Если у вас, конечно, нет собственных ссылок на UIWebView 🙂

Я хотел бы попросить вас попробовать это как можно скорее. Может быть, не выпускать в магазин актуальную новую версию на основе пакета предварительного просмотра Forms, но, по крайней мере, загрузить сборку, чтобы убедиться, что это решение работает правильно. Как только вы это сделаете, вы можете просто выполнить обновление до стабильного пакета 4.5 и с уверенностью выпустить новую версию.

Если вы столкнетесь с чем-либо при использовании этого решения, свяжитесь со мной напрямую (gerald.versluis [a с длинным хвостом] microsoft.com) или откройте новую проблему в репозитории. Конечно, всегда приветствуются и положительные отзывы 😉

Еще раз спасибо!