Xamarin.forms: ITMS-90809:不推荐使用的API-Apple将停止接受使用UIWebView API的应用程序的提交

创建于 2019-08-30  ·  99评论  ·  资料来源: xamarin/Xamarin.Forms

https://docs.microsoft.com/zh-cn/xamarin/xamarin-forms/user-interface/webview?tabs=windows#uiwebview -deprecation-and-app-store-rejection-itms-90809


亲爱的开发人员,

我们确定了您的应用“ xxxx” 1.0.11(1.0.11)最近交付时出现的一个或多个问题。 交付成功,但是您可能希望在下一次交付中更正以下问题:

ITMS-90809:不推荐使用的API-Apple将停止接受使用UIWebView API的应用程序的提交。 有关更多信息,请参见https://developer.apple.com/documentation/uikit/uiwebview

解决问题之后,可以使用Xcode或Application Loader将新的二进制文件上传到App Store Connect。

最好的祝福,

App Store团队

但是我确定我用WKWebView(WKWebViewRenderer)替换了UIWebView。

in-progress iOS 🍎 bug

最有用的评论

@ Mikilll94 ,您好,我们正在积极地进行这项工作,但是完整的解决方案将很快无法使用。 有了“完整解决方案”,我的意思是每当您向商店提交Xamarin.Forms应用程序时,警告将不再来自Apple。

要停止警告消息,我们需要从源中完全删除当前的WebViewRenderer 。 由于该渲染器是当前的默认设置,并且已经永久存在于源代码中,因此这是一个重大的重大更改。 有了与此问题相关的PR,我们将默认渲染器切换为WKWebViewRenderer ,它将有效地使用新的WKWebView 。 Xamarin.Forms的最终用户应该不会注意到有关此更改的任何信息。 通过此开关,我们还将原始WebViewRenderer标记为已弃用,以使Xamarin.Forms用户可以在其代码中进行必要的更改。 例如,如果他们有依赖WebViewRenderer自定义渲染器。

但是,由于WebViewRenderer仍在源中链接,因此Apple在扫描您的应用程序时仍然会注意到这一点。 在Xamarin.Forms的更高版本中,它是最早的4.5版本,我们将完全删除WebViewRenderer并且苹果的警告消息应该停止。

话虽如此,有两件事要摘走:

  1. Apple发出的消息只是暂时的警告,没有阻止您提交新版本的信息,它们应该被App Store接受。 直到iOS 14(至少给我们一年),这种情况可能会一直如此。
  2. 同样,从源代码中删除WebViewRenderer是我们不愿做的重大突破,但目前我们别无选择。 因此,我们需要一些时间来警告用户有关此情况,并逐渐逐渐切换到新的实现,然后才从源中删除该类。 这是一个漫长的过程,但应该会在iOS 14发行之前完成。

我希望这能解决您对此的所有担忧,如果没有,请告诉我。 我很高兴回答您对此可能有的任何疑问。

感谢您的理解和耐心等待!

所有99条评论

我也遇到了这个问题,我们正在使用:Xamarin.Forms 3.6.0.539721

每个版本的Forms都会得到此信息,因为iOS中的WebViewRenderer实现了UIWebView,并且即使您切换了WkWebViewRenderer,该文件也会保留。 我不知道在构建过程中是否可以将文件链接出去。

@ swansca79-这几乎是我所担心的。 我希望我们能像您所说的那样将其链接出去。

苹果公司对此要求的最后期限是什么? 我找不到...

我想这会影响所有应用程序,无论它们是新提交的还是更新的。 如果是这样,那么链接旧的渲染器又有什么意义呢? 应该将其从源代码中删除。 另外,我们需要找出这是否是iOS 13要求...

这里同样的问题。 我正在使用Xamarin.Forms 4.2.0.709249

我在iOS项目的AssemblyInfo.cs中添加了以下行,但没有任何改变:

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

我也想知道Apple提交应用程序的截止日期。

这里同样的问题。
有人知道苹果要求的截止日期吗? 或者,如果Xamarin正在处理此更新

