[Web] App crashes on safari on iOS when loading large images

This reproduces reliably on all iPhones.

To repro:

Open https://vitalsynergyoregon.web.app in iPhone
Observe how the website opens couple times and then error page (below in comment)

source code: https://github.com/vitalsynergy/vital_synergy
deployed website: https://vitalsynergyoregon.web.app/
i deployed this app by running firebase deploy in the folder website. I tried both Flutter master and Flutter stable, also i tried to recreate firebase project and deploy to it.

what SDKs I tried:

flutter --version
Flutter 3.24.0-1.0.pre.214 • channel master • [email protected]:flutter/flutter.git
Framework • revision c63733310f (9 days ago) • 2024-07-20 19:26:30 -0400
Engine • revision 207f088f73
Tools • Dart 3.6.0 (build [3.6.0-55.0.dev](http://3.6.0-55.0.dev/)) • DevTools 2.37.1

 flutter --version
Flutter 3.22.3 • channel stable • [email protected]:flutter/flutter.git
Framework • revision b0850beeb2 (13 days ago) • 2024-07-16 21:43:41 -0700
Engine • revision 235db911ba
Tools • Dart 3.4.4 • DevTools 2.34.3

Reproducible using the code sample in the repo provided above.

I managed to reduce the code sample to what was actually causing the crash. The issue is caused by trying to load
https://github.com/vitalsynergy/vital_synergy/blob/main/website/assets/images/logo_large.jpg

The reduced code sample is posted below. The image is about 18.7mb so I can't upload it in the comment (GH apparently has a 10mb image limit)

As noted above, this works fine on android and desktop browsers.

code sample

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      home: Scaffold(
        body: Center(child: Image.asset('assets/logo_large.jpg',),),
      ),
    );
  }
}

flutter doctor -v

[✓] Flutter (Channel stable, 3.22.3, on macOS 14.5 23F79 darwin-arm64, locale en-GB)
    • Flutter version 3.22.3 on channel stable at /Users/nexus/dev/sdks/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision b0850beeb2 (2 weeks ago), 2024-07-16 21:43:41 -0700
    • Engine revision 235db911ba
    • Dart version 3.4.4
    • DevTools version 2.34.3

[!] Flutter (Channel master, 3.24.0-1.0.pre.410, on macOS 14.5 23F79 darwin-arm64, locale en-GB)
    • Flutter version 3.24.0-1.0.pre.410 on channel master at /Users/nexus/dev/sdks/flutters
    ! Warning: `flutter` on your path resolves to /Users/nexus/dev/sdks/flutter/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/nexus/dev/sdks/flutters. Consider adding /Users/nexus/dev/sdks/flutters/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/nexus/dev/sdks/flutter/bin/dart, which is not inside your current Flutter SDK checkout at /Users/nexus/dev/sdks/flutters. Consider adding /Users/nexus/dev/sdks/flutters/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision dc99d2f692 (6 hours ago), 2024-08-01 21:40:10 -0400
    • Engine revision fe39ed980e
    • Dart version 3.6.0 (build 3.6.0-107.0.dev)
    • DevTools version 2.38.0
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

To give an update on this issue:

I previously addressed the iOS Safari crash by introducing an ImageDecodingManager that throttled simultaneous HTMLImageElement.decode() calls. This significantly reduced concurrent memory spikes and helped alleviate the OOM crashes.

Currently, I am in the process of landing a major refactor to the web engine's image decoding architecture (unifying the CanvasKit and Skwasm pipelines). As part of this refactor, we are completely removing the legacy HTML image element-based codec. Instead, for Safari and other browsers that do not support the native ImageDecoder API, we are now using createImageBitmap for static image decoding.

createImageBitmap is a much more robust browser API and does not suffer from the same concurrency bugs and limitations as the old HTMLImageElement.decode() method.

Once this unification refactor lands, we will monitor the performance and memory behavior of createImageBitmap on iOS Safari. If we find that throttling createImageBitmap calls is still beneficial for keeping peak memory usage low on highly resource-constrained iOS devices, I will re-introduce the ImageDecodingManager throttling in a follow-up PR.

@harryterkelsen

@harryterkelsen Thank you for your efforts to resolve this critical issue for our applications. Can we test these fixes in a beta version? It appears the fixes haven't been implemented in 3.46.0-0.2.pre, as the bug is still present. When do you plan to include them, at least in a beta release? Thanks in advance for your feedback.

@harryterkelsen

@harryterkelsen The same for my team. We are still catching the bug.
Thanks for your efforts.

@harryterkelsen

@harryterkelsen Hi, any updates?
Thanks

The image decoding refactor has landed. I'm going to verify that decoding many large images is better with a real iOS device and report back

By the way, you can work around this issue pretty effectively by setting webHtmlElementStrategy: WebHtmlElementStrategy.prefer if you are using Image.network. Safari seems to heavily optimize <img> elements which make them much faster than creating a bitmap to upload to WebGL (the normal codepath on web). If you can, please try that out and let me know if it works for you.

@harryterkelsen

Thank you @harryterkelsen for your work on this! Do you know which Flutter version this patch will be included in?

Thank you for the suggestion. I tested webHtmlElementStrategy: WebHtmlElementStrategy.prefer, and the issue is still present, but it occurs much less quickly than before.

When navigating rapidly between pages, Safari now crashes after dozens of very fast navigations, whereas previously it would only take a few navigations to crash the browser.

I also noticed that the issue takes significantly longer to occur when using smaller/lighter images.

So this workaround definitely improves the situation, but unfortunately it doesn't completely resolve the issue in my case.

You can test it using the following link. Here is the video demonstrating the issue.
https://devmode.scan.feadys.com

issue_safari_app_crache.mp4

@Bylinkk

@Bylinkk thanks for the repro. I'll investigate shortly

Any update?

I made a VERY agent-forward stab at this: #193408

if you're able to try it out on a physical device (I only have access to a simulator) I'd love to know if it helps!

[web] Clear HTMLImageElement.src when WebImageInfo and ImgElementPlat…

Landed a partial fix in #193408 - I'd LOVE anyone to try out Flutter @ HEAD and let me know if it helps!

[web] Clear HTMLImageElement.src when WebImageInfo and ImgElementPlat…

Navigation Menu

Repository navigation

[Web] App crashes on safari on iOS when loading large images #152709

91 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Web] App crashes on safari on iOS when loading large images #152709

Description

Activity

polina-c commented on Aug 1, 2024

danagbemava-nc commented on Aug 2, 2024

91 remaining items

harryterkelsen commented on Jun 25, 2026

Bylinkk commented on Jun 30, 2026

fobos commented on Jul 2, 2026

fobos commented on Jul 9, 2026

harryterkelsen commented on Aug 4, 2026

harryterkelsen commented on Aug 4, 2026

Bylinkk commented on Sep 12, 2026

Bylinkk commented on Sep 12, 2026

Bylinkk commented on Sep 12, 2026

harryterkelsen commented on Sep 14, 2026

Garciconx commented on Sep 26, 2026

kevmoo commented on Sep 27, 2026

kevmoo commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions