HTML Parsing with NSAttributedString

When we decided to rewrite and redesign the orders list screen, we also wanted to use small pieces of html strings for some part of each order cell information we provide. This approach could give us little freedom to change colors, fonts, order statuses etc. dynamically. This means, we need to parse multiple html strings for every cell.

We started to face a few issues at that point, since the “every cell” is the important keyword here. As we used to configure table cells with mostly prepared data, we just pass the required data to cell classes, inside the cellForRow delegate method.

There are 3 important points to be considered, especially when parsing and displaying html data in cells.

Initial usage of NSAttributedString

At the very first call of NSAttributedString for parsing the html data, iOS is allocating a few threads, especially the JavaScriptCore and WebThread ones. This indicates that WebKit is just used to parse the html under the hood.

So it means WebKit and other necessary modules are building up which takes really a good amount of time.

Of course, the time spent for first parsing operation depends on the html string, but it can be up to 1 second for a mid-sized html. Apparently, it’s not possible to avoid it but at least we can keep it in mind to avoid blocking the application flow.

Thankfully, it just takes that much time and memory, just for the first time. When you try to parse another html data with NSAttributedString, it uses some sort of internal cache for consecutive calls and takes reasonable milliseconds (around 1/10 seconds of the initial call.)

Consecutive parsing calls

As we mentioned, consecutive parsing operations are also not so cheap. It could take around 0.02 second for each mid size html data. So this means if you try to parse the html in every cellForRow, it’s very likely to see some delay on scrolling actions.

For our specific case at the orders list screen, we fetch the orders by indicating the page size and number. Then we resolved the scrolling issue by parsing the HTML beforehand, right after the fetch is completed (also a loader icon is shown at that moment). And then store the NSAttributedString objects in ViewModels.

Main Thread is required

Since using NSAttributedString with NSHTMLTextDocumentType requires WebKit importer and is not a thread safe operation, it just needs to be run on the main thread. This brings another thing to keep in mind that every html parsing operation requires to block the main thread, or user interactions in other words. Depending on the amount of HTML data, it would make sense to consider this delay and tackle by showing a loader, or just splitting the html data if possible in your case.