UIWebView仍处于iOS13测试版中,因此直到iOS14才可能存在。

如果查看Xamarin.Forms.iOS渲染器文件夹,您会发现他们在2个月前添加了WKWebViewRender。 我假设您可以创建从该渲染器继承的自己的WebView(如果您的项目上没有XF的原始版本,则可以复制/粘贴代码)来解决WebView的此问题。

WkWebViewRenderer.cs

伙计们,我发现有些奇怪,我更改了应用程序捆绑包标识符并将其再次提交给应用程序商店,但我没有收到来自苹果的警告电子邮件。
我的情况:三天前,在将ipa提交到testflight之后,我没有收到来自苹果的任何警告电子邮件,然后在进行了一些与Webview无关的更改后,我收到了该电子邮件,然后尝试查找为什么采用以下方式:
1.尝试用WKWebViewRenderer替换UIWebViewRenderer;
2.删除WebView;
3.删除第三方nuget lib(我最近添加了);
但是他们对警告毫无用处(我仍然收到警告电子邮件)。
我不知道苹果是如何检查ipa的,他们是否有可能出错?

我注意到这种情况最近随着动荡和本机出现(开发人员也遇到了问题)。

@ Carl-Wen这也发生在Ionic应用程序上

我今天从Apple Store Connect得到了同样的信息。 奇怪的是我的应用程序中没有任何Web视图。 我还尝试查看Xamarin插件以查看它们是否使用过,但是似乎它们都没有使用UIWebView(虽然不是100%可以肯定,因为也存在依赖关系)。
有人知道如何识别应用程序中的UIWebView用法吗?

我也发生同样的事情。 第一次尝试提交应用

我今天从iTunesConnect收到了相同的警告

几天前我也遇到同样的错误,有什么解决方法吗?

请在这里检查我的答案,我在Xamarin.Forms 3.6.x上有一个项目,它使用了一些webviews,所以我只为iOS创建了WebView的自定义渲染器,并将继承从UIWebViewRenderer更改WKWebViewRenderer 。 昨天我将应用程序上传到商店,但未收到任何警告。

同样的问题

@FabriBertani您能否分享您的自定义渲染代码?

我遇到了同样的问题,但是我的应用程序不使用任何Web视图。 我假设Apple正在Xamarin.iOS库中检测使用情况。

您对此有任何解决方案或解决方法吗? 当我们上传应用程序时也发生了。 我们也不使用WebViews,似乎@dhewitson是正确的,这是由于Xamarin库上的UIWebView。

假设您没有使用无法控制的使用UIWebView的程序包,那么这足够了。 然后,只需使用自定义的rendrer而不是常规的XF WebView

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

同样的问题,有人对此进行更新吗?

嘿大家! 感谢您的举报和您的研究。

我们正在对此进行跟踪,并且WkWebView的渲染器已经存在了一段时间。 我在PR上前进了一步,使该渲染器成为默认渲染器并弃用了UIWebView一个。 这样,该错误应消失。

我希望团队其他成员对我的PR进行一些评论和反馈,但是希望这会尽快解决。

@jfversluis ,您好,该修补程序可以应用于旧版本的XamarinForms吗?
我正在使用3.4.0.1009999,因此要升级到最新版本的Xamarin.Forms会花费很多精力。

@ngoquoc,我们可能会将其反向移植到较早的版本,但是我怀疑我们会将其一直恢复到3.4。 为什么要花费太多精力进行升级? 可能值得对该领域进行调查:)

@jfversluis感谢闪电般的快速回复:D
我绝对同意值得升级到新版本,但情况确实接近我们计划的发布期限。 而且,我们有许多旧版依赖项(仅支持XF 3.x)以及新版本重大更改的用法。

@ngoquoc没问题! 我完全理解! 不过,对于您的下一个版本,我确实认为寻求升级是明智的。 可能会有更多API即将弃用或弃用。 如果我们可以做些什么来改善您的升级体验,请联系!

希望我们可以在3.4上解决此问题。 绝对要升级到4.x,如果需要帮助,我们将与团队联系(希望不是:D)。 非常感谢您的支持!

