أواجه هذه المشكلة أيضًا ، فنحن نستخدم: Xamarin.Forms 3.6.0.539721

سيحصل كل إصدار من النماذج على هذا لأن 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 منذ شهرين. أفترض أنه يمكنك إنشاء WebView الخاص بك الذي يرث من هذا العارض (إذا لم يكن لديك أحدث إصدار من XF في مشروعك ، يمكنك نسخ / لصق الرمز) لإصلاح هذه المشكلة مع WebViews الخاصة بك

WkWebViewRenderer.cs

يا رفاق ، وجدت شيئًا غريبًا ، لقد غيرت معرف حزمة التطبيق وأرسلته إلى متجر التطبيقات مرة أخرى ، ولم أتلق رسالة التحذير الإلكترونية من Apple.
ووضعي: منذ ثلاثة أيام ، لم أتلق أي بريد إلكتروني تحذيري من Apple بعد إرسال ipa إلى testflight ، ثم تلقيت البريد الإلكتروني بعد إجراء بعض التغييرات التي لا علاقة لها بعرض الويب ، ثم أحاول العثور على لماذا بالطرق التالية:
1.حاول استبدال UIWebViewRenderer بـ WKWebViewRenderer ؛
2-إزالة WebView ؛
3 قم بإزالة nuget lib الخاص بالطرف الثالث (أضفته مؤخرًا) ؛
لكنهم غير مجديين بشأن التحذير (ما زلت أتلقى بريدًا إلكترونيًا للتحذير).
لا أعرف كيف تم فحص ipa بواسطة Apple ، هل هناك أي احتمال لارتكاب بعض الأخطاء؟

لقد لاحظت أن هذا الموقف يظهر برفرفة وتفاعل أصلي مؤخرًا (يواجه المطورون المشكلات أيضًا.)

@ Carl-Wen يحدث هذا مع تطبيقات Ionic أيضًا

تلقيت نفس الرسالة من Apple Store Connect اليوم. الشيء الغريب هو أن تطبيقي لا يحتوي على أي عرض ويب فيه. لقد حاولت أيضًا البحث في مكونات Xamarin الإضافية لمعرفة ما إذا كان أي منها يستخدم ، ولكن يبدو أن أيا منها لا يستخدم UIWebView (ليس متأكدًا بنسبة 100٪ لأن هناك أيضًا تبعيات).
هل يعرف أي شخص كيفية تحديد استخدام UIWebView في التطبيق؟

نفس الشيء يحدث لي. المرة الأولى التي تحاول فيها إرسال تطبيق

تلقيت نفس التحذير من iTunesConnect اليوم

لقد تلقيت أيضًا نفس الخطأ منذ بضعة أيام ، فهل هناك أي حل بديل؟

يرجى التحقق من إجابتي هنا ، لدي مشروع على Xamarin.Forms 3.6.x ويستخدم بعض عروض الويب ، لذلك قمت بإنشاء عارض مخصص لـ WebView لنظام iOS فقط وغيرت الوراثة من UIWebViewRenderer إلى WKWebViewRenderer . بالأمس قمت بتحميل التطبيق إلى المتجر ولم أتلق أي تحذير.

نفس المشكلة

FabriBertani هل يمكنك مشاركة رمز العرض المخصص الخاص بك من فضلك؟

لدي نفس المشكلة ، لكن تطبيقي لا يستخدم أي طرق عرض ويب. أفترض أن Apple تكتشف الاستخدام في مكتبة Xamarin.iOS.

هل لديك أي حلول أو حلول لهذا الحل؟ حدث أيضًا عندما قمنا بتحميل تطبيقنا. كما أننا لا نستخدم WebViews ويبدو أن 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 واحد. مع ذلك ، يجب أن يختفي هذا الخطأ.

أتوقع بعض المراجعات والتعليقات على العلاقات العامة الخاصة بي من بقية الفريق ، ولكن آمل أن يتم حل هذا قريبًا.

مرحبًا jfversluis ، هل من الممكن تطبيق الإصلاح على الإصدار الأقدم من XamarinForms؟
أنا أستخدم 3.4.0.1009999 وسيكون هناك الكثير من الجهد للترقية إلى أحدث إصدار من Xamarin.Forms.

ngoquoc قد أشك في أننا

