The curious case of SVGs and crashing Xcode

Recently, I had the opportunity to help a fellow developer troubleshoot an issue that had them stumped: SVGs were crashing Xcode 16 whenever they were accessed through the Assets folder.

If you’re a developer, you know how frustrating it can be when something that worked perfectly in one version suddenly breaks in the next, disrupting your workflow. This article documents my debugging journey and provides solutions for anyone facing similar problems.

The Problem

Brian, the developer, reached out on Reddit with a strange issue: after upgrading to Xcode 16, a handful of SVG assets in his weather app caused Xcode to crash as soon as the Asset catalog was accessed.

These same assets had worked flawlessly in earlier versions, like Xcode 14 and 15. The crash only became apparent after the upgrade to version 16.

Interestingly, just four out of 50 SVGs triggered the problem. At first, Brian thought the issue might be related to the filenames, which contained the word “sleet.” However, further investigation revealed that the filename wasn’t the culprit.

Even after regenerating the SVGs through Affinity Designer, the issue persisted. Was it the SVG format, metadata quirks, or some obscure rendering conflict? This was the puzzle I set out to solve.

Background

What piqued my interest about this issue was how something as fundamental as SVGs — a staple in many apps — could create such havoc. Given how important they are to development, especially since Apple's SFSymbols framework heavily relies on them, it was unusual to encounter such a failure in Xcode.

With my experience in SVGs, including the development of Charty for Docsify.js back in 2021, I was eager to dive into the problem.

Working on Charty required me to spend about eight months mastering the art of crafting, positioning, and programmatically coding SVGs to generate dynamic charts. Debugging this issue felt like a natural extension of my expertise.

Debugging the Issue

Verify Everything

Brian — if you’re reading this, I apologise — but one of the key lessons I’ve learned from years of supporting others with technical issues is not to take every initial report at face value.

It’s not about doubting anyone’s efforts; it’s about ensuring we're solving the actual problem.

That said, Brian was absolutely right: the SVGs were indeed crashing Xcode as soon as the files were accessed in the Asset catalog. But it’s critical when troubleshooting to align with everyone involved, verifying each detail along the way.

Miscommunication can lead you down the wrong path, wasting time chasing a phantom issue.

In debugging, the goal is to get on the same page quickly, confirming exactly what’s happening—otherwise, you risk solving the wrong problem and getting no closer to the solution.

Testing the SVGs Across Platforms

The next thing I did wasn’t even part of the official debugging process, but it gave me an important clue. All I wanted to do was view the test SVG Brian sent me. Interestingly, the SVG displayed perfectly on my iPhone (running iOS 18.0). This made me second-guess whether the SVG was faulty at all. If it worked fine on iOS and iPadOS, why would macOS — and specifically Xcode — be having issues?

I hit a twist: although the SVG rendered fine on the iOS Mail app, it caused the macOS Mail app to crash the moment I tried to open it. This pointed to a more nuanced issue, likely tied to how macOS and Xcode interpret SVGs differently than iOS.

At this point, it became clear that the problem wasn’t with how the SVG was built—Affinity Designer, the XML structure, or the SVG format alone weren’t the root causes. Instead, it seemed like the macOS rendering engine or the Xcode environment was stricter about SVG standards than iOS.

Apple vs developers

Now, I needed to determine if this was an issue with Apple’s frameworks or just Xcode being finicky. I’ve run into quirks with Apple frameworks before, particularly with PDFKit and Quartz, where Apple's rendering struggled with certain files while third-party SDKs like PSPDFKit handled them perfectly.

To rule out any obvious software issues, I tested the SVGs in several popular design apps:

• Adobe Illustrator: No issues
• Affinity Designer 2: No issues
• Sketch: No issues

This told me that the SVGs weren’t fundamentally flawed. Instead, the problem lay in how applications interpret them and how strictly they adhere to SVG standards—something Apple seems to enforce more rigorously in macOS and Xcode.

Manual investigation

Here’s something many people might not realise: an SVG isn’t just a graphic—it's essentially XML code, where coordinates and paths represent shapes on a canvas.

In contrast, opening a PNG file in a text editor just gives you gibberish (HTML encoded for displaying):

âPNG

