Today we’re following up on that post to talk about the lessons we learned in the past 10 months, as well as the eventual changes we ended up making.
Finding the problem
When the week of WWDC came around, we scheduled our appointment with the WebKit team and arrived with test devices in hand, ready to show them our findings. In our meeting, we were very confident that we could demonstrate the performance issues, but what we didn’t expect was their response.
On macOS the security model enforced by the system is much looser than on iOS. A prime illustration of this is how you get apps on the two platforms. On macOS an app may come from the App Store, but it may also be downloaded from a developer’s website. On the other hand, iOS apps exclusively come from the App Store and downloading from a website isn’t an option.
Luckily, for developers in the same boat as us, there’s another way: WKWebView.
Migrating to WKWebView
func evaluateScript(String!) -> JSValue!
There are two major differences between the APIs, and they are both a result of WKWebView running in a separate process from the host app.
The first difference is in the return value. Notice how the JSContext version of the API simply returns a
JSValue. If you read our previous blog post you know that
Any?, Error? returned from the WKWebView API. Because it is running in a separate process with its own networking, and its own memory space, it returns an optional
Error and either a
Dictionary or an
After every major change in framework or technology, it’s always valuable to ask the question, “was it worth it?” With all the trade-offs noted above, it might be hard to believe that the move was worth it, but for the average customer, it definitely was. If you recall, document merges could take between 10 and 30 seconds for normal documents. After the transition to WKWebView, we noticed that depending on the operations needed to merge documents, the merges were between 10 and 15 times faster. It’s hard to overstate how big of an improvement that is for the end user. WKWebView took an operation that was so slow that users questioned whether the merge was stuck or not to something so fast and seamless that users rarely even notice anything is happening at all.
It’s that difference in user experience that’s really what all of this is about. When a user is using Lucidchart to get their job done, they shouldn’t need to worry about what the software is doing or how fast it is doing it. Good software hides all of its complexity and lets the user focus on the work that needs to be done. In the instance of document merges and the improvements that were made by migrating to WKWebView, I think we really met that standard and the team delivered a truly excellent experience.
Any help is appreciated!
Thanks! There isn’t much information on JSC in production so your two articles have been most helpful.