jfversluis شكرا على الرد السريع: د
أوافق تمامًا على أنه يستحق الترقية إلى الإصدار الأحدث ، ولكن الوضع قريب جدًا من الموعد النهائي للإصدار المخطط له. ولدينا العديد من التبعيات القديمة (التي تدعم فقط ما يصل إلى XF 3.x) بالإضافة إلى استخدامات التغييرات التكسيرية للإصدار الأحدث.

ngoquoc لا مشكلة! أنا أفهم تماما! بالنسبة لإصدارك القادم ، أعتقد أنه من الحكمة البحث عن الترقية بالرغم من ذلك. قد يكون هناك المزيد من واجهات برمجة التطبيقات التي سيتم إيقافها أو إيقافها قريبًا. إذا كان هناك أي شيء يمكننا القيام به لتحسين تجربة الترقية ، فيرجى التواصل معنا!

نأمل أن نتمكن من تطبيق إصلاح هذه المشكلة على 3.4. الترقية إلى 4.x مضمنة تمامًا في خطتنا وسنتواصل مع الفريق إذا احتجنا إلى مساعدة (ونأمل ألا: د). حقا نقدر دعمكم!

ngoquoc على أي حال ، كما هو مكتوب أعلاه ، بينما يمكنك تحميل ipa الخاص بك ، وفي iOS13 لا يزال هذا الفصل موجودًا.
لذلك ، سوف يعمل هذا لبعض الوقت

KSemenenko هل تقصد يمكن أيضا نشر التطبيق "حذر" على متجر أبل؟
إذا كان الأمر كذلك ، رائع ، يمكننا تهدئة وتأجيل التبديل إلى 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

تضمين التغريدة

لم ينجح معي ، لدي كل من العارض والمدخل في ملف التجميع وما زلت أتلقى التحذير.

هل قصدت أن مجرد إضافة WKWebViewRenderer لا تكفي لهذا البريد الإلكتروني التحذيري؟

تضمين التغريدة

لم ينجح معي ، لدي كل من العارض والمدخل في ملف التجميع وما زلت أتلقى التحذير.

في هذه الحالة ، ربما يكون لديك أي حزمة أخرى تستخدم UIWebView ، فأنا فقط أستخدم هذا الحل ولا أتلقى أي تحذير من متجر التطبيقات :)

مرحبًا ngoquoc ، أي حظ في عملية المراجعة حتى الآن؟

أود فقط معرفة ما إذا كان الموعد النهائي لتطبيقنا سيتم الوفاء به في حالة تقديمه للمراجعة بغض النظر عن "التحذير".

أعتقد أننا بحاجة إلى معرفة متى ستبدأ Apple في اعتبار هذا سببًا لرفض ملف IPA. أخشى ألا يعلنوا ذلك علنًا.

تلقيت اليوم رسالة تفيد بأن تطبيقي قد اجتاز مراجعة Apple
حتى الآن يعمل :)

مراجعة التطبيق تعمل كالمعتاد. تم نشر تطبيقي الجديد بشكل طبيعي. ربما مجرد تحذير للإفراج في المستقبل.

عادة ما تكون التحذيرات مجرد تحذيرات وتمنحك الكثير من الوقت. في حالة Google ، يمنحونك حوالي عامين. افترض هنا أن التحذير هو إخبارك بأنهم سيقومون بإزالته من iOS 14 (تخميني) وأنهم يريدون حقًا التوقف عن استخدامه. على الرغم من أنك إذا قلبت المفتاح أو إذا كان قيد التشغيل افتراضيًا ، فلن تستخدمه على أي حال. لذلك ما لم يقلبوا المفتاح ويرتكبوا خطأ ، وهو ما لا أعتقد أنه سيفعلونه لأن بعض الأشخاص ما زالوا بحاجة إلى دعم الأجهزة القديمة.

حسنًا ، هذا ما فعلته للتحقق مما يجري.

