Display SVGs from URLs in React Native

[jatin-bhuva]

I’m running into a performance issue when displaying multiple remote SVGs (coming as URLs from the backend) inside a FlatList. Once I load around 20+ items, the Android app crashes — likely due to how react-native-svg renders SVGs.

From what I understand, the library parses the SVG XML into a hierarchy of React Native components (Path, Rect, etc.), which are then rendered in native code. That means each SVG is not treated as a single image, but as multiple native view elements.

I’m wondering — why does the library use this approach instead of rendering the SVG directly as a native image (similar to how handles PNGs or JPGs)?

Specifically:

Is there a technical reason we can’t just load and render the SVG as a single native image instead of parsing it into a React component tree?

Are there any plans or existing APIs in the library to support this more lightweight “native image” rendering path for remote SVGs?

Here’s a simplified example of what I’m doing:

import { SvgUri } from 'react-native-svg';
import { FlatList, View, Text } from 'react-native';

const MyList = ({ data }) => (
  <FlatList
    data={data}
    renderItem={({ item }) => (
      <View style={{ flexDirection: 'row', alignItems: 'center' }}>
        <SvgUri width={40} height={40} uri={item.iconUrl} />
        <Text>{item.title}</Text>
      </View>
    )}
    keyExtractor={item => item.id.toString()}
  />
);

I understand the current approach allows dynamic SVG manipulation (changing fills, strokes, etc.), but for simple “display-only” use cases, a native image rendering mode would be much more efficient — especially for lists.

Would love to know if this is by design or if there are any plans to support direct native rendering of SVGs from URLs.

2025-10-13 16:16:11.062  3956-3963  .test         com.test                   I  Clamp target GC heap from 215MB to 192MB
2025-10-13 16:16:11.062  3956-3963  .test         com.test                   I  Background concurrent mark compact GC freed 32KB AllocSpace bytes, 0(0B) LOS objects, 0% free, 191MB/192MB, paused 387us,2.653ms total 433.197ms
2025-10-13 16:16:11.062  3956-3964  .test         com.test                   I  WaitForGcToComplete blocked Alloc on Background for 433.504ms
2025-10-13 16:16:11.062  3956-4009  .test         com.test                   I  Waiting for a blocking GC Alloc
2025-10-13 16:16:11.063  3956-3956  .test         com.test                   I  Waiting for a blocking GC Alloc
2025-10-13 16:16:11.065  3956-3965  .test         com.test                   I  Waiting for a blocking GC Alloc
2025-10-13 16:16:11.847  3956-3963  .test         com.test                   I  Clamp target GC heap from 215MB to 192MB
2025-10-13 16:16:11.847  3956-3963  .test         com.test                   I  Background concurrent mark compact GC freed 32KB AllocSpace bytes, 0(0B) LOS objects, 0% free, 191MB/192MB, paused 616us,11.107ms total 784.942ms
2025-10-13 16:16:11.848  3956-4009  .test         com.test                   I  WaitForGcToComplete blocked Alloc on Background for 1.218s
2025-10-13 16:16:11.848  3956-3956  .test         com.test                   I  Waiting for a blocking GC Alloc
2025-10-13 16:16:11.848  3956-3965  .test         com.test                   I  WaitForGcToComplete blocked Alloc on Alloc for 783.104ms
2025-10-13 16:16:13.104  3956-4009  .test         com.test                   I  Clamp target GC heap from 215MB to 192MB
2025-10-13 16:16:13.104  3956-4009  .test         com.test                   I  Alloc concurrent mark compact GC freed 32KB AllocSpace bytes, 0(0B) LOS objects, 0% free, 191MB/192MB, paused 522us,3.555ms total 1.255s
2025-10-13 16:16:13.104  3956-3956  .test         com.test                   I  WaitForGcToComplete blocked Alloc on Alloc for 2.475s
2025-10-13 16:16:13.104  3956-3963  .test         com.test                   I  WaitForGcToComplete blocked Background on Alloc for 1.256s
2025-10-13 16:16:13.105  3956-4009  .test         com.test                   W  Throwing OutOfMemoryError "Failed to allocate a 16 byte allocation with 49664 free bytes and 48KB until OOM, target footprint 201326592, growth limit 201326592; giving up on allocation because <1% of heap free after GC." (VmSize 41277040 kB)
2025-10-13 16:16:13.146  3956-7125  .test         com.test                   I  Waiting for a blocking GC Alloc
2025-10-13 16:16:13.230  3956-4009  AndroidRuntime          com.test                   E  FATAL EXCEPTION: OkHttp Dispatcher
                                                                                                    Process: com.test, PID: 3956
                                                                                                    java.lang.OutOfMemoryError: Failed to allocate a 16 byte allocation with 49664 free bytes and 48KB until OOM, target footprint 201326592, growth limit 201326592; giving up on allocation because <1% of heap free after GC.
                                                                                                    	at okio.Buffer.readString(Buffer.kt:315)
                                                                                                    	at okio.Buffer.readUtf8(Buffer.kt:299)
                                                                                                    	at okhttp3.internal.ws.WebSocketReader.readMessageFrame(WebSocketReader.kt:245)
                                                                                                    	at okhttp3.internal.ws.WebSocketReader.processNextFrame(WebSocketReader.kt:106)
                                                                                                    	at okhttp3.internal.ws.RealWebSocket.loopReader(RealWebSocket.kt:293)
                                                                                                    	at okhttp3.internal.ws.RealWebSocket$connect$1.onResponse(RealWebSocket.kt:195)
                                                                                                    	at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
                                                                                                    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
                                                                                                    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:651)
                                                                                                    	at java.lang.Thread.run(Thread.java:1119)
2025-10-13 16:16:13.831  3956-4004  .test         com.test                   I  Waiting for a blocking GC Alloc
2025-10-13 16:16:13.969  3956-4009  Process                 com.test                   I  Sending signal. PID: 3956 SIG: 9

[Rishabh11200]

💬 Confirmation

I can confirm this issue — I’ve experienced the same behavior on a Samsung S24 Ultra (Android 16).

The app crashes once around 20+ remote SVGs are rendered simultaneously in a FlatList.

The crash log points to OutOfMemoryError in the heap during SVG parsing (exactly like in the logs above). Interestingly, the same code runs fine on a Pixel 6 Pro, which likely has a different memory handling strategy or GPU composition behavior.

---

🧩 Technical Analysis

From what I can tell, this happens because react-native-svg parses each SVG XML into a full React Native view hierarchy (<Path>, <Rect>, etc.) rather than rasterizing it once into a bitmap or GPU texture.

So, when many SVGs are displayed in a list, memory usage scales linearly with the number of SVG nodes — instead of staying roughly constant as it would with rasterized images.

For simple “display-only” use cases (no dynamic color or shape manipulation), it would be extremely helpful to have an option to render remote SVGs as native images — for example, by pre-rasterizing or caching them on the native side, similar to how <Image /> handles PNG or JPG.

---

📱 Device Behavior Summary

Device	OS	Result
Pixel 6 Pro	Android 16	✅ Works fine (no memory crash)
Samsung S24 Ultra	Android 16	❌ Crashes after ~20+ SVGs (OOM)

---

💡 Suggestion

Would be great to know if there are any plans for a lightweight rendering mode — e.g., a native image-based renderer for static SVGs — or if there’s a recommended caching/rasterization approach for large lists of remote SVGs.