@ngoquoc无论如何,如上所述,虽然您可以上传ipa,但在iOS13中此类仍然存在。
所以这会工作一段时间

@KSemenenko您是说“警告”应用程序也可以发布到Apple Store吗?
如果是这样,那就很好,我们可以冷静下来,并将切换到WKWebView的时间推迟更多时间:D
我唯一关心的是苹果是否批准带有警告的此类申请。
我在此处找到了有关弃用的已发布信息,但未指定官方截止日期/ Apple商店审查政策: https :

@ngoquoc从历史上看,是的,他们仍然会暂时批准这些应用程序。 警告基本上是说:“嘿,我们暂时批准您的应用程序,但是将来我们不会批准,因此您应该尽快切换”。 只要您在他们决定将其切换为错误之前发布,就可以了。

谢谢。 我将尝试立即提交该应用程序,并可能在Apple审核后的几天内将结果反馈给你们:)

@ngoquoc昨天我能够将ipa上传到AppStore。

复制自
https://github.com/xamarin/Xamarin.Forms/pull/7367#issuecomment -527558598

我目前的想法是弄清楚为什么这些渲染器没有被链接出去(我一直在努力)。 如果RenderWith不会导致渲染器被链接出去,那么我认为它不起作用,并且整个转发器都可以满足任何目的(对吗?)

在那种情况下,我们可以切换默认类型(例如此PR),然后保留WebViewRenderer。如果人们需要还原到WebViewRenderer,则可以为其添加Export,但是如果人们不使用它,则希望它可以链接出来。

我发现的一个原因是我们的平台程序集都具有
在程序集级别指定的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

没有提供希望的足够弱的连接

似乎正在发生这种情况,因为没有链接Checkbox(表单元素)本身,这随后导致RenderWith属性保持了Renderer。

如果我将CheckboxRendererDesigner更改为某些不存在的类的属性
C#
[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文件。 我担心他们不会公开宣布这一点。

今天我收到一封信,说我的应用程序通过了苹果审查
所以现在它可以工作了:)

应用审核照常进行。 我的新应用正常发布。 也许只是对将来发布的警告。

通常,警告只是警告,它们会给您很多时间。 如果是Google,他们给您大约2年的时间。 我在这里的假设是,警告是要告诉您他们将要从iOS 14中删除它(我猜是真的),并且他们真的希望您停止使用它。 虽然如果您拨动开关或默认情况下处于打开状态,则无论如何都不会使用它。 因此,除非他们拨动开关并使其出错,否则我认为他们不会这样做,因为有些人仍然需要支持较旧的设备。

好的,这就是我所做的以验证发生了什么。

创建了一个虚拟应用程序,我使用最新的稳定Xamarin.Forms包将其上传到Apple,并且该应用程序仅显示WebView。 上传后不久,我收到了此警告。 为了验证警告是否每次都发出,从而验证我们可以假设警告不出现时我们已经解决了该问题,我创建了另一个二进制文件,除了版本号外没有任何更改。 警告消息再次出现。 这样可以确认:每当您停止收到警告时,显然问题已得到解决。

然后,我继续使用@FabriBertani在此处提供的确切代码实现自定义渲染器。 消息仍然到来。 因此,这似乎不是解决方案。

然后,我转到此分支,并删除了WebRenderer,并有效地删除了对UIWebView的所有引用。 这具有理想的效果。 苹果现在不再向我发送警告。

所有这些似乎都表明了这样一个事实,只要我们在代码中引用UIWebView(阅读:只要UIWebViewRenderer仍然存在),Apple就会检测到它并最终将停止接受该应用程序。 为了获得最大的向后兼容性,我们需要研究为什么链接器不再使用时不再删除WebViewRenderer。 如果我们解决了这个问题,我的PR就有意义,应该一劳永逸地解决这个问题。

就像James(和其他人)提到的那样,这只是一个警告,因此,即使您收到消息,此刻也无需担心,它会起作用。 但是,当然,我们需要为Apple决定停止允许旧的UIWebView API做好准备。

