Exposure checks failing: Apple internal views detected as "obstructing"

[MattMur]

I'm guessing this might be something relatively new with iOS 26's new Glass UI....I'm seeing an issue where my prebid ad view is reporting viewability exposure checks incorrectly. It looks like Apple internal views FloatingBarContainerView and FloatingBarHostingView are being overlayed on top of my view heirarchy when using a UINavigationController, then, during the viewability polling in the method testForObstructing it is detecting these views as being obstructions and setting exposure to zero, even when the ad is 100% in view.

In the view hierarchy debugger, you can see the two Apple internal view's overlayed on top:

Has anyone else experienced this issue? Are there any workarounds? Ideally I would expect Prebid to be smart enough check that a view is transparent before considering it as an obstruction.

[YuriyVelichkoPI]

The viewability tracking approach of Prebid SDK is based on the Open Measurement approach. It assumes that only parts of the ad which are on the screen and not covered by any other views considered as viewable.

If there are any known views which covers the ad on purpose - they should be registred as friendly obstructions. Including the transparent overlaps.

I should admit that prebid SDK doesn't provide API to register the friendly obstructions like Google IMA does: https://developers.google.com/interactive-media-ads/docs/sdks/android/client-side/omsdk#:~:text=This%20transparent%20overlay%20is%20used,controls%20must%20not%20be%20registered.&text=The%20following%20sample%20code%20demonstrates,The%20string%20can%20be%20nil.

Prebid SDK registers only own obstructions (playback and interstitial controls). And encourage publishers to be sure that the ad view is not covered by any other view in the app layout.

Until now we haven't received any complains about this policy. But of course, it can be revisited.

So in the scope of this task we can support new iOS version by registering the new know iOS' views as friendly obstructions.

But we still shouldn’t ignore transparent overlapping views when determining ad visibility. Their opacity can change at any time due to external logic, and the ad may stop being visible.

As the separate scope we can introduce API to register friendly obstructions.

[MattMur]

Sounds perfect, thank you.

[YuriyVelichkoPI]

@mdanylov-sigma please take this issue in progress with highest priority.

[mdanylov-sigma]

Hey @MattMur! Do you have any sample project where the issue is reproducible, and you can share it with us ?

[MattMur]

Hi @mdanylov-sigma, I do have my own sample app I'm using, but you can recreate this using the Prebid InternalTestApp actually. I'm running on a iPhone 17 simulator using iOS 26. Simply load up any ad that using Prebid rendering, and then see that viewable in onViewabilityChanged is always false. Also the viewability callback in PBMWebView will never be called.

[mdanylov-sigma]

Hi @mdanylov-sigma, I do have my own sample app I'm using, but you can recreate this using the Prebid InternalTestApp actually. I'm running on a iPhone 17 simulator using iOS 26. Simply load up any ad that using Prebid rendering, and then see that viewable in onViewabilityChanged is always false. Also the viewability callback in PBMWebView will never be called.

Thanks, will try

[MattMur]

@mdanylov-sigma Actually, my bad, it looks like viewable in onViewabilityChanged does in fact fire, since it seems to use a different "legacy" tracking method. It's only the exposure callback in PBMWebView that doesn't fire due to this issue.

On that note, do we know why we have two separate viewability trackers? One in PBMHTMLCreative and the other in PBMWebView. It seems that handles notifying viewability event to the outside, while the tracker in PBMWebView is for notifying MRAID. But could it be possible to simply have a single tracker in PBMHTMLCreative that notifies both?