Why Shouldn't A UIWebView Be Placed in a UIScr

Question

The Question

Does anyone know of technical reasons for avoiding web views inside scroll views on iOS (assuming you're willing to disable scrolling inside the web views themselves)?

If you look at the Apple docs for UIWebView, they state:

Important: You should not embed UIWebView or UITableView objects in UIScrollView objects. If you do so, unexpected behavior can result because touch events for the two objects can be mixed up and wrongly handled.

My Educated Guess

It looks like maybe they're warning you against putting a scroll view inside another scroll view, because touches can be confused between the inner, and outer scroll views.

But, there's a very valid reason to want to put a UIWebView inside a scroll view. Web views aren't just scroll views. UIWebView can easily display a wide range of web content.

If there is no need to allow scrolling within the UIWebView itself, and you turn off scrolling with either:

webView.userInteractionEnabled = NO;

or

webView.scrollView.scrollEnabled = NO;

then is there really any problem with this design?

I'm wondering if this is partly an artifact of the original UIWebView interface, where it did not give you direct (and documented) access to its embedded UIScrollView (to be able to disable its scrolling easily). Maybe this statement in the Apple docs is a legacy of that?

Project Context

I ask because I'm maintaining an app (written by someone else) that uses a handful of web views inside a scroll view that allows scrolling between them horizontally. The web content must be considered fixed (not changeable), and it only shows one page of content per HTML page. The user needs to be able to scroll between pages, so multiple UIWebViews inside a UIScrollView were chosen for that. So far, it appears that it may be working properly.

However, the pages show full screen images, and scrolling performance is an issue. But, I'm trying to determine if the fundamental nesting of web views inside scroll views (which Apple warns against) is really part of the problem.

Answer 1

I have encountered at least one other reason for this:

UIWebViews appear not to run any JavaScript while they are scrolling. My JavaScript-animated content is frozen while the web view is scrolling and continues where it left off as soon as scrolling ends.

Presumably, this is a performance optimization. Now when we scroll a scroll view that contains web views, the web views are not aware that they are moving, and thus will not pause their JavaScript.

The question, of course, is whether or not this affects performance in a significant way, and on which iPad models.

Answer 2

The only reason Apple does not recommend putting UIWebViews inside UIScrollViews if for the one you explain: because scrolling would risk to be mixed up between the two scroll views.

I guess they wrote this because, by the fact that UIWebView inherits UIView and not UIScrollView, and thus is not a scrollview itself (but embeds one), this may be not obvious for the unexperimented user that the web content can be scrollable depending on the HTML, which would mess up with the container scrollview if any. So that is probably just a reminder for this case.

But if you disable the scrolling, I can't see any reason why this would go wrong.

Note anyway that disabling user interaction on the scrollview is not the same as disabling scrolling. If your HTML content contains links or other clickable/tappable content, disabling user interaction will disable them too. To only disable scrolling only but keep user interaction like simple taps, use webview.scrollView.scrollEnabled = NO instead of webview.scrollView.userInteractionEnabled = NO.