"works just fine in Chrome, Firefox, Edge as well as Safari on MacOS and Safari in the Mobile simulator. Only actual iOS devices fail." In our case, it's a regular PWA page, and it crashes immediately, but we believe this is the same issue. Given that this only occurs on actual iPhone devices, we believe it's a problem associated with the iPhone's OS and AP, or more specifically, a malfunction in the OS's memory management logic or malicious pattern blocking logic. This post is from last year, and it's surprising that the same issue is still being reported, and as a developer, I'm deeply pessimistic.

Additionally, I've discovered something new: If I click "Request Mobile Website" in the page menu while the page load fails, the page loads normally! However, if I enable "Request Desktop Website" at the bottom of the menu, it only works on the initial mobile-to-desktop transition. Reloading the page or quitting and restarting Safari still fails. This clearly indicates a bug in the iPhone's WebKit system.

Additionally, I've discovered something new: (Corrected a wording error.) If I click "Request Desktop Website" in the page menu while the page load fails, the page loads normally! However, if I enable "Request Desktop Website" at the bottom of the menu, it only works on the initial mobile-to-desktop transition. Reloading the page or quitting and restarting Safari still fails. This clearly indicates a bug in the iPhone's WebKit system.

I've submitted feedback regarding this, and the ID is as follows: FB20357937

Here's what we've confirmed: When screen recording is enabled on an iPhone 12 mini and you attempt to access the page in Safari, the recording ultimately stops, and Safari either closes or the iPhone Home app closes and restarts. However, this issue does not occur on an iPad mini 6. We understand that both models have the same amount of memory (4GB). It appears to be an issue with the iPhone OS's memory management. We've updated the existing feedback with diagnostic information.

Here's what we've confirmed: On the same device (iPhone 12 Mini) as the reply above, when screen recording is enabled and the page is loaded, an OOM error occurs. However, when the desktop page is requested and loaded normally, the screen recording does not stop. There appears to be a factor in the mobile page request mode routine that is causing excessive memory usage. Furthermore, when the same test was performed on an iPhone Air, no OOM error occurred, and a normal page load error was recorded in the screen recording. I look forward to a speedy resolution. Thank you.

Additionally, I'd like to share with you what we've confirmed through our own testing. Currently, we've conducted tests in index.html, commenting out scripts and CSS files or blocks, and then loading them. As a result, the following two cases exist, based on my Safari app test on my iPhone 12 mini (iOS 26). First case: I simply commented out the single /styles/estreUi.css link, and the page loaded normally. (The UI is broken, however, because the style sheet is missing.) Please note that this has been applied to testclass.mangoedu.co.kr. Second case: I commented out all script files and blocks, and then commented out each link, starting with the last linked CSS file, until it loaded normally. This was applied to betaclass.mangoedu.co.kr. (Depending on the situation, this error may occur intermittently, and it may load normally even if three additional CSS files, including the one before main.css, are loaded.) *Since there is no script, the gray screen loads normally. What's unusual is that when the Web Inspector window is opened via Safari on a connected Mac after the page loads normally, the page immediately crashes as before. Since both sites share the same source code, there is no difference between the two sites. Since estreUi.css loaded normally after being commented out, one might assume that the file was not the issue. However, in the second case, the page loaded normally with the file included, and other low-volume sites that use the same framework elements also load normally. I have updated the feedback by reproducing the process of the second case, which loaded normally and then crashed upon launching the Web Inspector, and attached diagnostic information. This test further confirms that the issue is a memory issue, especially since the error is triggered when the Web Inspector is launched. Please resolve this issue promptly.

Since I need to keep updating the existing sites I've disclosed above, I've separated the crash test pages into a separate domain. Please test them using the following domains instead of the addresses in the main text: https://iphoneblowclass.mangoedu.co.kr https://iphonecase1class.mangoedu.co.kr https://iphonecase2class.mangoedu.co.kr

We've finally found a way to bypass the iPhone's loading crash issue. We split the culprit CSS file into multiple files, leaving only the minimal CSS links needed to display the splash screen, and lazy-loaded the rest within the framework after the page's onLoad event. This allowed the pages to load without crashing, and it worked for all three sites mentioned in this article. However, this issue isn't resolved. It's simply unacceptable that a DOS-era 360KB memory limit exists in 2025. This issue still needs to be addressed, and until it is, it will remain a blemish on the iPhone. In that spirit, we'll keep the three separate sites mentioned in the reply above available for reproduction, and we'll await Apple's official response in this thread. If anyone reading this thread agrees with this, please give it a boost.

Through additional page modifications, we've confirmed that the volume of font files linked within CSS also affects the crash. While the site currently loads without errors when scheduled for live service, this means the issue could reoccur if the volume is increased at any point in the future. Furthermore, page load failures are also affected by the native volume of the app loading the page. Our own WebView app for the App Store, in previous versions (version 2.0.1 on TestFlight), was able to load pages before the workaround was applied with a very high probability. However, even if the source code was maintained, simply updating the included libraries to the latest version resulted in unconditional load failures. Our current, upcoming release version of the app has increased the volume even further, resulting in a lower page volume limit than the maximum page volume allowed in Safari on iOS 26. (The amount of CSS used during the initial load must be reduced to a very extreme level.) We sincerely hope that this issue will not be dismissed as a workaround within Apple's development team but will be addressed in the near future.