أنشأت تطبيقًا وهميًا قمت بتحميله على Apple باستخدام حزمة Xamarin.Forms الأحدث والتطبيق يعرض WebView فقط. بعد فترة وجيزة من تحميله ، تلقيت هذا التحذير. للتحقق من أن التحذير ينطلق في كل مرة ، وبالتالي للتحقق ، يمكننا أن نفترض أنه عندما لا يأتي التحذير ، قمنا بإصلاح المشكلة ، لقد قمت بإنشاء ثنائي آخر بدون أي تغييرات إلى جانب رقم الإصدار. جاءت رسالة التحذير مرة أخرى. وهذا يؤكد: عندما تتوقف عن تلقي التحذير ، يبدو أن المشكلة قد تم حلها.

ثم تقدمت ونفذت عارضًا مخصصًا بالشفرة الدقيقة التي قدمها هنا . الرسالة لا تزال تصل. لذلك لا يبدو أن هذا هو الحل.

ثم أخذت هذا الفرع وحذفت للتو WebRenderer وأزلت بشكل فعال جميع الإشارات إلى UIWebView. كان لهذا التأثير المطلوب. لم تعد Apple ترسل لي الآن التحذير.

يبدو أن كل هذا يشير إلى حقيقة أنه طالما نشير إلى UIWebView في الكود الخاص بنا (اقرأ: طالما أن UIWebViewRenderer لا يزال في مكانه) فإن Apple ستكتشفه وستتوقف في النهاية عن قبول التطبيق. للحصول على أقصى قدر من التوافق مع الإصدارات السابقة ، نحتاج إلى التحقيق في سبب عدم قيام الرابط بإزالة WebViewRenderer عندما لا يتم استخدامه بعد الآن. إذا قمنا بإصلاح ذلك ، فإن العلاقات العامة الخاصة بي منطقية ويجب أن تحل هذه المشكلة إلى الأبد.

كما ذكر جيمس (وآخرون) ، إنه مجرد تحذير في الوقت الحالي ، لذلك حتى لو تلقيت الرسالة ، فلا داعي للقلق في هذه المرحلة وستنجح. لكن بالطبع نحن بحاجة إلى الاستعداد عندما تقرر Apple التوقف عن السماح بواجهة برمجة تطبيقات UIWebView القديمة.

لذلك بعد التحقق من فريق iOS ، يبدو أن أي شيء يرث من NSObject لن يتم ربطه أبدًا ، لذا فإن وعد RenderWith بربط العارضين ، أنا متأكد تمامًا من عدم العمل على iOS

بالنظر إلى أننا سنضطر فقط إلى حذف العارض تمامًا وكسر الجميع

أو احصل على ماكرة باستخدام nuget منفصل وبعض أنواع إعادة التوجيه

لدي نفس المشكلة أي تحديث على هذا؟

مرحبًا @ Mikilll94 ، نحن نعمل بنشاط على هذا ، ولكن لن يتوفر حل كامل في أي وقت قريبًا. مع "الحل الكامل" أعني أن التحذير سيتوقف من Apple عندما ترسل تطبيق Xamarin.Forms إلى المتجر.

لإيقاف رسالة التحذير نحتاج إلى إزالة WebViewRenderer من المصدر تمامًا. نظرًا لأن هذا العارض هو الافتراضي في الوقت الحالي وكان موجودًا في المصدر منذ ذلك الحين إلى الأبد ، فهذا تغيير كبير. مع العلاقات العامة المرتبطة بهذه المشكلة ، نقوم بتحويل العارض الافتراضي إلى WKWebViewRenderer والذي سيستخدم بشكل فعال WKWebView . يجب ألا يلاحظ المستخدمون النهائيون لـ Xamarin.Forms أي شيء بخصوص هذا التغيير. باستخدام هذا التبديل ، نقوم أيضًا بوضع علامة على WebViewRenderer الأصلي على أنه مهمل لمنح Xamarin.Forms للمستخدمين إمكانية إجراء التغييرات اللازمة في التعليمات البرمجية الخاصة بهم. على سبيل المثال ، إذا كان لديهم عارضين مخصصين يعتمدون على WebViewRenderer .

ومع ذلك ، نظرًا لأن WebViewRenderer لا يزال مرتبطًا بالمصدر ، فلا يزال هذا شيئًا تلتقطه Apple أثناء فحص تطبيقك. في إصدار لاحق من Xamarin.Forms ، والذي هو في أقدم إصدار 4.5 ، سنقوم بإسقاط WebViewRenderer بالكامل ومع ذلك يجب أن تتوقف رسائل التحذير من Apple.

