Our clients recently encountered an issue when viewing PDF reports on iPad/iOS devices (Tablet Mode). The embedded PDF component only displays the first page and cannot be scrolled, whereas the exact same page displays and scrolls perfectly on desktop browsers.
We performed a comprehensive diagnostic by setting up 4 different embedding methods side-by-side:
- Method A:
<iframe>+ Direct URL - Method B:
<iframe>+ Blob URL - Method C:
<embed>+ Direct URL - Method D:
<object>+ Direct URL - Method E: Direct Link (
target="_blank") opening in a new tab
Diagnostic Result: Methods A, B, C, and D all failed on iPad (only the first page was visible). Only Method E worked flawlessly.
Root Cause Analysis (Unresolvable at Native HTML Level)
This behavior is not a bug in our application code. It is a hard system-level limitation enforced by Apple’s iOS/iPadOS WebKit engine.
To save memory and optimize battery life on mobile devices, Apple’s mobile browser core refuses to spawn a fully-functional PDF rendering thread inside regular HTML tags (<iframe>, <embed>, <object>). Instead, it silently takes a snapshot image of the first page and renders that image inside the container. Therefore, no matter which native HTML tag or container we use, it will always be restricted to a single page on iOS.
Furthermore, switching browsers (e.g., to Chrome or Edge on iPad) will not resolve this. Per Apple’s App Store Review Guidelines (Section 2.5.6), all third-party browsers on iOS/iPadOS are legally and technically forced to use Apple’s underlying WebKit (WKWebView) framework. They all share the exact same rendering limitations as Safari.
Official Documentation & Community Evidence
For more context and proof of this long-standing platform constraint, please refer to the following official and developer community discussions:
| Source | Reference Link |
|---|---|
| Apple Developer Forum | Apple Forum: Iframe Scrolling issues on iOS / Safari rendering first page as an image |
| Stack Overflow | Stack Overflow: PDF in iframe only showing first page on iPhone/iPad |
| Apple App Store Policy | Apple App Store Review Guidelines - Section 2.5.6 (WKWebView Requirement) |
Proposed Solutions for Our Product
Since a native inline fix is technically impossible due to OS restrictions, we propose two actionable alternatives for our upcoming iterations:
- Option 1: Device-Adaptive Layout (Zero Cost & 100% Secure)
We can introduce a simple User-Agent check in our frontend. If the user is on a desktop, keep the standard inline layout. If the user is on an iPad/iPhone, hide the broken embedding frame and show a clean, prominent button saying: “You are using an iOS device. Click here to open the full document in a new tab.” (Triggering Method E). - Option 2: Private Deployment of Mozilla’s PDF.js (Best UX)
We can download Mozilla’s open-source PDF.js engine and package it directly into our localsrc/assetsfolder. PDF.js uses HTML5 Canvas to manually reconstruct PDF pages into standard web elements pixel by pixel. This completely bypasses Apple’s restrictions and works 100% offline/on our private intranet with zero license risks (Apache 2.0 License).