Xamarin-macios: ITMS-90809: Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs .

[Cloudtrackers]

When i am submitting iOS build for review getting this error. i am not using UIWebView anywhere in my xamarin forms project.

[Cloudtrackers]

It seems like compiler is not removing unwanted class files or libraries.

[spouliot]

Note that this is a warning (not an error)
XF specific parts are tracked in https://github.com/xamarin/Xamarin.Forms/issues/7323

[aspnetde]

I've just seen this for the first time myself:

Dear Developer,

We identified one or more issues with a recent delivery for your app, "XXX" Version (Build). 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 starting from December 2020 . See https://developer.apple.com/documentation/uikit/uiwebview for more information.

After you’ve corrected the issues, you can upload a new binary to App Store Connect.

Best regards,

The App Store Team

• The IPA was built against Xamarin.iOS 13.10.0.21
• It does not use Xamarin.Forms
• There is not a single occurrence of UIWebView in the codebase.

Right now I am calm. But given that this issue is half a year old, I would like to know if it is a known (and soon to be addressed!) Xamarin.iOS issue, or if I have to dig into libraries we are using.

(Though we did not change anything here in the last months regarding the referenced libs. And we have deployed to the AppStore 1-2x per month for the last half year or so – never seen that message before.)

[spouliot]

@aspnetde Apple checks have been a bit inconsistent (and they do not document how it's done). E.g. there has been cases where references to UIWebView exists yet it has not been reported (as a submission warning). Your warning might be a _fix_ and not related to recent code changes inside your application.

Our next releases will have more diagnostic options, to make it easier to track where references of UIWebView are coming from. We're also testing a _nuclear_ option to remove _most_ trace of it.

They are not the one in the stable/preview channels but the packages can be downloaded from GitHub if you wish to try them.

or if I have to dig into libraries we are using.

You should. It can be a single grep in both input/output binaries - in particular the one given to the build (after they mostly get merged into a single blob so it's not as helpful the origin).

If it comes from a 3rd party native library then you might require an update to such library(ies) or, if lucky, some native linker argument tweaks might be possible (e.g. in case you are forcing everything into the application).

Also double-check that the managed linker is enabled (e.g. Link SDK Framework) to ensure unused types are being removed from your application.

[aspnetde]

Thx for the feedback!

They are not the one in the stable/preview channels but the packages can be downloaded from GitHub if you wish to try them.

As there is still time till December, I will take a wait and see approach. At least until autumn.

Also double-check that the managed linker is enabled (e.g. Link SDK Framework) to ensure unused types are being removed from your application.

Will do. Again, thanks for the feedback.

[tipa]

I am hitting the same issue and I am not using UIWebView anywhere in my app. I also have "Link All" active in the linker settings. Will see if I can find anything using grep. Also very curious to hear about the findings of @aspnetde

[spouliot]

@tipa @aspnetde please share your findings whenever you see 3rd code that brings the UIWebView type into applications.

@tipa if you are using Xamarin.Forms please look at https://github.com/xamarin/xamarin-macios/issues/7059#issuecomment-534132790 and https://devblogs.microsoft.com/xamarin/uiwebview-deprecation-xamarin-forms/

[tipa]

I am not using Xamarin.Forms.
Could you perhaps give a small hint on how to use grep to find references to UIWebView? I have not much experience with that command

[thongdoan]

@tipa, you can use otool to find references:

1. Rename the AppName.ipa to AppName.zip
2. Extract AppName.zip -> you will see Payload/AppName.app
3. Run: otool -o AppName.app/AppName
4. Now you need find UIWebView in terminal (cmd + F)

[tipa]

Did this and it gives me an extremely long output of hex numbers (presumably memory addresses?) but no readable names, like "UIWebView". Then simply opened the assembly dll in a text editor and in my case it seems like the InAppSettingsKit bindings references the UIWebView. In the native library the reference was already removed, but the bindings are totally outdated.... :/

Thanks for your help!

[thongdoan]

Glad to hear that you fixed it, but it should output something like:

Meta Class
           isa 0x0 _OBJC_METACLASS_$_NSObject
    superclass 0x0 _OBJC_METACLASS_$_NSObject
         cache 0x0 __objc_empty_cache
        vtable 0x0
          data 0x1f4abb4 (struct class_ro_t *)
                    flags 0x185
            instanceStart 20
             instanceSize 20
               ivarLayout 0x0
                     name 0x1e2de5d PPMockURLResponseManager
              baseMethods 0x1f4aba0 (struct method_list_t *)
           entsize 12
             count 1
              name 0x1dda343 defaultManager
             types 0x1e2ea6a @8@0:4
               imp 0x1929507
            baseProtocols 0x0
                    ivars 0x0
           weakIvarLayout 0x0
           baseProperties 0x0
01ec5538 0x1f78954
           isa 0x1f78968
    superclass 0x0 _OBJC_CLASS_$_UIWebView
         cache 0x0 __objc_empty_cache
        vtable 0x0
          data 0x1f4b234 (struct class_ro_t *)
                    flags 0x184
            instanceStart 4
             instanceSize 60
               ivarLayout 0x1e2dea8
                layout map: 0x12 0x33 0x21 
                     name 0x1e2de8a PPHTMLLabel
              baseMethods 0x1f4aed4 (struct method_list_t *)

...A Lots of hexa at the bottom...
0000000101e34918 0x1020c4bc8
0000000101e34920 0x1020c4c28
0000000101e34928 0x1020c4c90
0000000101e34930 0x1020c4cf0
0000000101e34938 0x1020c4d60
0000000101e34940 0x1020c4e60
0000000101e34948 0x1020c4f70
0000000101e34950 0x1020c4fd0

In my case, it is also a third party library

[spouliot]

Some additional tooling landed with the Xamarin.iOS 13.16 release, available in the Xcode 11.4 Preview Public Release channel.

This includes additional mtouch arguments to:

• Detect the presence of UIWebView (or any type) in the input and output assemblies

• Forcefully remove managed references from the built application

The preview can be installed, temporarily, to help you diagnose warnings from the App Store and identify where the culprit code reside. Once identified you can switch back to the Stable channel, update/fix, and submit your applications.

[spouliot]

The above comments and this blog post can also be useful if the references are only part of native code.

[prin53]

Another way to detect UIWebView usage:

• Remove bin/obj folders to avoid unnecessary matches
• In Terminal, cd to the project _source_ code
• Run grep -r 'UIWebView' . from here
• In my case there is an old NuGet package and the output looks like this:

./src/packages/Xamarin.1PasswordExtension.1.8.4/lib/Xamarin.iOS10/OnePasswordExtension.dll matches

[spouliot]

@Prin53 yes, but it's less accurate. For example if that nuget included

Console.WriteLine ("I don't use UIWebView anymore");

or

public enum UIWebViewOptions { ... }

then grep would report them.

Still it's useful if UIWebView was only included in a (static .a or dynamic .dylib) native library that you include inside your application.