# Technical Limitation: PDF Embedded via iframe/embed/object Only Standardly Renders the First Page on iPad/iOS

**URL:** <https://community.criticalmanufacturing.com/t/technical-limitation-pdf-embedded-via-iframe-embed-object-only-standardly-renders-the-first-page-on-ipad-ios/956>\
**Category:** Lounge\
**Created:** [October 21, 2026, 10:46am UTC](https://community.criticalmanufacturing.com/t/technical-limitation-pdf-embedded-via-iframe-embed-object-only-standardly-renders-the-first-page-on-ipad-ios/956 "2026-10-21T10:46:03Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Lainey\_Lian](https://avatars.discourse-cdn.com/v4/letter/l/9de053/32.png) [@Lainey\_Lian](https://community.criticalmanufacturing.com/u/Lainey_Lian)\
**Post date:** [October 21, 2026, 10:46am UTC](https://community.criticalmanufacturing.com/t/technical-limitation-pdf-embedded-via-iframe-embed-object-only-standardly-renders-the-first-page-on-ipad-ios/956/1 "2026-10-21T10:46:03Z")

</div>

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:

1. **Method A:** `<iframe>` + Direct URL
2. **Method B:** `<iframe>` + Blob URL
3. **Method C:** `<embed>` + Direct URL
4. **Method D:** `<object>` + Direct URL
5. **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)](https://developer.apple.com/app-store/review/guidelines/)**, 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](https://stackoverflow.com/questions/53558808/pdf-in-iframe-only-first-page-on-iphone-ipad)** |
| **Apple App Store Policy** | **[Apple App Store Review Guidelines - Section 2.5.6 (WKWebView Requirement)](https://developer.apple.com/app-store/review/guidelines/)** |

* * *

**💡 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 local `src/assets` folder. 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)**.

---

<div class="post-metadata">

**Author:** ![Ricardo\_Cunha](https://yyz2.discourse-cdn.com/flex050/user_avatar/community.criticalmanufacturing.com/ricardo_cunha/32/1133_2.png) [@Ricardo\_Cunha](https://community.criticalmanufacturing.com/u/Ricardo_Cunha)\
**Post date:** [October 21, 2026, 10:47am UTC](https://community.criticalmanufacturing.com/t/technical-limitation-pdf-embedded-via-iframe-embed-object-only-standardly-renders-the-first-page-on-ipad-ios/956/2 "2026-10-21T10:47:24Z")

</div>

Hi Lainey,

Please note that iPads (iPadOS) are not supported as a client device.

From the CM documentation ([Client Devices - Critical Manufacturing Documentation Portal](https://help.criticalmanufacturing.com/systemrequirements/clientdevices/)):

| **Operating System** | **Supported browsers** |
| --- | --- |
| **Android 10 or later** | • Google Chrome |
| **Linux ARM** | • Chromium |
| **Microsoft Windows 10 / 11 (32 or 64-bit editions)** | • Google Chrome  
• Microsoft Edge |
| **macOS** | • Google Chrome |

Best regards,  
Ricardo
