Recorded – watch the full episode on YouTube.
What do you often shake your head at when you look at UIKit application code?
Janina Kutyn: I think when I've really been a bit confused by why someone has done something is when people do a lot of layout passes without giving it much thought, like “set this property, boom, layout pass. Set this property, yeah, layout if needed.” Well, you didn't really need to do that for all of these.
When people think they're achieving readability by kind of putting everything into one place and forcing it all to run because they feel like that way they get deterministic results. But, in practice, what they've created is suboptimal code that's making more layout passes than it really needed to.
“When people think they're achieving readability by kind of putting everything into one place and forcing it all to run because they feel like that way they get deterministic results.”
Paul Hudson: Layout passes, I think, are so almost accidental that you didn't realize there was a cost to you doing this fairly small thing. And yet, it kind of happened anyway and you didn't even realize. You can't see on the screen it's happening, but it builds up.
It's like if it happens a little bit here, you don't really see that. Happens a little bit here, you don't really see that either. Do that enough times and it's like, well, my application is running a bit slow now. I'm not quite sure why. And it's a little thing here, a little thing here, a little thing here, just kind of building up, and building up and building up.
Janina Kutyn: Exactly. It's a bit of a death by a thousand cuts where you don't notice an issue initially, and then it really snowballs and can get away from you.
Paul Hudson: It really does. I have a comment from Vincent Groeneveld who says, “readability is kind of important though, so it depends.” And I think it depends is very, very commonly required in UIKit code because there is no real one way of doing things.
Certainly – and how can I phrase this gently? – the way Apple suggests in its sample code is often quite surprising. Let's put it that way. So, there's no one true way which we think we can all agree on.
Some folks do MVC. Some folks do MVVM. Some folks who are a bit confused do VIPER. We have coordinators. We have Elm. We have many, many options. So, it depends, I think is really, really critical.
“Performance doesn't mean different things to different people and I think readability is something you need to agree on within your team about what is readable to your entire team and what works for your team.”
Janina Kutyn: I completely agree that readability is super important, but readability means different things to different people.
Whereas performance doesn't mean different things to different people and I think readability is something you need to agree on within your team about what is readable to your entire team and what works for your team.
Paul Hudson: Well, hopefully via SwiftLint, so it stops becoming an argument and just gets resolved for you automatically, before you even hit the poll request stage!
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED Spend less time managing in-app purchase infrastructure so you can focus on building your app. RevenueCat gives everything you need to easily implement, manage, and analyze in-app purchases and subscriptions without managing servers or writing backend code.
Link copied to your pasteboard.