ITMS-90809 is Apple telling you the app still references UIWebView, an API it stopped accepting years ago. The catch that makes this error frustrating is that you probably are not using UIWebView in your own code; an old third-party SDK is, and it dragged the reference into your binary. UIWebView was deprecated for good reasons, including security ones, and WKWebView replaced it. Here is what the error means, why Apple removed UIWebView, and how to track down the dependency that is keeping you from submitting.
Short answer
ITMS-90809 means your app still contains references to UIWebView, a deprecated web view API that Apple no longer accepts in submissions. Per Apple's deprecation notice, you must replace UIWebView with WKWebView, which is the supported and more secure web view. The reference is often not in your own code but in an outdated third-party SDK, such as an ads or analytics library, so the fix is to find which dependency includes UIWebView and update or replace it. Search your binary for the UIWebView symbol, remove the source, increment your build number, and resubmit.
What you should know
- It is a deprecated-API rejection: UIWebView is no longer accepted.
- Use WKWebView instead: the supported, more secure web view.
- SDKs are the usual source: an old library often carries the reference.
- Your own code may be clean: the symbol can come entirely from a dependency.
- Find the symbol, then the SDK: locate UIWebView and the library that uses it.
What does ITMS-90809 mean?
That Apple detected the UIWebView API in your uploaded binary and rejected it during processing. UIWebView was deprecated, and Apple stopped accepting new apps and then app updates that reference it, so any remaining use of the API blocks your submission with ITMS-90809. This is an automated check on the binary, not a human review decision, and it triggers on the mere presence of the UIWebView symbol, regardless of whether that code path ever runs. So even a dormant reference inside a library counts. The error is specific and binary, the API is either present or it is not, which is why the path forward is to locate and eliminate every reference rather than to argue the case.
Why is UIWebView gone, and why is WKWebView better?
Because WKWebView is a more capable and more secure web view, and Apple moved the platform to it. UIWebView ran web content in the app's own process with an older engine, while WKWebView renders web content out of process with the modern WebKit engine, which improves both performance and security isolation. From a security standpoint, out-of-process rendering means a compromise in the web content is better contained, and WKWebView supports modern web security features more fully. So the deprecation is not arbitrary housekeeping; it pushes apps onto a web view that isolates untrusted web content more safely. Replacing UIWebView with WKWebView is therefore both a compliance fix and a genuine security improvement for any app that displays web content.
How do you find and fix it?
Locate the UIWebView reference, identify its source, and remove it. The table shows the two cases.
| Where the reference lives | How to fix it |
|---|---|
| Your own code | Replace UIWebView with WKWebView and adjust the API calls |
| A third-party SDK | Update the SDK to a version that uses WKWebView, or replace it |
| An unmaintained dependency | Remove it if no updated version exists |
Start by searching the compiled binary for the string UIWebView, since that tells you whether the reference is present at all and helps point at the offending framework. If it is your code, migrate to WKWebView, whose API differs but covers the same use cases. If it is an SDK, update to a current version, because most maintained libraries removed UIWebView years ago; if a dependency is abandoned and still uses it, replace it. After removing every reference, increment the build number and resubmit.
What to watch out for
The first trap is assuming the problem is in your code when it is almost always a stale SDK, so search the binary and audit dependencies first. The second is updating one library while another still carries UIWebView, which produces a repeat ITMS-90809. The third is missing a transitive dependency that bundles an old web view. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces the SDKs and symbols in your build, which helps you locate a UIWebView reference and the dependency that introduced it before the upload bounces. Fixing the dependency at its source is what clears the error for good.
What to take away
- ITMS-90809 means your binary still references UIWebView, a deprecated API Apple no longer accepts, so you must move to WKWebView.
- WKWebView is the supported replacement and is more secure, rendering web content out of process with the modern WebKit engine.
- The reference usually comes from an outdated third-party SDK rather than your own code, so find the symbol and update or replace the library.
- Use a pre-submission scan such as PTKD.com to locate the UIWebView reference and its source SDK before you resubmit.