بعد قولي هذا ، هناك شيئان يجب إزالتهما:

1. الرسالة من Apple هي مجرد تحذير في الوقت الحالي ، فلا يوجد ما يمنعك من إرسال إصدارات جديدة ويجب قبولها في متجر التطبيقات على ما يرام. من المحتمل أن يستمر هذا الأمر حتى نظام iOS 14 الذي يمنحنا (على الأقل) سنة.
2. مرة أخرى ، يعد إسقاط WebViewRenderer من المصدر تغييرًا فاصلًا رئيسيًا لا نفضل القيام به ، لكن ليس لدينا خيار في هذه المرحلة. لذلك نحتاج إلى قضاء بعض الوقت في تحذير المستخدمين من هذا الأمر والتبديل التدريجي إلى التطبيق الجديد أولاً ثم إزالة هذه الفئة من المصدر فقط. هذه عملية طويلة ولكن يجب أن تحدث قبل إصدار iOS 14 بفترة طويلة.

آمل أن يعالج هذا كل مخاوفك بشأن هذا ، إذا لم يكن كذلك ، فيرجى إبلاغي بذلك. يسعدني الرد على أي أسئلة قد تكون لديكم حول هذا الموضوع.

شكرا لتفهمك وصبرك!

تضمين التغريدة
شكرا على هذه الإجابة الرائعة :)

jfversluis شكرا لإجابتك
من فضلك ، هل يمكن أن تخبرني بكيفية إسقاط WebViewRenderer من المصدر؟

NehalOsama الطريقة الوحيدة للقيام بذلك هي استنساخ مستودع XamForms هذا ، وحذف ملف WebViewRenderer.cs من مشروع Platforms.iOS ، وتغيير جميع المراجع للإشارة إلى WKWebViewRenderer وإنشاء ملفات DLL الخاصة بك و استخدم ذلك في تطبيقك.

سأكون في غاية يوصي ضد هذا . القيام بذلك يعني أنه لا يمكنك الترقية إلى الإصدارات التي سنصدرها ، لذلك لن تتلقى أبدًا أي إصلاحات للأخطاء أو أي شيء دون فقدان التغيير المخصص. أو قد تحتاج إلى تكرار هذه العملية مرة أخرى في كل مرة تريد فيها الترقية.

إذا كنت لا اعتبارها لي طلب؛ لماذا لا تنتظر الرسالة من Apple هي مجرد تحذير وسنقوم بذلك جيدًا قبل أن تبدأ Apple فعليًا في رفض التطبيقات. لا يوجد ما يدعو للقلق في هذه المرحلة.

تضمين التغريدة
شكرًا جزيلاً ، بغض النظر عن إزالة المراجع والتحذير ، فإن السبب هو أن عميلنا يصر على التكامل مع تطبيق آخر باستخدام 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 بمعالجة الملف الثنائي بالكامل بعد إرسال رسالة كهذه.

أرى أن تعليقك منذ حوالي ساعة ، يجب أن يظهر في بوابة Developer الآن. هل ستكون قادرًا على التحقق من أنه لم يمر بالفعل؟

أيضا

لم تتم معالجة ملفي الثنائي وإتاحته للإصدار.

كيف تحققت من هذا؟ إذا انتقلت إلى تعريف التطبيق ، ثم "النشاط" ، ضمن "جميع الإصدارات" ، ألا ترى ذلك؟

شكرا لردكم السريعjfversluis. لم أتلق رسالة التأكيد بالبريد الإلكتروني ولا تظهر في الإصدارات المتاحة. أعتقد أنه يمكن أن يكون هناك تراكم معالجة؟ من واقع خبرتي ، تتم معالجة الملف الثنائي في أقل من 20 دقيقة. سوف أتحقق من ذلك مرة أخرى بعد قليل وأعد تقريراً.

آه ، هذه نقطة جيدة تتطرق إليها هناك. قد يكون هناك بعض النشاط الإضافي مع ظهور iOS 13 وإرسال الأشخاص الكثير من الإصدارات لذلك. لقد قمت للتو بإنشاء إصدار جديد من التطبيق الوهمي الذي يمكنك رؤيته أعلاه وإرساله أيضًا ، فقط للتحقق ومعرفة ما سيحدث.

