ITMS-90809: Deprecated API Usage, and finding the UIWebView you did not write

ITMS-90809 means something in your app references UIWebView. Usually not your code. Usually a prebuilt framework or an old dependency that still carries the reference, whether or not anything ever calls it.

The check reads your binary, so removing the class from your source is not sufficient if a linked framework still contains it.

The message, and which one you got

Apple used at least three wordings as the deprecation moved from advisory to enforced. Which one you received tells you how much trouble you are in.

The advisory version:

"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."

The version with dates:

"ITMS-90809: Deprecated API Usage. Apple will no longer accept submissions of new apps that use UIWebView as of April 30, 2020 and app updates that use UIWebView as of December 2020. Instead, use WKWebView for improved security and reliability."

The enforced version:

"ITMS-90809: Deprecated API Usage. New apps that use UIWebView are no longer accepted. Instead, use WKWebView for improved security and reliability."

If your email arrived alongside "Your delivery was successful, but you may wish to correct the following issues in your next delivery", the build landed and you have time. If it arrived alongside "Please correct the following issues, then upload again", the build did not land and you do not.

Both deadlines in the second message have long passed, so treat any ITMS-90809 today as blocking.

Why it fires on apps that use WKWebView

Because the check looks for the class reference in the compiled binary, not for a call site in your source.

Reported sources, all with the framework named in the error or found by the developer afterwards:

• Firebase ML frameworks. FirebaseMLCommon and FirebaseMLVision were found to contain the reference in several reports. Updating the pods fixed it.
• Google Sign-In, in older versions, which used a web view for the auth flow.
• Ad and attribution SDKs, which historically rendered creatives in a web view.
• Cordova and PhoneGap plugins. cordova-plugin-wkwebview-engine exists precisely because the default engine used UIWebView, and a project can end up with both.
• Flutter packages with old iOS platform code, particularly anything doing OAuth or in-app browsing.
• Any framework not rebuilt in years. A .framework or .a compiled in 2018 contains whatever it contained in 2018.

The pattern: it is nearly always a dependency, and nearly always fixed by updating that dependency rather than by changing anything you wrote.

Finding it

Search source and prebuilt binaries separately, because grep on source will miss a compiled framework.

Source and dependency trees:

grep -rn "UIWebView" . \
  --include=*.h --include=*.m --include=*.mm \
  --include=*.swift --include=*.xib --include=*.storyboard

The storyboard and xib includes matter. A UIWebView dropped onto a screen in Interface Builder years ago will not show up in a source-only search.

Prebuilt binaries, which is where the answer usually is:

grep -rl UIWebView Pods/ Carthage/ node_modules/ 2>/dev/null

grep will report Binary file Pods/SomeSDK/SomeSDK.framework/SomeSDK matches. That line is your culprit.

And to check the built bundle before you upload again, which covers the app binary and every embedded framework in one pass:

grep -rl UIWebView "MyApp.app"

No output means the whole bundle is clean.

Fixing it

Update the dependency. First and best. Every major SDK removed UIWebView before the 2020 deadline, so an update usually resolves it outright. Run your package manager's update, rebuild, and re-run the grep.

Remove the dependency. If the SDK is abandoned and no updated version exists, it will not be fixed. Nobody is coming back to it in 2026. Replace it or drop the feature.

Migrate your own code to WKWebView. If the reference genuinely is yours, this is the real work. WKWebView is not a drop-in replacement: it loads content in a separate process, has an asynchronous JavaScript evaluation API, and handles cookies and local file access differently. Budget properly for it rather than expecting a find and replace.

Delete it from the storyboard. If the reference came from a xib or storyboard, open the file, delete the view, and rebuild. This is the fastest possible fix and worth checking early.

Check for duplicate web view engines in Cordova and Capacitor projects. Two engine plugins installed together will keep the old reference alive no matter what you configure.

A note on scope

Every reported instance of ITMS-90809 that I can find names UIWebView. The code's label is the generic "Deprecated API Usage", which suggests Apple could reuse it for other deprecations, but I have not seen it do so.

So: if your message names UIWebView, everything above applies. If it names something else, treat the named API as the subject and the general approach as the same. Do not assume the fix is a UIWebView fix because the code matched.

Why this still happens in 2026

UIWebView was deprecated with iOS 12 and Apple stopped accepting submissions using it in 2020. A project started today cannot produce this error from its own source.

What survives is prebuilt binaries. A framework compiled against an old SDK carries the reference forever, and it does not care what Xcode you build your app with. That is the whole reason this page is about grepping dependencies rather than about migrating code: for almost everyone still hitting it, the reference is in a file they did not compile.