因此,在与iOS团队核实之后,似乎从NSObject继承的任何内容都将永远不会被链接出去,因此RenderWith承诺可以链接出渲染器,我敢肯定我从来没有在iOS上使用过

鉴于我们只需要完全删除渲染器并破坏所有人

或者通过单独的nuget和某些类型的转发来狡猾

我也有同样的问题。 这事有进一步更新吗?

@ Mikilll94 ,您好,我们正在积极地进行这项工作,但是完整的解决方案将很快无法使用。 有了“完整解决方案”,我的意思是每当您向商店提交Xamarin.Forms应用程序时,警告将不再来自Apple。

要停止警告消息,我们需要从源中完全删除当前的WebViewRenderer 。 由于该渲染器是当前的默认设置,并且已经永久存在于源代码中,因此这是一个重大的重大更改。 有了与此问题相关的PR,我们将默认渲染器切换为WKWebViewRenderer ,它将有效地使用新的WKWebView 。 Xamarin.Forms的最终用户应该不会注意到有关此更改的任何信息。 通过此开关,我们还将原始WebViewRenderer标记为已弃用,以使Xamarin.Forms用户可以在其代码中进行必要的更改。 例如,如果他们有依赖WebViewRenderer自定义渲染器。

但是,由于WebViewRenderer仍在源中链接,因此Apple在扫描您的应用程序时仍然会注意到这一点。 在Xamarin.Forms的更高版本中,它是最早的4.5版本,我们将完全删除WebViewRenderer并且苹果的警告消息应该停止。

话虽如此,有两件事要摘走:

  1. Apple发出的消息只是暂时的警告,没有阻止您提交新版本的信息,它们应该被App Store接受。 直到iOS 14(至少给我们一年),这种情况可能会一直如此。
  2. 同样,从源代码中删除WebViewRenderer是我们不愿做的重大突破,但目前我们别无选择。 因此,我们需要一些时间来警告用户有关此情况,并逐渐逐渐切换到新的实现,然后才从源中删除该类。 这是一个漫长的过程,但应该会在iOS 14发行之前完成。

我希望这能解决您对此的所有担忧,如果没有,请告诉我。 我很高兴回答您对此可能有的任何疑问。

感谢您的理解和耐心等待!

@jfversluis
感谢您的精彩回答:)

@jfversluis感谢您的回答
请您告诉我如何从源中删除WebViewRenderer吗?

@NehalOsama唯一的方法是克隆此XamForms存储库,从Platforms.iOS项目中删除WebViewRenderer.cs文件,更改所有引用以指向WKWebViewRenderer并构建自己的DLL和在您的应用中使用它。

我强烈建议不要这样做。 这样做意味着您无法升级到我们将发布的版本,因此,在不丢失自定义更改的情况下,您将永远不会收到任何错误修正或任何内容。 或者,您每次需要升级时都需要再次重复此过程。

如果你不介意我问; 为什么不等? 来自苹果的消息只是一个警告,在苹果实际上开始拒绝应用程序之前,我们会做得很好。 此时,您无需担心。

@jfversluis
非常感谢,无论删除引用和警告,原因是我们的客户坚持要求我们使用Webkit与另一个应用程序集成
我制作为https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -527294907,
但是如何确定我的自定义渲染器是WKWebViewRenderer而不是UIWebView?
它们之间是否有明显的区别,或者可以向客户证明的任何区别?

从某种意义上说,如果我们做得对,您应该不会看到它们之间的任何区别😉

我不确定他们需要多少证据。 您可以使用检查器或UITest内容进行挖掘,以挖掘出所生成的实际类型。 不过,最简单的方法是在您创建的自定义渲染器中简单地设置一个断点,然后查看是否被击中。 如果是这样,则使用WKWebView 。 此外,您可能会在自定义渲染器中实现一种从本地平台加载特定页面的机制,再次可以设置一个断点并验证其将使用WKWebView而不是UIWebView

如果您想将所有常规WebView控件切换到WKWebViewRenderer而不必创建自定义渲染器,而只使用WebView而不是继承,则可以将此行添加到您的iOS项目中的AssemblyInfo.cs