سأقوم بتحديثك بمجرد أن أرى أي شيء.

شكرا للتقرير على أي حال!

@ joehanna تلقيت التحذير أولاً وفي غضون دقائق حصلت على الصورة الثانية. لذلك ، لست متأكدًا مما يحدث مع جهازك ، ولكن لا يبدو أنه مرتبط باستخدام UIWebView

لقد جاء أخيرًا. آسف على الدراما. لم يستغرق الأمر وقتا طويلا من قبل. شكرا لمتابعته.

SDK_Bug

تكمن المشكلة في عدم قيام المترجم بإزالة ملفات الفئات أو المكتبات غير المرغوب فيها.
تحتاج فرق تطوير Xamarin إلى الرجوع إلى أحدث سياسات تطوير التفاح.

jfversluis نواجه نفس المشكلة مع مشاريع Xamarin.iOS. أثناء وجود هذا الخيط تحت Xamarin.Forms ، هل السبب الجذري هو نفسه؟ هل سيتناول الإصلاح كلا من Xamarin.iOS و Xamarin. Forms؟

شكرا جزيلا!
شركة CompaNova LLC

dmitrymal هناك عدة أسباب

سيحل Xamarin.iOS قضيتهم ومن ثم سنبني على ذلك لحل مشكلتنا

لدينا بعض الحلول قيد العمل وسنقوم بتحديث هذه المشكلة بينما نحرز تقدمًا

كيف يحدث هذا الموضوع لا يزال موسوم s / لم يتم التحقق منه؟

لا انها ليست taublast 🤡

على الرغم من أنني أقدر أن هذا الإصلاح متوقف لفترة وجيزة وليس عاجلاً حاليًا ، فهل سيتم نقله إلى إصدارات XF السابقة عند الانتهاء؟ لدينا مجموعة كبيرة من التطبيقات المضمنة في الإصدار 3.4 وبسبب العديد من مشكلات التبعية ، فقد فشلت دائمًا عند محاولة الترقية إلى XF 4.0 أو أعلى.

@ 1888games أعتقد أن هذا غير محتمل إلى حد كبير ، وهذا يتوقف أيضًا على الإصلاح النهائي النهائي.

https://github.com/xamarin/Xamarin.Forms/pull/7367 تم دمجها لكنها مجرد جزء من اللغز لذا لا تتوقع اختفاء التحذير

لا يزال يتطلب إصلاحات رابط داخل Xamarin. نماذج 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 (الأساسية) التي لم يتم استخدامها. بالإضافة إلى ذلك ، تم دمج العلاقات العامة الخاصة بي مما سيجعل WKWebViewRenderer الخيار الافتراضي.

مع تطبيق ذلك ، فإن الخطوة الأخيرة بشكل أساسي هي إطلاق حل "ربط iOS". عندما يحدث ذلك ، يكون WKWebViewRenderer هو الوضع الافتراضي ، ويجب أن يؤدي عدم استخدام WebViewRenderer في شفرتك بعد الآن إلى إسقاطه من الملف الثنائي الناتج الذي يتم إرساله إلى Apple. ما قيل؛ إن إطلاق حل ربط iOS أسهل قولًا من فعله وسيستغرق بعض الوقت.

الجانب الإيجابي هنا هو أننا ربما لن نضطر إلى المضي في حل التغيير الكامل ، ولكن يمكننا نقل الجميع تدريجيًا إلى هذا الحل.

آمل أن يجيب هذا على جميع أسئلتك في هذا الوقت. إن لم يكن، واسمحوا لي أن أعرف!

عند إهمال UIWebView واستبداله بـ WkWebView ، يجب أن تفكر في هذه المشكلة
https://github.com/xamarin/Xamarin.Forms/issues/8028

يمكنك كسر تطبيقات الأشخاص إذا قمت فقط باستبدال UIWebView بـ WkWebView

@ Mikilll94 بينما النقطة صحيحة ، فإن الحقيقة البسيطة هي أن Apple ستبدأ في رفض الثنائيات التي لا تزال تستخدم UIWebView. لذا ، حتى لو لم يفعل Xamarin شيئًا ، فسيكون تغييرًا كبيرًا على أي حال لأن Apple (ربما في الأشهر التسعة المقبلة) لن تسمح لك بتحديث تطبيقك دون إجراء هذا التغيير على أي حال.

