[expo-image][ios] SVG rendering issues

[jozan]

Minimal reproducible example

https://github.com/jozan/svg-expo-image-rendering-ios-repro

Summary

on iOS there are rendering issues with svgs when using expo-image. i've attached a repro repo which uses managed expo workflow with sdk 49.

icon sets that are used as examples:

• ionicons v7.1.2
• heroicons v2.0.18

i have attached some screenshots show that some svgs render blank and some have weird rendering issues. as we can see, rendering fails on some very simple paths. i have highlighted some of the issues on the screenshots for quick reference.

we can also see that on the heroicon there are lots of blank icons. almost all of the blank icons are outline type icons that are simple paths.

note

some of the rendering issues can be fixed by running svgo on svgs which alters paths. this fixes all heroicon icons that are type of solid. sadly this doesn't fix any of the rendering issues on ionicons. this is not done on any of the svgs in the repro repo nor is its set up.

pinging @tsapeta since we had brief conversation about this issue on expo's discord and he mentioned having some initial plans to change the underlying native svg rendered at some point the future. however, there is no timeline for this as of now.

Environment

  expo-env-info 1.0.5 environment info:
    System:
      OS: macOS 13.4.1
      Shell: 3.6.1 - /usr/local/bin/fish
    Binaries:
      Node: 20.5.0 - ~/n/bin/node
      Yarn: 3.5.0 - ~/n/bin/yarn
      npm: 9.8.0 - ~/n/bin/npm
      Watchman: 2023.07.10.00 - /usr/local/bin/watchman
    Managers:
      CocoaPods: 1.12.1 - /usr/local/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
    IDEs:
      Xcode: 14.3.1/14E300c - /usr/bin/xcodebuild
    npmPackages:
      expo: ~49.0.3 => 49.0.3
      react: 18.2.0 => 18.2.0
      react-native: 0.72.3 => 0.72.3
    Expo Workflow: managed

[expo-bot]

Thank you for filing this issue! This comment acknowledges we believe this may be a bug and there’s enough information to investigate it. However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

[smbryar]

Wondering if there is any timeline on this? It would be really useful for my app as currently can't use the SVGs I want with this package as they are getting distorted.

[tian000]

@jozan im curious if you were able to render these SVG images with react-native-skia maybe Expo could switch to use skia under the hood.

[jozan]

@jozan im curious if you were able to render these SVG images with react-native-skia maybe Expo could switch to use skia under the hood.

i haven't tested on skia. the repo is still up for anyone to try.

[chriszs]

The SDWebImageSVGCoder plugin this library relies on uses an undocumented Apple API called CoreSVG, which it calls through base64 obfuscated methods to fool Apple's static analysis. CoreSVG unfortunately seems to be incomplete, though how incomplete seems to be a bit of a mystery. I'm dealing with an issue where it doesn't show an embedded image rendered in a pattern using objectBoundingBox units, which may or may not merit a separate issue in one of these projects, but which the only real solution for is probably to change renderers.

The maintainers claim CoreSVG is at least better than SVGKit, which they were using previously.

They've also come out with SDWebImageSVGNativeCoder, which uses an Adobe library to render a standardized SVG subset called SVG-Native. They claim better compatibility with that standard, but the standard only covers part of the overall SVG spec by design, so that has a list of caveats.

Skia's SVG renderer seems cool, but also has a list of caveats, as documented on the page you linked to.

So, which one is going to work best depends on what subset of SVG is needed. I wonder if it would make any sense to allow an expo-image user some control over which SDImage SVG plugin is used, among the three available.

Unfortunately, for my use case I'm loading arbitrary SVGs supplied by users, so that subset may be pretty open-ended (though not infinitely so, I don't need interactivity, animation, scripting, etc.). It's getting judged against browser support for those same SVGs. And if it doesn't work, it looks bad in front of a lot of people.

The SVGView project, which seems even more incomplete than some other solutions, had at one point the ambition to reach 100% feature completeness, and so runs their renderer against a test suite of samples provided by W3C. It'd be interesting to try to establish which of these does the best on the most commonly used set of SVG features as judged by the same benchmark and/or a feature matrix derived from the documented caveats provided by some of these, but that does seem like a lot of work, and requires defining "most commonly used."

I feel like someone has to have a more or less complete SVG renderer, at minimum web browsers do. Maybe I'll shell out to a web view for this.