IHDRfi¶µ1
©iCCPICC ProfileHâïóTìŸÄÔˇßá
Ññ:Ñfi§∑RB]:ÿI °Ñ*bC
WpEuEó™‡ZY"ämQ¨®ËÇ,
"Í∫XÀ˚ÅCÿ›wfi{ÁÕ9sÊ
ÀdÓËõ{œô@¶≤E¢4XÄta∂8
‹œìO«ç(eÄ⁄lNñ
àô≥ó˜w4moôOÁ˙
˜Ôˇ´
(pyY†0ÑπYútÑè#˙ä#gÄ:à
¯ıVdã¶˘¬T1“ ¬”ú<À
„”ú8√hÙLLd∏¬*‡Il∂8í>
‚ßÁpíë<$oÑ≠Ñ\Åa‰
3pKOœ‡"å‘∆Hå·È¸åƒ
ø‰I˛[ŒDiN6;Y ≥{ôº∑ Kî∆^
ı«ˇñÙ4…\
CDI|±8bi»ôıßfJYò:«ÓL¸
Û%˛QsÃ…Úäüc.€;P∫6-$héì
æ,iûlV‰Û≤|"ÊXú.≠ï$ˆb
Œ1[<_Wí%ıÛy,
i˛\~dÃÁ¢CÊ8+5"p>∆KÍK¬•
˝ÛÑ~ûÛu}•{Oœ˙À~,È⁄l~§ø
tÔÏ˘˛yBÊ|Œ¨Xio\û∑œ|Lî4^îÌ)
≠%Jì∆Û“¸§˛¨úÈ⁄l
‰BŒØ

But open an SVG, and you’ll see something much more structured and readable:

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <radialGradient id="edgeGradient" cx="50%" cy="20%" r="50%" fx="50%" fy="20%">
      <stop offset="0%" style="stop-color:blue; stop-opacity:0" />
      <stop offset="30%" style="stop-color:blue; stop-opacity:0.8" />
      <stop offset="70%" style="stop-color:blue; stop-opacity:0.3" />
      <stop offset="100%" style="stop-color:blue; stop-opacity:0" />
    </radialGradient>
  </defs>
  <circle cx="100" cy="100" r="80" fill="none" stroke="url(#edgeGradient)" stroke-width="20" />
</svg>

Because SVGs are readable code, I opened Brian’s problematic SVG in VSCode to dig into the source.

Luckily, he had also provided a working SVG created with the same tool (Affinity Designer), which made comparisons quick and easy.

Spotting the Embedded PNGs

One thing that stood out immediately was the presence of embedded data:image/png;base64, images within the problematic SVG.

While SVGs are meant to be scalable vectors, Brian’s SVG contained three embedded PNGs.

At first, this seemed odd—why embed raster images in a format designed for scalable graphics? But it made sense once I looked closer. These PNGs were being used to create an eclipse-like radial shadow effect inside a circle.

While standard SVGs allow for linear or radial gradients, achieving this specific shadow style required the embedded imagery.

Even though it was unconventional, this use of PNGs within SVGs wasn’t the direct cause of the crash. However, it did highlight that the SVGs were more complex than they first appeared, possibly complicating how Xcode handled them.

Path of Least Resistance

One thing you learn over time—perhaps best summarised by an ongoing developer joke—is that you’ll often build an elaborate, highly-engineered, automated system to water your plants... when you could just set a reminder and use a watering can manually.

Initially, I wanted to take the same approach: automate the debugging process, spit out a working solution, and impress Brian with a quick, effortless fix. But as I scanned the SVG’s source code, I decided to apply a tried-and-true technique: the 50% rule.

The idea is simple—take half the problematic code and run it. If that part works, try the other half. If that half fails, split it again and repeat the process until you pinpoint the offending code. It’s not the most sophisticated method, but it works.

And sure enough, in just a couple of minutes, I found the troublemaker. When I added the following section of the SVG, Xcode crashed instantly — just like before:

<g clip-path="url(#_clip3)">
  <g>
    <g>
      <clipPath id="_clip4">
        <rect x="1.394" y="1.035" width="134.5" height="91.354"/>
      </clipPath>
      <g clip-path="url(#_clip4)">
        <g id="_Image5_" serif:id="_Image5" transform="matrix(1.63162,0,0,1.63161,1.39384,1.03498)">
          <use id="_Image5_1" serif:id="_Image5" xlink:href="#_Image5" x="0" y="0" width="83px" height="56px"/>
        </g>
      </g>
    </g>
  </g>
  <defs>
    <image id="_Image5" width="83px" height="56px" xlink:href="data:image/png;base64,..."/>
  </defs>
</g>

At that point, I knew I was close. But what exactly was causing the issue? Was it the <image> tag? The sheer number of nested <g> elements? Or maybe something deeper in the encoding or metadata of the file?

This was the point where I realised the solution might not be as straightforward as it first appeared. But at least I had narrowed down the issue to a specific block of code. Now, it was time to dive deeper into the details and start testing hypotheses.

Finding a Solution

After isolating the problematic SVG block, I dove deeper into the source and started examining the attributes against official SVG specifications. The two attributes that caught my eye were serif:id and xlink:href.

• xlink:href: While still technically part of the SVG spec, it is deprecated. Current best practice is to use href instead.
• serif:id: This wasn’t in any official documentation — it turns out that it’s a custom namespace added by Affinity Designer, the software Brian used to create the SVGs.

The Real Issue: Duplicate IDs

When I stripped away unnecessary attributes and compared the IDs, I uncovered the root cause: duplicate IDs.

Unlike HTML, which allows duplicate IDs without crashing (though it can cause issues with functionality), SVG files follow XML rules, where every ID must be unique to prevent rendering conflicts.

The offending code included multiple instances of the same ID, violating XML’s unique identifier requirement:

<g id="_Image5_" serif:id="_Image5" transform="matrix(1.63162,0,0,1.63161,1.39384,1.03498)">
  <use id="_Image5_1" serif:id="_Image5" href="#_Image5" x="0" y="0" width="83px" height="56px"/>
</g>

Here, both id="_Image5_" and serif:id="_Image5" appeared multiple times, creating conflicts. While most browsers ignore unrecognised namespaces (like serif:), Xcode’s stricter XML parser treated it as a standard ID.

This caused the crash because the system couldn’t handle the duplicate identifiers properly.

Solution: Clean the Code

The fix was straightforward: remove or rename duplicate IDs. By replacing the unnecessary serif:id attributes, the SVG imported into Xcode without crashing:

<g id="_Image5_" transform="matrix(1.63162,0,0,1.63161,1.39384,1.03498)">
  <use id="_Image5_1" href="#_Image5" x="0" y="0" width="83px" height="56px"/>
</g>

Automating the Fix

Since manually fixing each SVG file would be time-consuming, I explored tools to automate the process:

• SVGOMG: A web-based SVG optimiser that cleans redundant code and aligns with SVG standards.
• ImageOptim: A Mac app that optimises images, including SVGs, for better compatibility.

Additionally, Adobe Illustrator and Sketch automatically rewrote the SVG code when resaving the files, though not perfectly. These editors did align the files more closely with SVG 2.0 standards, making them usable in Xcode.

One important note: embedded PNGs within the SVGs still caused scaling issues in Xcode, even though they looked fine in Finder and design apps. While these PNGs were used to create special gradient effects, it might be worth reconsidering their use in scalable vector graphics.

Alternative Solution: Switch to SFSymbols

Given that Brian’s app relied heavily on weather glyphs, I recommended exploring SFSymbols (or custom SFSymbols). This approach would offer several advantages:

• Dynamic Colour Changes: Adjust colours based on weather conditions without needing multiple assets.
• Built-in Light and Dark Mode Support: Seamless integration with iOS’s appearance settings.
• Reduced Asset Management: A single symbol can handle multiple styles, simplifying maintenance.

Apple’s SFSymbols library already includes many relevant icons, such as cloud.moon.rain.fill and cloud.heavyrain. Where needed, custom SFSymbols could fill any gaps, offering more flexibility than static SVGs.

Conclusion

Debugging SVG issues in Xcode can be challenging, especially with Apple’s stricter rendering rules. In this case, the issue boiled down to duplicate IDs and deprecated attributes, which Xcode 16 couldn't handle gracefully.

If you encounter similar problems, here’s a checklist to guide you:

• Ensure all ID attributes are unique.
• Replace xlink:href with href.
• Use tools like SVGOMG or ImageOptim to clean and optimise SVG files.
• Consider switching to SFSymbols if you need dynamic and scalable icons.

Special thanks to Brian for allowing me to share this journey. I hope this article helps others navigate similar SVG challenges. If you need help with debugging or SVG issues, feel free to reach out — I’m always happy to dive into technical problems and find solutions.