تضمين التغريدة
صحيح.

لكنني أردت أن أوضح أن هناك مشكلة في WkWebView وهي مشكلة بالغة الأهمية وستؤثر على العديد من المطورين ولا يوجد حل بديل لها في الوقت الحالي.

المشكلة نفسها ! أي عمل مثالي حولها؟

مرحبًا شكرًا samirgcofficial للإبلاغ عن https://github.com/xamarin/Xamarin.Forms/issues/7323#issuecomment -542363338؟

يجب أن يفسر ذلك الوضع الحالي إلى حد كبير :)

ملخص: لا يوجد حل أو حل في الوقت الحالي ، نحن نعمل على حله. لكن هذه الرسالة من Apple هي مجرد تحذير ويجب أن تكون قادرًا على إرسال تطبيقاتك دون أي مشاكل ، فقط رسالة التحذير هذه.

إذا كانت هناك أي أسئلة ، فيرجى إبلاغي بها!

تضمين التغريدة #jfversluissamirgcofficial
وفقًا لتجربتي ، لم تعد Apple تقبل أي تطبيق يعرض UIWebView في ملفه الثنائي. يتعذر علينا إرسال تطبيقات Xamarin الخاصة بنا إلى متجر التطبيقات بعد الآن. وبالتالي ، فهي ليست مجرد رسالة تحذير ، إنها قضية مهمة للغاية.
من ناحية أخرى ، إذا كان لديك حل حول كيفية نشر تطبيقاتنا ، فالرجاء إخبارنا كيف؟

JawadJaber نعم ، إنها مشكلة خطيرة! لا يمكنني إجراء اختبار خارجي لتطبيقي في متجر التطبيقات لرحلة تجريبية. لكن الاختبار الداخلي للتطبيق ممكن ولا يؤثر WebView هذا أبدًا على الاختبار الداخلي.
كان السيناريو هو إنشاء ارتباط خارجي ومشاركته والتي لا يمكن القيام بها في Test Flight. اي حل ؟

JawadJaber إذا تلقيت رسالة مختلفة من Apple تقول إنهم رفضوا النظام الثنائي الخاص بك بدلاً من مجرد تحذير ، فيرجى نشر لقطة شاشة أو أي شيء لإعطاء مزيد من التفاصيل. لقد نجحت في إرسال ثنائي إلى Apple يوم الجمعة دون أي مشكلة سوى البريد الإلكتروني التحذيري.

لقد قمت فقط بإرسال برنامج ثنائي وتلقيت رسالة بريد إلكتروني تحذيرية فقط

JawadJabersamirgcofficial هل يمكن أن تخبرني من فضلك لماذا تعتقد أن نظامك الثنائي مرفوض بسبب هذا السبب؟ ليس لدينا سبب للاعتقاد بأن أي شيء آخر غير هذا لا يزال تحذيرًا. يؤكد الكثير من الأشخاص هذا ولم يتغير نص التحذير في رسالة البريد الإلكتروني منذ إنشاء هذه المشكلة.

نحن نتفق على أن هذه مسألة مهمة للغاية ، وهذا هو السبب في أننا نعمل بجد للتوصل إلى حل ونحن واضحون وشفافون بقدر ما يمكن أن نكون في هذه المرحلة.

في وقت سابق من هذا الموضوع ، كان هناك شخص آخر يعتقد أن نظامه الثنائي قد تم رفضه ولكن المعالجة استغرقت وقتًا أطول قليلاً. هل يمكن أن يكون هذا هو الحال بالنسبة لك أيضًا؟

حسنًا ، أعترف أنه يعمل بشكل صحيح الآن مع Apple.
على الرغم من أنه تم رفضه قبل 3 أسابيع ، واتصلت بفريق دعم App Store وقالوا نفس الشيء (سياستهم).
لكنها تعمل الآن. أعتقد أن شركة Apple قد غيرت سياساتها لهذه الحالة. شكرا لك jfversluis ، @ martijn00 @ cabal95

