What are the best tools and techniques for large iOS projects?

Recorded January 15th 2021 – watch the full episode on YouTube.

You have worked for some major iOS teams, including just recently Netflix. What tools, techniques, and architectural choices have you made that you found particularly useful for these large, complex, and very important projects?‌

Mayuko Inoue: I feel like most of the iOS projects that I've worked on has been fairly large with the exception of maybe Patreon, just because when I joined, it was a two-year-old code base, versus Netflix, which has been around for a while and millions of people use it. There are a lot more iOS engineers. I have this ethos around coding and software development that it's the “keep it simple” method – that’s always the best to start. There's no point in over-complicating things from the get go. You never want to over-engineer things because number one, it takes a lot of time, and number two, it takes a lot of resources. Why spend effort if you can do that same amount for less?

So, yeah, I think in every code base that I've been the things that I've always been amazed by is in the complexity, finding the simplicity, because the simplicity helps in both. It just helps in many, many different ways. Being able to understand the code base without needing to study it for months on end, I think is an important thing because the world changes and the product changes and everything else is changing.

"Being able to onboard new developers to a code base where there isn't a high learning curve or anything I think is invaluable."

I feel like it's just a lot of mental labor just to be in the code base. And then I think there's something to be said also of just being able to work on a team, collaborate efficiently, having everyone be aligned with what's going on in the code base.

Obviously no code base or architecture is ever perfect. That's what we all strive for, but is there ever actually a perfect architecture code base? Probably not. Trying to aim for that, and then not making it extra hard for yourself, I think is important. Being able to onboard new developers to a code base where there isn't a high learning curve or anything I think is invaluable.

But at the same time there is a place for really state of the art ideas and architectures and work. And I think that happens more at an industry level of just being able to move as a whole, towards a certain type of programming. I think we're seeing that with SwiftUI in our community. That's something that React has been doing for years, but we're moving towards it as a whole.

"Do your best and try to make it the best you can be. I think coding should be fun. So there's definitely room for creativity, obviously."

So three or four years ago we were talking about that kind of programming, we were like, this makes no sense because it's so different from what we're used to. But now that we're in 2020, we're like, yeah, this is a thing that we were all talking about and thinking about, and this is obviously the way forward that we want to go with. And so, yeah, go with the flow, keep it simple!

Paul Hudson: Just chill out, man. Take it easy.

Mayuko Inoue: Just chill out. You try to make something good. Do your best and try to make it the best you can. I think coding should be fun. So there's definitely room for creativity, obviously. I feel like I've been burned so many times by architectures and patterns that are complex just to be complex, and I just don't really see that being, overall, adding as a good thing, positive impact in the end sometimes. And so, yeah, I don't know.

Paul Hudson: I think iOS, and perhaps since the advent of Swift a few years ago, has had a real flourishing of architectural thinking and approaches to building software. And so much of that really, really belongs on the stage at a conference as opposed to in someone's code base. Because you can get up there and feel brilliant thinking your architecture is fantastic, but I've got a ton of actual commercially important tasks to implement, plus bugs to work on. Oh, plus there's a new iPhone out with a different screen size. Plus there's a new iOS version with new bugs inside it.

I'm not going to think about re-architecting my code completely just to fit in with what's shiny and latest and greatest. It's very, very hard. I know the urge is there – you want to be one of the cool kids. When someone asks what architecture you use, you kind of want to say “oh, I use this fancy clever-pants thing over here.” But you can't because you've got an actual job to do, actual work shipping software. So it's a real trade-off, right?

"I think for me, I have this ethos around coding and software development that it's the, keep it simple method, I feel like is always the best to start with."

Mayuko Inoue: It is. It's such a hard balance to achieve because I feel like most of the time, and maybe this is just me, I like being busy at work, but I always feel like there's always too much to do as a software developer, especially as an iOS development. Not only are you building the things, you're most likely educating people about how mobile development works. You're also doing the whole apps review process, which adds so much more compared to other technologies out there.

You always have this trade-off of actually shipping things out into the world that help the business, that help people do whatever they want. But then also you still also want to learn how other people are doing it and try out new things and see what other solutions are out there, as well.

"We say the technology changes overnight and some dude in a garage is making something world changing, but like everything else in the world, it takes time for this stuff to really make a difference."

But it's a really hard balance to achieve. And I feel like some folks lean more towards the really, let's think of the next big thing in architecture and stuff. And like you said, I think those are the talks that belong at conferences because change takes a while to set it in. So even if they think of something that is state of the art and cool, it takes a while for the developer community to really think about it, move on it, make it better, improvements.

I mean, I feel like Swift has gone through that whole thing of just when we saw it we're like, cool. Swift is cool. Then we went from Swift 2 to Swift 3 and we're like, Swift kind of sucks. Now that we're at 5 or 6, we're like, okay, yeah, no, this is good. This is great. Lot of community feedback has gotten in. It's really stable now, and the tooling is there. It's good. But it's taken about this long for us to be like, yes, this is a thing that we like, and we're going to go with it forever. So, yes, we say the technology changes overnight and some dude in a garage is making something world changing, but like everything else in the world, it takes time for this stuff to really make a difference.

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