Apple has been refining a new way to configure springs that's easier to understand and to work with. It uses just 2 parameters: duration and bounce. Increasing the duration makes the animation take longer. And increasing the bounce adds bounce to the animation. All of their frameworks that support springs will use them.

Being able to understand the math that's behind these curves helps make springs feel more approachable, but if math just makes your head spin, don't worry, it's completely optional. They’ve implemented all of this math for you.

You can call value to get the position of the spring. You just pass in a target, which is what the spring is moving towards, and the time you want to evaluate it at. You can also use the same inputs on a velocity method to evaluate the spring's velocity over time.

Hang == Delay. What kind of delay is acceptable depends on the circumstances.

For a discrete interaction, a delay below

To enable our UI elements to react “instantly”, it is vital to keep the main thread free from non-UI work.

Given that every update to a UI element needs some time on the main thread, and we want these updates to happen within 100 ms to feel real. Ideally, **no work on the main thread should take longer than 100 ms**. If you can be faster, even better. Long-running work on the main thread can also cause hitches.

Shortly, Xcode will install your app on device, but, it will not launch it. Instead, you will see an instrument template chooser on your screen. Choose “Time Profiler”. Time profiler is a good starting point if you don’t yet know what you are looking for and want to get a better understanding of what your app is doing.

It will create a new time profiler document, which includes time profiler and hangs profiler, both of which will be useful for addressing hangs.

Hit record button at the top-left of the tool bar. It will launch the configured application and start capturing data. And use you app as you normally would. Instruments will record all of your app’s data. Once you found the hang, hit the stop recording button in the toolbar. In this talk, he used Backyard Birds app to demonstrate hangs.

Instruments has also detected the hang. It measures the hang duration, and labels the corresponding intervals according to the severity. In this case, instruments shows us a “Server Hang” has happened (see above screenshot).

There are two main cases for an unresponsive main thread:

In order to identify the hang, first select the Backyard Birds on the left panel, tap the disclosure indicator to unfold all the threads, select main thread, then click to the ugly red area (hang-interval in the timeline) to show the context menu, hold option key and click “Set inspection range and zoom” (as shown in the above screenshot).

This zooms into the interval’s range and filters the data displayed in the detail view to the selected time range.

After you have done above two steps, it will filter out all functions from the system libraries, making it a lot easier for you to inspect just on your hanging code.

As you can see, the `BackgroundThumbnailView.body.getter` takes the longest. It is the Busy Main Thread problem. There are two potential scenarios to cause this hang.

How we should reduce the work on the main thread depends on which case we have.

For a long running function, we want to look at its implementation and its callees. We need to look further down.

Click the view body instrument and drag it into the document window to add it. We gotta record again.

You can see a lot of orange intervals all labelled BackgroundThumbnailView. This tells us precisely how many body executions there were and how long each one took. The orange color indicates that the runtime of that specific body execution took a little longer than what we are aiming for with SwiftUI. The bigger problem is how many intervals there are.

We can now address to that problematic code.

Let’s just use lazy VGrid to solve the issue.

Let’s profile the updated code.

We still have a micro-hang. Let’s profile it on our iPad.

We still experience the hang on iPad. That’s because now our screen is bigger and there’re a lot more thumbnails to be rendered. Instruments also recorded this hang (see in below screenshot). We see more BackgroundThumbnailView bodies again.

The same code performed mostly OK on an iPhone but was slow on an iPad, simply because the screen was bigger. This is one of the reasons why you should also fix micro hangs. Let’s find out what we can do to make each individual execution faster.

We seem to be computing a thumbnail on the fly here, which is quite time consuming. This is work we should rather be doing in the background and not keep the main thread busy with. To better understand what change we can make, let’s look at the context how the thumbnail getter is called.

And update our code to show progress view while loading the actual image.

Let’s try out the updated code. You will our progress indicators, and a few seconds later, our thumbnails were displayed.

This is the slightly different type of hangs. The way Instruments’ hang detection works is that it looks at all works items on the main thread and check whether they are too long. If so, it marks them as potential hang. Hang detection also detects these asynchronous or delayed cases, but it only measures the potential delay, not the actually experienced delay.

The problem (executing asynchronous task on main thread)

The solution

This should allow the “thumbnail” getter to execute on Swift Concurrency’s concurrent thread pool inside of the main thread. Let’s try it out again.

To determine whether a blocked thread is a responsiveness issue or not, look to the Hang instruments, not the thread states instruments. So a blocked main thread doesn’t imply an unresponsive main thread. High CPU usage also doesn’t imply that the main thread is unresponsive. If the main thread is unresponsive, that means it was either blocked or the main thread was busy.

Whatever work you are doing on the main thread, it should be done in less than 100ms to free the main thread for event handling again. The shorter the better. Determine whether the main thread is busy or blocked. Hangs can surface synchronously or asynchronously. Do less, move work to the background, sometimes, even both. measure first and check whether there is actually a hang before optimizing.

sessionFileContents = sessionFileContents.replacing(

"../../../images/notes/\(event.lowercased())/\(session.code)/\(imageFileName)",

)

}