حسنًا ، تلقيت رسالة أخرى من فريق متجر التطبيقات مفادها أنني كنت أقيد وصول جميع المستخدمين إلى التطبيق والسماح لأشخاص معينين في المنطقة بالتحقق من OTP باستخدام TWILO. يجب أن أستبعد القيود ، هذا كل شيء والتطبيق قيد الاختبار التجريبي الآن :). هذا كل شئ. شكرا لكم جميعا.

نفس القضايا

من الصعب جدًا توضيح للعملاء أن تطبيقنا على ما يرام تمامًا ، إنه مجرد تحذير ، إلخ (

أنا أفهم تمامًاYuliaLoyko. للأسف نحن نتحرك بأسرع ما يمكن.

في انتظار 4.4

@ prasannamca1107 فقط

على الجانب المشرق ، لقد رأيت إصلاحًا عمليًا ، كما ذكرت: نحن نعمل على ذلك ، لكن الأمر سيستغرق بعض الوقت قبل أن يصطف كل شيء ويمكننا وضعه بين يديك.

حتى الآن ، لا يوجد ما يدعو للقلق ، لا تزال رسالة Apple مجرد تحذير!

كنت أتابع موضوعًا في هذا الرابط الذي يجب أن يعمل على ما أعتقد.

لم أحاول نفس التحذير

softsan ، شكرا للمشاركة! لسوء الحظ ، هذا ليس حلاً حاليًا. في هذا الوقت ، لا يوجد حل (سهل). الشيء الوحيد الذي يمكنك القيام به ، والذي أوصي به بشدة ، هو بناء حزم Xamarin الخاصة بك مع حذف UIWebViewRenderer من الحل.

ما زلنا نعمل بجد لإيجاد حل ، لا تقلق! :)

لقد قدمت تطبيقًا جديدًا يوم الجمعة الماضي ، وتلقيت نفس التحذير ولكن كان مجرد تحذير.
تمت الموافقة على التطبيق وإدراجه في متاجر التطبيقات دون أي مشكلة.

jfversluis ، softsan لقد كتبت برنامج العارض الخاص بي لـ WebView ، والذي يقوم بإرجاع WKWebView. لقد اختبرت الكود ونشرته في المتجر وما زلت أتلقى التحذير. يتبع العارض الخاص بي النمط النموذجي للعارض ولكن فيما يلي مقتطف مختصر من الشفرة ذات الصلة:

إذا (التحكم == فارغة)
{
_contentController = جديد WKUserContentController () ،
var frame = UIApplication.SharedApplication.Delegate.GetWindow (). Bounds ؛
var cgRect = 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. لا تزال أشكال التعليمات البرمجية داخل تطبيقك.

بعد أن قال هذا ؛ سوف نتأكد من إصلاحه بطريقة أو بأخرى قبل أن تتوقف Apple حقًا عن قبول الثنائيات بسبب هذا.

آسف فاتني المنشور في وقت سابق حول UIWebViewRenderer قيد الإنشاء
في الثنائيات jfversluis ، يا سيئ. شكرا للإستجابة!

يوم الخميس 14 نوفمبر 2019 الساعة 11:54 صباحًا Gerald Versluis [email protected]
كتب:

seanstilson https://github.com/seanstilson لن يكون ذا فائدة. مثل
المشار إليه سابقًا في هذه المشكلة ، حتى إذا قمت بإنشاء عارض مخصص
يستخدم WKWebView وسيظل UIWebViewRenderer مدرجًا في ملف
Xamarin.Forms الثنائيات بسبب كيفية عمله الآن. ونحن نعمل على
تغيير ذلك ، ولكن حتى نقوم بذلك ، لا يوجد شيء يمكنك القيام به لتغيير هذا
في هذا الوقت.

من المحتمل أن تخبرك Apple ببساطة أن هناك إشارة إلى UIWebView. ليس
في التعليمات البرمجية الخاصة بك ، ولكن من خلال Xamarin. لا تزال أشكال التعليمات البرمجية داخل التطبيق الخاص بك.

بعد أن قال هذا ؛ سوف نتأكد من إصلاحه بطريقة أو بأخرى من قبل
توقف Apple حقًا عن قبول الثنائيات بسبب هذا.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/xamarin/Xamarin.Forms/issues/7323؟email_source=notifications&email_token=AMVYZVVKIGZKMMH5XOS2QATQTWGF5A5CNFSM4ISLFU32YY3PNVWWK3TUL52HS4DFVREXG43VM33TUL52HS4DFVREXG43V
أو إلغاء الاشتراك
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) ، سيختفي هذا أخيرًا.