[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

尽管使用了这种被动语言(“将停止接受”),但我的二进制文件尚未处理,无法用于该发行版。

现在这很关键。 我无法发布客户应用程序的任何新版本。

此修复程序的ETA是多少?

@joehanna感谢您的举报。 你确定吗该消息本身表示交付成功,没有理由假定与第一次打开此问题时有所不同。 在发送这样的消息后,Apple处理完整个二进制文件确实需要一些时间。

我看到您的评论是大约一个小时前发布的,现在应该会在开发人员门户中显示。 您能否验证它确实没有通过?

我的二进制文件未处理,无法发布。

您如何验证的? 如果转到应用程序定义,然后转到“所有构建”下的“活动”,您看不到吗?

image

感谢您的快速回复@jfversluis。 我没有收到确认电子邮件,也没有出现在可用的版本中。 我想可能还有一个待处理的积压? 根据我的经验,二进制文件在不到20分钟的时间内就可以完成。 我会在一段时间后再次检查并报告。

啊,那是你要谈的一个好观点。 iOS 13可能还会有一些额外的活动,人们为此提交了很多版本。 我刚刚创建了虚拟应用程序的新版本,您可以在上面看到并提交它,以验证并查看会发生什么。

看到任何内容后,我会立即更新。

无论如何,感谢您的报告!

@joehanna我首先得到警告,在几分钟之内得到了第二张图片。 因此,不确定您的构建正在发生什么,但是它似乎与UIWebView使用无关

image

image

终于通过了。 对不起这部戏。 从来没有花那么长时间。 感谢您的跟进。

Screen Shot 2019-09-23 at 1 54 55 PM

SDK_错误

问题是因为编译器没有删除不需要的类文件或库。
Xamarin开发团队需要参考最新的苹果开发政策。

@jfversluis我们在Xamarin.iOS项目中遇到同样的问题。 当此线程位于Xamarin.Forms下时,根本原因是否相同? 该修复程序是否可以同时解决Xamarin.iOS和Xamarin.Forms?

谢谢!
CompaNova LLC

@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内的链接程序修复

那么,此版本的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

如果只用WkWebView替换UIWebView,就可以破坏人们的应用程序

@ Mikilll94尽管这一点是正确的,但简单的事实是Apple将开始拒绝仍使用UIWebView的二进制文件。 因此,即使Xamarin不采取任何措施,也将是一项重大突破,因为Apple(可能在接下来的9个月内)将不允许您在不进行任何更改的情况下更新应用。

@ cabal95
这是正确的。

但是我想表明WkWebView存在一个非常关键的问题,它将影响许多开发人员,现在没有解决方法。

同样的问题! 有完善的工作吗?

Screen Shot 2019-10-25 at 7 18 59 AM

@samirgcofficial感谢您报告您的发现。 您是否在顶部看到了我们一直在指的评论: https :

那应该可以解释当前的状态了:)

简介:目前没有解决方法或解决方案,我们正在研究中。 但是来自Apple的此消息仅是警告,您应该能够毫无问题地提交您的应用程序,仅此警告消息。

如有任何疑问,请告诉我!

@jfversluis @samirgcofficial
根据我的经验,Apple不再接受任何以二进制形式显示UIWebView的应用程序。 我们无法再将Xamarin应用发送到App Store。 因此,它不仅是警告消息,还是非常重要的问题。
另一方面,如果您对如何发布我们的应用有解决方案,请告诉我们如何?

@JawadJaber是的,这是一个严重的问题! 我无法在应用商店中对我的应用进行外部测试以进行试飞。 但是可以对应用程序进行内部测试,并且此WebView不会影响内部测试。
方案是生成外部链接和共享,而这在Test Flight中是无法完成的。 有什么办法吗?

@JawadJaber如果您收到来自Apple的另一条消息,说他们拒绝了您的二进制文件而不只是警告,请发布屏幕截图或提供更多详细信息。 我在星期五成功向Apple提交了二进制文件,除了警告电子邮件外没有其他问题。

