SVG in iOS

In the past, we were using SVG files, but not anymore. The need for it was necessary as we were simulating Avatars changing closes and colouring them. What could fit better than SVG? We thought — “nothing”. In the end, SVG created for such things… But it was not like we imagine.

.

As SVG is not supported natively, we were forced to use some external libraries for our purposes. All of them works in one way — drawing SVG using UIContext and CGPath. Unfortunately, it’s not the fastest operation that exists. Even more, as it works with UI, it should be performed in the main thread, which means it blocks all other rendering processes. Probably it would work with one SVG on a screen, but the designer decided to have three Avatars at the same time. In the end, we got horrible lags and the nearly unusable app.

What could we do at this point? The decision was simple – let’s simulate SVG Layers changing functionality. Our main idea came from how this file works.

In simple words, the SVG file is an XML with some changes. To change component in the SVG file, we need to find the proper node and change it, or attribute of it – depends on your needs.

We thought — what if we build a system of nodes, just by layering UIImages one after the other.

First goes Avatar Body, then shoos, then pants and so on. When you need to change something, you are not parsing SVG file, but merely changing the UIImage value that represents needed peace. The logic remains the same as before when using SVG, but instead of changing an XML node in a single file, we’re changing full image. However, we just changed the clozes outline. Imagine that we need to change closes colour, or on SVG language – node attribute. Then one image is not enough.

We need one more UIImage that represents a colour piece. Changing it changes the colour of closes. Now we got that two images represented each simple piece — one for the outline and one for colour. If SVG depends on some other features that should be shown and changed, then it causes adding one more UIImage. Now we got that each simple separate close represented with several images. Each image was layered properly and was responsible for solving a single role(such as colour showing or outline closes).

Each close is encapsulated object of UIImages with a proper hierarchy. All of them encapsulated in a single avatar object. When you need to change a property of a specific item(such as), you firstly find an item through avatar API and then changing its values(colour, outline, etc). Under – it finds UIImage that represents specific property and changes it to the provided value.

In the end, when we built this interpreter, we got many benefits. It’s straightforward to work with its API, easy to understand, flexible to change. And the essential thing is — we removed those horrible lags.

What if you have something more custom then a dull colour or outline? Instead of using images, you can use a fully customizable view with gradients and all other fancy things. The main idea remains the same build your layers based on your needs, customize them etc. No need to use SVG and parse them. It’s resource-heavy and lagging. It’s hard to work with them. All passed SVG should have the same structure. I can continue with many more reasons, but I think you got the truth.