لنكون واضحين تمامًا: الإصدار 4.5 من Xamarin. لن تعمل النماذج وحدها على حل هذه المشكلة. عندما يكون الإصلاح الكامل في الأفق ، سأكون متأكدًا من تحديث هذا مرة أخرى.

شكر!

أصدرت شركة Apple بيانًا قصيرًا يقدمون فيه مزيدًا من الوضوح حول خططهم لإيقاف UIWebView . أعتقد أن أهم قطعة هي:

لن يقبل App Store بعد الآن التطبيقات الجديدة التي تستخدم UIWebView اعتبارًا من أبريل 2020 وتحديثات التطبيقات باستخدام UIWebView اعتبارًا من ديسمبر 2020.

هذا يعني أنه لا يزال لدينا بعض الوقت للتوصل إلى حل ، مهما كان. في غضون ذلك ، كنا نبحث في الحل المفضل لدينا. تمكنا مع فريق Xamarin.iOS من إرسال تطبيق إلى المتجر لا يؤدي إلى تشغيل التحذير بينما يظل متوافقًا مع الإصدارات السابقة. هذا يعني عدم إسقاط (الآن) WebViewRenderer القديم. ما زلنا نقرر ما إذا كان هذا هو الحل بناءً على عاملين ، لكننا ما زلنا نعمل عليه وسنتأكد من استعدادنا. على الأقل الآن نعرف متى نكون مستعدين - نشكرك على سعة صدرك!

أخبار سارة للجميع! هناك حل نهائي يجب أن يكون متاحًا لك لاستخدامه قريبًا.

يحتاج الأمر إلى القليل من العمل من جانبك ، فأنا أعمل حاليًا على القليل من التوثيق الذي يصف ذلك. لا تقلق ، الأمر ليس بهذا التعقيد!

كلما كان ذلك مباشرًا وكانت جميع الأجزاء متاحة لك أيضًا ، سأقوم بنشرها هنا. لا توجد وعود قوية ، ولكن يجب أن تكون في القريب العاجل قبل الموعد النهائي في أبريل.

مرة أخرى ، شكرًا لك على استمرارنا في هذا الأمر!

الحل هنا!

كل القطع في مكانها ، وقت الحل! TL ؛ DR: تم وصف كل شيء في هذا الجزء من التوثيق هنا .

تأكد من أنك تستخدم أحدث إصدار من Visual Studio (لنظام التشغيل Mac) على القناة الثابتة ، والتي يجب أن تضعك على المسار الصحيح. في الوقت الحالي ، ستحتاج إلى استخدام إصدار معاينة Xamarin.Forms 4.5-pre1. أتفهم أن هذا قد لا يكون خيارًا متاحًا لكم جميعًا ، لكن اطمئنوا ، سيتم طرح الحزمة الثابتة قبل الموعد النهائي بوقت طويل. تم التخطيط للإسطبل 4.5 من منتصف إلى نهاية فبراير.

أخيرًا ، ضع علامة --optimize=experimental-xforms-product-type في إعداد وسيطات mtouch الإضافية لنظام التشغيل iOS الخاص بك ويجب أن تتخلص من تحذير الإيقاف من Apple. إذا لم يكن لديك أي مراجع خاصة بك إلى UIWebView بالطبع 🙂

أود أن أطلب منك تجربة هذا في أقرب وقت يناسبك. ربما لا يتم إصدار إصدار جديد فعلي إلى المتجر بناءً على حزمة معاينة النماذج ، ولكن على الأقل تحميل تصميم للتحقق من أن هذا الحل يعمل بشكل صحيح. متى فعلت ذلك ، يمكنك فقط التحديث إلى الحزمة الثابتة 4.5 وإصدار إصدار جديد بكل ثقة.

إذا واجهت أي شيء مع هذا الحل ، فلا تتردد في التواصل معي مباشرة (gerald.versluis [a with a long tail] microsoft.com) أو فتح مشكلة جديدة في المستودع. بالطبع يتم تقدير التعليقات الإيجابية دائمًا أيضًا 😉

شكرا مرة اخرى!