How fast is UIKit on modern iPhones?

Recorded April 24th 2020 – watch the full episode on YouTube.

In the world of the A13 CPU or A13Z in the new iPad Pro, how much of a problem really is layout when it comes to performance?

Janina Kutyn: Well, perhaps for iPhone 11 Pro Max, it isn’t a problem, but you have to think about what are you building your apps for.

For example, iOS 13 runs on iPhone 6s and that phone came out, I guess, almost five years ago now. It came out in 2015, I believe. So, that's a significantly slower machine than what you have now in your pocket.

“You have to think about what are you building your apps for.”

So, if you're building an app for iOS 13, people are running this app on iPhone 6s. Also, if you're supporting older versions of iOS, then there are many devices in which people are running these apps.

So, yeah, it might run perfectly on your current device, but there may be issues with older devices.

And in addition to that, if you kind of think of it also in a more futuristic way. If you're doing layouts in a way that's not the most performant, and if you're taking some shortcuts, but the current device is pretty good and it's letting you get away with these little things that you were doing sub-optimally, but everyone's doing these same things in their apps, and it's not really noticeable. So, everything looks pretty good.

“When I was working at Apple, we thought so much about performance. This is probably where my interest in performance started because there, the whole team, we all always thought about how can we make this app as performant as possible.”

But next year Apple comes out with an even better iPhone that's really fast. And yeah, you're getting a performance boost from this faster CPU or faster components, but Apple will have also optimized all of their apps.

So, their apps are going to look amazing. Their apps are going to run so smoothly, whereas if you haven't really optimized your code on your app, then compared to the system apps this is when it might become obvious if you have taken shortcuts somewhere. So, you're no longer taking advantage of the frame rate possible.

Paul Hudson: This has been a problem I think for a long time, potentially since iPhoneOS 1 and 2, which is that it's not just how good your app is standalone, it's how good your app is compared to the sort of yardstick of Apple's own stuff.

They're hitting ten of ten every time, great performance, great layout, great UX and so forth. And if you fall short from that, when people are expecting great stuff for their thousand dollar phone, it becomes noticeable. You feel it.

“There was definitely thought put into is this going to cause an extra layout pass? Is this necessary or is this not necessary? Why are we doing this? What is the better way to do it?”

Janina Kutyn: Yes, exactly. When I was working at Apple, we thought so much about performance. This is probably where my interest in performance started because there, the whole team, we all always thought about how can we make this app as performant as possible.

It wasn't really an afterthought like, oh, this app isn't running well, so let's optimize it later. It really kind of became a way of working.

I mean, we didn't really do silly optimizations that didn't make sense, but there was definitely thought put into is this going to cause an extra layout pass? Is this necessary or is this not necessary? Why are we doing this? What is the better way to do it?

So, I think so much care goes into every single system app that if your app didn't get the same level of care, the users will notice.

Paul Hudson: Right. But, with Apple, I think you worked on Apple Music, is that right? So, with Apple, with Music, presumably you always shipped on the latest, greatest iOS. That whatever code you wrote, you wouldn't then back port to iOS 12 presumably, or iOS 11, 10, 9, or whatever it was at the time, you'd always sort of ship the current release, presumably.

Janina Kutyn: Yes, exactly. We did do that.

Paul Hudson: So, you were able to target the latest, greatest iPhones, but you planned ahead and thought, no, we should also make this work great on slower devices.

Janina Kutyn: Right. And also we need to make sure that when a new device comes out that is able to be really fast, that our app doesn't have any sort of performance issues and that the software's performing as well as the hardware allows it.

“It's really about the mindset and the whole system. How is my app going to look on any device that the user has in their hand?”

Paul Hudson: Yeah. I think the interesting thing about performance these days is that it's not quite so predictable as it once was.

Think about the earliest iPad, running iOS 3.2. You had this big glass screen and when your app was running that glass screen was your app. The entire device was your app and that's what made the iPad so amazing. Your code was full screen, like it was custom designed for you, but now you have split-screen, and slide over and other apps running at the same time as you, and you're now both actively competing for resources.

There's background refresh happening, with lots of system tasks happening, with iCloud sync and similar happening. There's all sorts of other background work, which often runs at the same priority as you. Like two split-screen apps – they both have priority to run in the foreground.

So, if you think about your code, yeah, it works great when it's full screen. But, what about when it's running next to a resource-intensive app? Is there some headroom in there in your code to run in that kind of way?

Janina Kutyn: Yeah, exactly. So, it's really about the mindset and the whole system. How is my app going to look on any device that the user has in their hand?

Paul Hudson: How much of an impact on performance does Auto Layout have?

Janina Kutyn: Well, it's true. I think it doesn't come as a surprise that layout performed by Auto Layout with constraints is significantly slower than manually setting a frame because of the way that Auto Layout works – there's a solver and every constraint that is applied to a view goes into the solver to create a complex equation.

“When iOS 12 came out, that was the release that was very famous for all of its performance optimizations and that Auto Layout was a lot faster.”

The more constraints are added, the more complex this equation becomes, maybe even exponentially, and even the order in which the constraints are added can have impact on performance. So, of course, it is no surprise that Auto Layout is significantly slower.

At one point, I measured this and when I did, I found that for applying constraints to a simple view, just a box, it was about seven times slower for iOS 11.

And then, of course, when iOS 12 came out, that was the release that was very famous for all of its performance optimizations and that Auto Layout was a lot faster. And indeed, it was.

But, for something like a simple view that's being pinned, it was still about 3-3.5 times slower to do it with Auto Layout than it was to just assign a frame directly.

Now, that said, it's still very fast. It's just slower than manual layout. So, that doesn't mean throw out Auto Layout, throw out all constraints and start doing frames manually.

But, if you're using a lot of Auto Layout and you're having a lot of issues, maybe that's the place to take a look.

Paul Hudson: So, for example, in my head, I'm thinking already, well, if I have a collection view with grid cells or table view cells, and I'm scrolling through them briskly, that feels like a place where Auto Layout might struggle slightly more.

Janina Kutyn: Exactly. So, your cells might not be affected, but they also could be. If you are performing a lot of layout as the scrolling animation happens, then you could get in trouble with that.

If your cells have a lot of subviews are very heavy, and subviews and positioning and a lot of computations are going into where things are, then that's something that may take a little bit of time for the setup of the cell.

Paul Hudson: So, when there's things stacked horizontally or vertically, but also in terms of depth if there's subview, subview, subview, and layers and so forth, there's all sorts going on there.

Sponsor Hacking with Swift and reach the world's largest Swift community!