我只提交了一个二进制文件,但只收到警告电子邮件

@JawadJaber @samirgcofficial您能告诉我为什么您认为您的二进制文件因为这个原因而被拒绝吗? 我们没有其他理由认为这仍然是警告。 自创建此问题以来,许多人都在确认这一点,并且电子邮件中的警告文本没有更改。

我们同意这是一个非常重要的问题,这就是为什么我们正在努力寻求解决方案,并且我们在这一点上尽可能清晰和透明。

在该线程的较早位置,还有另一个人认为他的二进制文件被拒绝了,但处理时间稍长一些。 难道您也是如此?

好的,我承认它现在可以与Apple一起正常使用。
尽管3周前它被拒绝了,但我联系了App Store支持团队,他们说了同样的话(他们的政策)。
但是现在它正在工作。 我认为苹果公司刚刚改变了这种情况的政策。 谢谢@jfversluis,@ martijn00 @ cabal95

好的,我收到了来自应用商店团队的另一条消息,我限制所有用户访问应用,并允许某些地区的用户使用TWILO进行OTP验证。 我应该排除所有限制,并且应用程序现在处于beta测试中:)。 就这样。 感谢大家。

同样的问题

很难向客户解释我们的应用绝对可以,这只是一个警告,等等((

我完全理解@YuliaLoyko。 不幸的是,我们正在尽可能快地行动。

等待4.4

@ prasannamca1107只是要清楚,不要使您的希望越来越大。 在4.4中不会解决此问题。 我们还依赖Xamarin.iOS的更改,这不能仅由Xamarin.Forms团队来解决。

从好的方面来说,我看到了一个可行的修复程序,就像我提到的那样:我们正在努力,但是要花一些时间才能将所有内容整理好,然后我们才能将其放到您的手中。

到目前为止,仍然没有什么可担心的,来自苹果的消息仍然只是警告!

我在xamarin论坛中关注了一个链接应该可以正常工作。

我没有尝试过同样的警告

@softsan ,谢谢分享! 不幸的是,这不是当前的解决方案。 目前,还没有(简单的)解决方案。 我强烈建议您唯一要做的是使用从解决方案中删除的UIWebViewRenderer构建自己的Xamarin.Forms包。

我们仍在努力寻找解决方案,不用担心! :)

我上周五提交了一个新的应用程序,我得到了同样的警告,但仅仅是:警告。
应用程序已被批准并在应用程序商店中列出,没有任何问题。

@jfversluis@softsan我为WebView编写了自己的渲染器,该渲染器返回WKWebView。 我已经测试了代码并将其发布到商店,仍然收到警告。 我的渲染器遵循渲染器的典型模式,但这是相关代码的简短片段:

如果(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 =新的WKWebView(cgRect,配置)
{
NavigationDelegate =新的WKNavigationDelegate()
};

                    SetNativeControl(_wKWebView);
                }

我的代码中只有一个地方使用Web浏览器,并且我已经调试了这段代码并检查了数据类型并验证了它的正确性,但是我收到了Apple的错误。 我已向审核小组提交了审核意见,并等待回复。

@seanstilson ,将

苹果可能会简单地告诉您有对UIWebView的引用。 不在您的代码中,而是通过Xamarin.Forms代码仍然在您的应用程序内。

这么说; 因此,在Apple真正停止接受二进制文件之前,我们将确保以一种或另一种方式进行修复。

抱歉,我错过了前面有关正在构建UIWebViewRenderer的帖子
进入二进制文件@jfversluis ,我不好。 感谢您的回复!

在2019年11月14日星期四上午11:54 Gerald Versluis [email protected]
写道:

@seanstilson https://github.com/seanstilson ,它将毫无用处。 如
即使您创建了一个自定义渲染器
使用WKWebView,UIWebViewRenderer仍将包含在
Xamarin.Forms二进制文件,因为它现在的工作方式。 我们正在努力
改变这一点,但是除非我们这样做,否则您无能为力
此时。

苹果可能会简单地告诉您有对UIWebView的引用。 不
在您的代码中,但通过Xamarin.Forms代码仍在您的应用程序内部。

这么说; 我们将确保在以前以一种或另一种方式修复它
因此,Apple真的停止接受二进制文件。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件,在GitHub上查看
https://github.com/xamarin/Xamarin.Forms/issues/7323?
或退订
https://github.com/notifications/unsubscribe-auth/AMVYZVUT5A73R4SXSQFRDMDQTWGF5ANCNFSM4ISLFU3Q

@seanstilson不用担心。 这里有很多动作,我可以想象你错过了一些事情:)

嗨,朋友们,在我们等待Xamarin.iOS团队的结果之前,我们将暂时锁定此问题。 这样,我们将能够正确地跟踪此问题,遇到此问题的人将能够直接找到最相关的信息,而不必在这里进行所有对话。 每当有新事物要报告时,我们一定会。

对于正在发生的事情的一个很好的总结,请在这里阅读此评论: https :

当前最新的进展可以在这里找到: https :

要点是:我们正在以一种向后兼容的方式来解决该问题,并且在苹果因此而开始真正拒绝应用之前,我们已经准备好一种或另一种方式。

目前,唯一的是您从Apple收到警告消息,此消息现在可以安全地忽略。

感谢您的理解和耐心!

此方面的小更新:#8001已合并为拟议修复的第一步。 但是,这并不意味着该问题将在即将发布的版本中消失。

如前所述,Xamarin.iOS中还需要进行一些更改才能使其正常工作。 每当他们这样做时,正确的Xamarin.iOS版本以及此代码(从4.5开始)将最终消失。

完全清楚:仅Xamarin.Forms 4.5版不会解决此问题。 只要有完整的解决方案,我就一定会再次进行更新。

谢谢!

苹果公司发布了一份简短声明,其中他们更加明确了弃用UIWebView 。 我认为最重要的是:

自2020年4月起,App Store将不再接受使用UIWebView的新应用程序,而自2020年12月起将不再接受使用UIWebView的应用程序更新。

这意味着无论解决方案如何,我们仍有时间提出解决方案。 同时,我们一直在研究我们的首选解决方案。 我们与Xamarin.iOS团队一起设法将一个应用程序提交到商店,该应用程序在保持向后兼容的同时不会触发警告。 这意味着不要删除(现在)旧版WebViewRenderer 。 我们仍在基于两种因素来决定这是否是解决方案,但我们仍在努力之中,并将确保我们已准备就绪。 至少现在我们知道什么时候可以准备了。谢谢您的耐心!

大家好消息! 有一个最终修复应供您使用。

它确实需要您一点点的工作,我目前正在编写一些文档来描述它是什么。 不用担心,它并不那么复杂!

只要有直播,并且所有内容都对您可用,我将在此处发布。 没有明确的承诺,但应该在四月的截止日期之前不久。

再次感谢您在此方面坚持不懈!

解决方案在这里!

所有位都准备就绪,解决时间到了! TL; DR:一切都在这片文档的描述在这里

确保在稳定的频道上使用最新的Visual Studio(适用于Mac),这将使您走上正确的道路。 目前,您将需要使用Xamarin.Forms 4.5-pre1预览版。 我知道这可能不是所有人的选择,但是请放心,稳定的软件包将在截止日期之前到期。 计划在2月中旬至下旬稳定4.5。

最后,将--optimize=experimental-xforms-product-type标志放入您的iOS其他mtouch参数设置中,您应该摆脱Apple的弃用警告。 如果您自己没有引用UIWebView当然🙂

我想请您尽早尝试一下。 也许不是基于Forms预览包向商店发布实际的新版本,而是至少上载一个版本以验证此解决方案是否正常工作。 无论何时,您都可以更新到4.5稳定软件包并放心发布新版本。

如果您确实遇到任何使用此解决方案的问题,请随时直接与我联系(gerald.versluis [一个长尾巴的人] microsoft.com)或在存储库中打开一个新问题。 当然,积极的反馈总是值得赞赏的😉

再次感谢你!

此页面是否有帮助?
0 / 5 - 0 等级