What happened to Alcatraz and Xcode Extensions?

Leo Dion (Host): [00:00:00] Hello, welcome to another episode of EmpowerApps Show today. We have with us René Cacheaux and Josh Berlin. Guys, thanks for coming on. 

René Cacheaux (Guest): [00:00:08] Thanks for having us. 

Josh Berlin (Guest): [00:00:09] Yeah.

Leo Dion (Host): [00:00:09] So I've heard a lot of issues that companies have with architecture especially architecture with iOS apps and I know you guys have a book coming out as part of the Ray Wenderlich series - IOS app architecture. So this is something I'm really interested [in]. Maybe if you can kind of define the problems you've seen a lot of companies run into when it comes to architecting a successful mobile app, especially in iOS. 

René Cacheaux (Guest): [00:00:40] Yeah, one of the biggest challenges with iOS development is that there's really no strong opinion from Apple. So everyone's really kind of left to roll their own patterns. The biggest issues that I've seen is just slow in-team velocity, because we read a lot more code than we write. Everytime that we go into a code base to add a new feature, fix a bug, or something - the more tightly coupled all the pieces of your app are [and] the more you have to read to kind of understand all the things that you need to understand to make a safe change without breaking something. And so, kind of architecture really helps speed up your team because if you can kind of use the right patterns and break things up into no easy to reason about chunks. It's much much easier to find where you need to make the change and have confidence that you are not going to break something. So that's what I would say kind of like the main points on that.

Josh Berlin (Guest): [00:01:39] Yeah and another thing is like a lot of apps that are built usually start with maybe like one person or a small team and  that developer has an opinion about how to architect the app and as a team grows and the product org wants more changes [it] becomes a lot harder to make those changes if the team isn't on board with one type of architecture and everyone is going to have their own opinion. It's going to be a lot easier to make these changes. If everyone agrees on one architecture and knows where to our find everything, everything is documented because one day when the team grows more, you know, you're going to potentially have more problems - like René was saying finding things in the code base. When the app is small it's not as big of a deal but when it grows it becomes a lot more challenging, so it's good to get these architectural patterns in early on and have everyone on board.

Leo Dion (Host): [00:02:36] Maybe talk a little bit about your background and how did you guys get into iOS development? 

René Cacheaux (Guest): [00:02:40] So I got into it back in around 2008. I was doing a bunch of kind of web Java server face, you know internal it development and my wife had bought an iPhone and was kind of really trying to get me on board with the Apple ecosystem. Back then I was kind of Microsoft guy. You know, I was like, I'll try developing for this it would be interesting and I just got hooked honestly like. Working with like very abstract things kind of in the cloud and kind of in the background versus working on something that you can kind of feel and touch and look and show your friends kind of a really really cool thing. That's how I got into it. 

Leo Dion (Host): [00:03:17] How about you Josh? 

Josh Berlin (Guest): [00:03:18] Yeah. So in college, it was like maybe 10 years ago and iOS first came out. No one was really teaching this in school and I wanted a fitness tracker. So I built one for myself and ended up getting a job at a company building business products for Windows. They wanted to Android and iOS app and somehow I got the job. I'm in a building iOS apps ever since then. 

Leo Dion (Host): [00:03:43] It's funny. So how big are the teams that you've worked with? 

René Cacheaux (Guest): [00:03:46] All kinds of ranges. I mean Josh and I used to work at a consultancy called Mutual Mobile. The kind of a big project that we work together on were kind of establish all this architecture stuff. We had a team about six iOS and about six Android but you know in that agency we had other projects that were like two on each platform - so anywhere between two and six on each platform when we were in which the mobile 

Leo Dion (Host): [00:04:10] It seems like one of the big things I'm hearing is as more and more code gets written there's almost use the term interesting use in terms of velocity and it is a specific term obviously the agile world, but I can understand what you mean you basically mean speed of the project and its movement but I would almost say like when you get more and more code. It becomes more and more difficult to manage and then on top of it. There's like an inertia there. The bigger it gets the heavier it gets and the harder it is to move it. It seems to me like what you're saying is like good architecture makes it much quicker and much easier to add more and more components to an app. Is that correct? 

René Cacheaux (Guest): [00:04:49] Yeah, the weird part about it though is to get to the point where you get those benefits. You do have to kind of slow down a little bit. And that's the part that most organizations struggle with is that they want that high-velocity upfront on day zero and you just can't get that. If you don't spend the time to work together as a team and really figure out the patterns that everyone's on board with and really kind of experiment a little bit and kind of lock it in. That's one thing that, the project that I worked with Josh on. You know, the first couple months it was a pretty slow process. I mean we had everyone in every code review. We experimented with the patterns that we were using and we were tweaking them and whatnot. And so at the very beginning, it really wasn't a high-velocity project probably slower than average. But then about three or four months into it, we started moving really really fast and we had a big deadline because this project was for a big brand, for the World Cup and we needed it by certain day and it was a pretty large scope project. And by the end of it the last about three four months of it, I mean we were moving super fast. Everyone was able to build features pretty quickly. I know Josh if you want to expand on any of that stuff. 

Josh Berlin (Guest): [00:06:05] I think we were pretty lucky to have those two to three months to really nail down the architecture we liked and to implement an architecture that would allow us after that like initial ramp-up period to build new features super super fast and not break everything because If we didn't have those first two months and we just started like writing code like building new features. I don't even know like everything probably would have crumbled because we didn't have a good foundation. So I think it's super important. Like maybe you don't need two to three months, but maybe even two to three weeks when you start a new project to really nail down the architecture and figure out how you're going to be able to build features quickly later on and test them.

Leo Dion (Host): [00:06:48] Do you think part of it is making sure somebody is there to enforce consistency or do you need like an architecture role set up for a team or what are ways that you can like foster that within a company?

Josh Berlin (Guest): [00:07:01] I don't think you need necessarily an architecture role, but I think that having meetings at the early stages of products about architecture is very important 

Leo Dion (Host): [00:07:13] And you're talking like highly technical meetings, right?

Josh Berlin (Guest): [00:07:15] Yes, very technical like a lot of diagrams like class diagrams how everything is going to fit together and like coming up with some patterns. So I don't think you need necessarily like someone who's an architect on the project. I mean it definitely would help but I think like just a team of four or five people could have these meetings and figure this stuff out early on.

Leo Dion (Host): [00:07:34] Do you need somebody to call the shots at all?

Josh Berlin (Guest): [00:07:37] I mean I think it's probably better if you have someone driving this and everyone just kind of like tuning their plan, but I don't think it's completely necessary. I mean as long as everyone and I think what's more important is everyone's in agreement and everyone feels that they can have input and they're not just like doing what this one person says.

Leo Dion (Host): [00:07:58] Yeah. I've been in situations like that where there's somebody who pretty much is it ordering everybody what to do as far as architecture? And yeah, it can be really difficult to be in situations like that.

René Cacheaux (Guest): [00:08:08] I think the DNA of the team has a lot to do with it. I've been on very different kinds of teams and in teams we have folks that are very like self-motivated. You don't really need someone calling the shots and other teams. I've been on their folks that you know, maybe you want some more guidance and so for those are actually wanting someone to call the shots. So I think it really depends on kind of the personality and makeup of each team. But it definitely helps to have at least someone driving and at least the best way it's worked I think is making sure that whoever is driving is very open-minded and is more interested in having decisions being made less than pushing their personal agenda what they personally think is the best architecture.

Leo Dion (Host): [00:08:51] I really like that. It's a really good point. So maybe you guys can get into a little bit of the nitty-gritty what are like the different styles or different patterns that people can implement especially when it comes to iOS apps and architecture. 

René Cacheaux (Guest): [00:09:06] So there's three main styles that we've kind of categorized most of the patterns into. The more traditional work all the MV patterns, which are like MVC and MVP and MVVM. 

Leo Dion (Host): [00:09:16] And so like Apple, obviously, they really push MVC. 

René Cacheaux (Guest): [00:09:20] Yes.

Leo Dion (Host): [00:09:21] If there's any pattern that they push usually MVC is one of their oldest and most steadfast patterns

René Cacheaux (Guest): [00:09:27] They push it a lot. You know, UIKit [and] Cocoa Touch is designed around that pattern. And so that's the pattern that you will fight the least with when you're working with cocoa touch. It's a good pattern and there's a lot of materials out their on folks that are trying to kind of demystify all the negative kind of vibes around. You see because you can do MVC very well. I think that's actually the main thing that we learned Josh and I working together is that it's not so much a matter of which pattern you use its how well you put it to practice and you can like take any pattern and do a horrible job of applying it. You can take any pattern and do a great job of applying it. Like Dave Delong who used to work at Apple. He's a big proponent of MVC has a lot of cool articles out there on hey MVC is not so bad you just, you know decompose your view controllers into smart controllers and you'll be fine. You don't have to do this whole in MVP thing to fix those problems. 

Josh Berlin (Guest): [00:10:19] Yeah, like everyone hates on MVC but like I think a lot of it is just like how you implement it. It's not so much that in VC is a bad pattern is just like kind of like a broad thing and there's a lot of ways to do it poorly and a lot of ways do it well.

Leo Dion (Host): [00:10:33] Yeah, we had Alex Bush on who does contract work for Uber and his big complaint was how MVC gets unwieldy with really really really large projects. And that's kind of what I've heard. I use MVC. I don't have really large projects that I feel uncomfortable still implementing it but I think one of the things I've seen especially novice developers do is they'll take a pattern like a specific design pattern and just use it to use it without understanding why they use it. Most of the time, design patterns, I feel like they end up growing out of an it like just based on my experience. I've experienced enough that patterns just a naturally develop in your code if you're already using a lot of other things like making sure that things only do one thing. I forgot what that's called or, you know having a healthy use of like protocols or interfaces that automatically creates healthy patterns that follow patterns that we've seen in various books and stuff. 

René Cacheaux (Guest): [00:11:33] Yeah, I experienced that exact same kind of sequence of events where like I first learned about design patterns and it was like a kid in a candy store. I was like, I want to use as many of these as I can and then it kind of dies down and then when you just start trying to solve the problems that are in front of you it's like you said that you'll end up using those patterns but not because you said oh I want to use the Observer pattern. It's more because oh you have these external signals coming from the outside coming into the view controller and you want to decouple the view controller from that - let me build an observer for that. 

Leo Dion (Host): [00:12:05] Yeah, and then you realize wait a second. This is an observer pattern. It's like how they naturally grow out of your code. 

René Cacheaux (Guest): [00:12:11] Yeah. Exactly. 

Josh Berlin (Guest): [00:12:12] Yeah. 

Leo Dion (Host): [00:12:12] What other patterns do you see used throughout iOS? 

Josh Berlin (Guest): [00:12:17] Yeah. I think they'll like the reactive pattern has been super hot lately.

Leo Dion (Host): [00:12:21] Yes. 

Josh Berlin (Guest): [00:12:22] Maybe it's not the best. Thing to do on iOS like to write all this reactive code actually at the company. I work for now when I started a year and a few months ago the app was using a lot of RX Swift. 

Leo Dion (Host): [00:12:34] And RX Swift is hot right now 

Josh Berlin (Guest): [00:12:36] It's very hot. It's very hot. And when I first started I was I know RX left and I know like how to write it but it's still like sometimes when you look at a new project with Rx Swift you're kind of just like it's hard to wrap your head around what's going on. It's kind of funny because now a year later we have no RX Swift in the project. We've moved completely away from reactive programming and I think that's more of like, it's just easier to understand sometimes when the whole team doesn't know our RX Swift. It's like well do we want to continue down this path teach everyone this new style this like new trendy hot style or you want to move to something more of like an MVC pattern where everyone's more familiar and it's maybe more readable for everybody. 

Leo Dion (Host): [00:13:18] I also feel like I don't like bringing in third-party libraries like necessarily fight against the grain of I'm not against that pattern specific. But if you're like, let's say for instance, you're doing react like Facebook. React JavaScript stuff, right? Okay, at least that follows that pattern you're not fighting against the grain because that's what the whole thing is set up for but iOS like you're fighting against Apple and their push for MVC and okay if that's what you want to do. That's fine. But if after you know WWDC things though, work out that way like you're dependent on the React Swift team to like keep up with it, which that's up to you. That's a risk you're have to be willing to take

René Cacheaux (Guest): [00:13:56] Again. Like I think that's where the team DNA kind of comes in and that's why I think that it's bad advice to say here's the one architecture that you should always use. It's really about looking at who you're working with because there's some folks that are really into that stuff. And so I've been in environments both very reactive in both not and. Direct trainer bring a reactive into a non reactive environment is really hard is really really hard. Like Josh said it's almost not worth it. The other thing I think that kind of popped in my mind while we're discussing this stuff was that I would bring in third-party libraries one of the things that I kind of don't like about RX whiffed is that it's a really big library and if you really think about the common use cases, you're probably only using about maybe 60% of the library maybe 50% So you're only using a portion of it, but you're paying all the binary costs in the weight that it brings in. I really wish they could break it down into like a core version of it or not, but. Bringing third party dependencies can be pretty bad or pretty heavy on your app. 

Leo Dion (Host): [00:14:57] Yeah, I kind of agree. So anything else you want to talk about as far as different styles. I know like dependency injection has been big, protocol oriented programming especially important in the Swift realm.

René Cacheaux (Guest): [00:15:11] Yeah, I mean that's Dependency Injection is kind of cool because it's kind of a universal concept that we've been able to apply to all the different patterns. So I think of Dependency Injection as kind of like the foundation of the architecture where you can put patterns on top of it and if there's one thing that you want to focus on getting a right, I think especially if you're trying to build for a large team or large set of teams dependency injections is really important to get and the thing there is Josh and I've done this several different ways as we were learning the pattern and using it in different environments and different teams different companies. We started writing everything by hand because with Dependency Injection, there are Frameworks and libraries that kind of help you follow the pattern and that's typically where everyone goes to is oh, let me find a library or framework that helps with dependency injection. We found that using those libraries hurts more than helps. We found that handwriting all your dependency injection containers is actually the easiest way to write code that's easy to understand. It's a little more painful. It's a little bit more boilerplate a little bit more boring work, but on the other side of that you get a code base that's much easier to read and understand and trace through that's my advice I would give to any iOS developer is sure like look at the frameworks and play around with them and use them at the end of the day. I would recommend starting with handwriting stuff. The key thing there is. To make sure you don't put everything in one container, you know break it up down into multiple containers. But if you do that, you'll find that it's much easier to manage or do you agree with that Josh? 

Josh Berlin (Guest): [00:16:41] Yeah hundred percent. I mean, I think you're going to do one thing to make your app architecture better. It's like. Use dependency injection and like René was saying D.I. Can go from very simple to very very very complicated. 

Leo Dion (Host): [00:16:55] I want to break down dependency injection because some folks might not know what exactly that means. I'm gonna try at what I do. So I learned dependency injection at my previous employer? It was like this is amazing. Now this allows for unit testing, easy plugins and stuff. We had talked before the recording about how like I used to be a C# developer interview. Castle Windsor for dependency injection, which is great because Castle Windsor, it can do all the reflections so I can like look up whatever the default implementation of a specific interfaces and automatically do that for you but then if you want to like use mocks, you can use mocks to unit test as well. And I miss some of that ability to do reflection, automate some of the ability to plug in certain classes. So the way I've done dependency injection is kind of employing the protocol oriented way of creating a protocol for almost everything and then having specific components. Like for instance I have a class that needs I think that turns a wheel. So I have a protocol for turning a wheel and then I'll have a specific implementation of that. And then that way the constructor for that thing that takes in the thing that turns the wheel can take in anything that turns the wheel it doesn't matter but then I have a default implementation that I use an app and then in my unit test I might have a mock one just to see you know that it works regardless of what gets plugged in. Is that kind of what we're talking about here? 

René Cacheaux (Guest): [00:18:19] Yeah, and we're talking about also like the resolution of these things. So like when you say okay, I want to create this object and this object has a dependency on three other objects that may be a conform to specific protocol how that instruction happens how the assembly of the dependency graph happens. That's where tools like swinge act and other kind of dependency injection frameworks help you out. But the thing that we found is that those tools use what's called runtime resolution. So when you say I want this object, like let's say I want this view controller and it depends on this networking thingy. And this database thingy when you say hey give me this view controller. It does the resolution at runtime it rather than compile time. So if for some reason you don't register how to create a network thingy or a database thingy, you won't find out until you run the app, which is kind of a more dangerous way of doing it. Whereas if you just handwrite your dependency containers that. Know how to create a view controller with it network thingy and database thingy. You'll find out at compile time. If you're not able to create a database object conforming this protocol and injecting into the constructor it just you know, we should won't compile which is great for a really big app where you have lots of different protocols and services and objects and a large dependency graph. You don't want to depend on having to run through all the runtime logic to expose any kind of missing dependencies there so.

Leo Dion (Host): [00:19:44] Yeah, that's what I feel like has been the big roadblock for me is the lack of like decent resolution frameworks to plug in. So I just end up, you know hard-coding in the app and taking defaults and things like that.

René Cacheaux (Guest): [00:19:57] Yeah, and that's exactly how we found it to be the most helpful. Yep. 

Josh Berlin (Guest): [00:20:00] I mean even doing it that way like you're still getting all the benefits of dependency injection where your Constructors take in interfaces like protocols and these classes become testable. Even though you're not using a framework or still getting all the benefits of DI doing it yourself by hand.

Leo Dion (Host): [00:20:18] Exactly. And then you know, when you do a unit test you can mock it you're not dependent on that specifically so you guys have had experience what other languages have you had experience developing. Sounds like René you've done some Java stuff. 

René Cacheaux (Guest): [00:20:30] Yeah, Java and JavaScript. I've done Kotlin, Objective-C, and Swift. Those are the main ones. 

Josh Berlin (Guest): [00:20:39] A couple years ago. I spent some time doing a reactive element the JavaScript. 

Leo Dion (Host): [00:20:45] Okay. 

Josh Berlin (Guest): [00:20:45] Yeah, I've done some Java before a little bit of Kotlin. 

Leo Dion (Host): [00:20:49] What have you found as what's unique as far as IOS app architecture? Would have been unique benefits that unique challenges that you've seen, you know with that and with the dev tools in general.

René Cacheaux (Guest): [00:21:02] That's good question. There's a lot of thoughts there that are running through my mind. So one of the things that I think is challenging is that Apple even though they do push MVC quite heavily and cocoa touch does kind of you know is designed with MVC in my they don't seem to have a very strong opinion about it at least not around tooling and things like that. Whereas like in the Android side Google's really into architecture these days and they're putting out like libraries that are all about just architecture. It kind of helped folks, you know, architect their apps. And so I think the platform having an opinion really helps because it allows people to kind of rally around that set of patterns or that sort of thing and build tooling libraries that kind of just work with it and like an IOS and Android you don't have to use those things, right, but if you want to move. It's a good default. Whereas an iOS we really don't have that. So that's I think a challenge. 

Leo Dion (Host): [00:21:55] It's funny you mention that because I'm doing a talk on multi-threaded like asynchronous development. I'm preparing for it. And one of the big libraries for Swift to do that is actually done by Google. Yeah, even though we have like Swift NIO by Apple, Google is even providing libraries for Swift developers. 

René Cacheaux (Guest): [00:22:14] Yeah, and I guess Swift is a huge a challenge right? Because it's a great language. It's moving so slowly. I mean you can pair it with something like Kotlin. We just have huge gaps in Swift like concurrency primitives that are not there and I'm calling you have things like her routines and things like that. It's just, you know Collins moving a lot faster than Swift. And so when you're doing both Android and iOS today's a weird time to be doing both because there's a lot lacking or not on the iOS side. It used to be the other way around.

Leo Dion (Host): [00:22:41] Yeah. I mean it almost seems like with Swift they've slowed down because they've placed a high priority on like ABI stability. I think now that they've gotten over that hurdle. It'll be interesting to see and we'll get into that like what they might come up with as far as development tools for iOS and maybe updates to Swift as a language. How about as far as like Xcode devtools? It seems like we're going in the same direction where it's just like Xcode. It's painful to do Swift development on sometimes like I'm glad we have some refactoring stuff but just like autocomplete sometimes it works. Sometimes it doesn't very cryptic messages from the compiler when we just aren't doing our generic protocols the right way that it wants us to. What other stuff have you run into?

Josh Berlin (Guest): [00:23:28] The error messages are kind of a tough. I think it's another reason to just make your apps as simple as possible. That's why I like sometimes using third-party libraries just makes all the error messages worse and it's harder to find bugs 

Leo Dion (Host): [00:23:42] It fixes one problem, but crazy three more. 

Josh Berlin (Guest): [00:23:44] Yeah. So like maybe you have like a really cool architecture and like you have one way data flow, you know, everything works properly, but when something breaks, it might be a lot harder to fix versus if you go a simple around simple architecture, you're kind of setting yourself up for success later on. So think like like Xcode has come a long way in the last 10 years, but you still have to fight it sometimes for sure. 

René Cacheaux (Guest): [00:24:09] It's definitely creaking any like the fact that they had a kind of rebuild the build system underneath it completely. I mean it really needs it have an overhaul. Yeah. 

Josh Berlin (Guest): [00:24:19] Yeah build times are pretty high.

Leo Dion (Host): [00:24:21] It's not as bad as iTunes, but still it needs help. 

Josh Berlin (Guest): [00:24:24] And the thing is like Google's just continuously improving their IDs and it kind of like makes me want to start doing more Android development not like I love iOS like that's my number one. It is I think interesting because they're doing so much with architecture and their build system is amazing. Right? So iOS developers can learn a lot from the Android platform. 

Leo Dion (Host): [00:24:46] Yeah, it's amazing to see like there are some really good tools out there that third parties have built like I'm just thinking I like Fastlane and see what you will about Cocoapods or Carthage, but they're essentially filling in the gap that Apple hasn't provide like hopefully Swift Package Management can fill a lot of that Gap like with dependencies, but still it's nice to see that at least there's a community out there filling in the gaps  that apple hasn't filled, right?

René Cacheaux (Guest): [00:25:13] It's strange though because you know apple is such a large organization with so much money. You know, I feel like if they really wanted to solve these problems. They probably could do a pretty good job and they are doing things like they acquired BuddyBuild and so we'll see what happens with that. But I still feel like there's so much more that they could do in terms of helping developers in the environments that they are in today because a lot of the tooling that Apple builds. Apple doesn't use themselves things like Interface Builder isn't that widely used I think in apple and so what happens is a lot of the stuff that Apple builds is not really tailored for large organizations or large teams building large apps. And so that's where the community has to kind of jump in and fill those gaps which you know, the community has a really good job of it. I feel like apple could do even better job of it given all the resources that they have, Hopefully 

Leo Dion (Host): [00:26:03] You speak about interface Builder. So let's get into it like especially with architecture. How do you deal with managing your UI, but keeping a healthy architecture. I'm a storyboard guy, but I'm by no means somebody who's going to like shove it down anybody's throat. I totally get how painful it can be especially working on a team when you have like merging you have to deal with some crap like that. But what are your recommendations or your personal styling?

René Cacheaux (Guest): [00:26:33] I would not recommend anyone use interface Builder especially in large teams. 

Leo Dion (Host): [00:26:37] Yes. 

René Cacheaux (Guest): [00:26:38] That's one of the strong opinions that I do have is mostly because with interface Builder. You don't have a source of Truth everything that you put in your storyboard or your nib file is subject to change by the code underneath it. And so when you're looking at the story board itself in your kind of tweaking the layouts and you're taking the constraints and stuff like that. There's nothing stopping the code underneath the completely changing that and so when there's bugs and stuff, sometimes it's really hard to figure out the root cause because you can't just look at the storyboard. That's not enough. You have to go to storyboard and you have to look at the code. So that's one of the things that Apple could fix that. The other thing around is if you use a storyboard still kind of the way that Apple suggest you use them with segues and stuff like that. We do end up coupling all your view controllers together and there are kind of acts around it to make it less so but they're still pretty hacky. The simplest example is just a navigation stack, right, you know, you have a navigation controller and you have your presenting like, you know a list of things and you tap on an item with segues you're going to have to instantiate the next view controller in that first view controller. Now your tightly coupling those two things. If you needed to reorganize the navigation path, you're gonna have to go in to touch all the view controllers and kind of remove things around. So those are like a couple of big things I would say there's other ones but they're the ones that up my mind 

Josh Berlin (Guest): [00:27:54] Also like Auto layout code is not that hard to write by hand. I think the initial ramp up time is pretty high. It takes a little bit to learn how to build constraints by hand.

Leo Dion (Host): [00:28:05] You're talking about like the visual format language?

Josh Berlin (Guest): [00:28:08] I'm just talking about like all the helper methods that Apple provides to create constraints and like constrained one view to another one in code 

Leo Dion (Host): [00:28:16] Interesting. Okay. 

René Cacheaux (Guest): [00:28:17] Yeah. They added like a new anchor API that makes it way easier 

Josh Berlin (Guest): [00:28:20] So nice. Yeah and like you can write it some helper methods around that stuff reading this in your view classes is really nice and it's really easy to look at a view and see how everything's laid out in code and the other thing is like simple views in Interface Builder. Maybe it's easier to build those using like like a storyboard or seeing the views like laid out on screen versus encode but once you start doing like animations and changing constraints that stuff is so much easier to write in code. 

René Cacheaux (Guest): [00:28:51] One thing you mention there Josh is I think a lot of folks don't use this enough where you can totally subclass uiview and do all your styling and layout in there as opposed to in a view controller. I still see a tons of you controllers with times of layout and styling code. I think that's one of the biggest complaints about not doing your UI and code is like, oh it blows my view controllers in your dad's all this layout and style code into my view controllers. And so. You know what I usually say is. Okay. Well, that's fine. Just subclass your route uiview do it all in there and that really nicely separates the viewcontroller kind of controlling logic from like the UI and a styling logic. 

Leo Dion (Host): [00:29:27] Yeah that goes back to the whole point about having healthy app architecture. Your view should not be in the controller like drawing your view should be in your view. That's what it's there for. 

René Cacheaux (Guest): [00:29:35] Exactly. 

Leo Dion (Host): [00:29:37] Cool. Well, thanks guys for coming on. So do you want to talk a little bit about your book that's coming out? 

René Cacheaux (Guest): [00:29:42] Yeah, definitely. So it's been lots of effort getting this book out. We've been working on it for I think about three years now, we're super excited about it. We really wanted to write something that was extremely pragmatic and something that would tackle all the real world scenarios of architecture. I think I've read a bunch of different architecture books that have come out and they're very theoretical they usually have very simple example code and so what we decided to do is to try to build out as much of a real app as we could possibly do and so what we did is we built basically an app that's kind of like an Uber app, but it's kind of fun. It's a kangaroos pick you up, so it's called Koober. And so yeah, you can hail a kangaroo 

Leo Dion (Host): [00:30:26] I started watching your YouTube video. You did a presentation on it, about Koober I loved it. Yeah, and I'll post a link to that as well.

René Cacheaux (Guest): [00:30:33] It was a lot of fun. We based it off of Uber. So we built as much of Uber as we possibly could and so we had to tackle some hard problems. We couldn't shy away from things like navigation. Or things like authentication tokens and authentication stuff. And so we tackled all of those things. So because of that we didn't cover that many architectures. I think we cover three but we cover them pretty deeply and so yeah, I mean that's a couple of things I'm excited about actually probably the thing I'm most excited about is Josh and I are working together last, you know, six or so years. We kind of came up with her own kind of architecture and the last chapter of the book kind of covers that and we're pretty excited about it. Hopefully the community will have a good response to it. And I'm sure Josh has lots of thoughts on it. 

Josh Berlin (Guest): [00:31:20] I'm excited to hear what people think about  elements. It's an architecture that we created a Mutual Mobile  a long time ago, and we really try to provide a set of useful. Architecture patterns that people can like pick and choose which ones they like and yeah, we're pretty excited to see what people think of that. 

Leo Dion (Host): [00:31:39] Awesome. The name of the book is Advanced IOS app architecture and you can find out right at Ray Wenderlich's site. I'll provide the link in the notes just to plug our podcast. We are at brightdigit on Twitter as well as Facebook and I just started Instagram so you should definitely check that out. And before we close out guys, I wanted to ask you maybe your top three or top two things. You're most looking forward to at WWDC this year.

Josh Berlin (Guest): [00:32:07] I know my number one. Definitely the Dark theme and I'm really excited to see what they do with seeming because that's something I've been working on at work lately is building a theming for our app and there's a lot of like third party theme libraries that are available right now. And I'm excited to see how Apple is going to do this.

Leo Dion (Host): [00:32:29] Yeah, I'm excited about that too. 

René Cacheaux (Guest): [00:32:31] Oh boy. I have things that I want that I don't think are going to happen if this is gonna happen if they're cool. Obviously, I did. My number one. Most realistic was Marzipan. Just seeing what that looks like. I think I'm most interested in seeing how much of the macOS stuff is exposed like things like Safari extensions and stuff like that. Things that I would like to have that probably I think might not happen. I'd love for them to present concurrency primitives for. Something like co-routines would be so awesome. It would be really really cool 

Leo Dion (Host): [00:33:02] I feel like that if they're gonna announce it like a Swift is open source. That's the thing. I'm thinking about Swift is open source. So if they're going to announce that they would announce it. I think that's gonna be a Swift 6 or 5.3 or 5.2 thing. I think is definitely on the radar but I doubt we're going to hear about it at WWDC. But yeah, I totally agree. We need a async await. We need some of that stuff. 

René Cacheaux (Guest): [00:33:24] So you never know but yeah, I don't expect it. Yeah, those are my two. 

Leo Dion (Host): [00:33:28] Yeah. I was just going to say going back. Like I wish they'd fix our Xcode. I wish they'd get some of that stuff fixed. I think Swift Package Manager should be integrated into Xcode and it shouldn't be so difficult. I've become a big fan of some of the server side stuff. I'd like to at least have some sort of plug. For like Swift NIO and all the different Vapor and all the Kitura and all those projects because I think they're missing a lot of that push that Apple could give it. I'm really interested to see and I've done an episode on it as Apple has moved more into services if we're going to see Apple do anything for developers when it comes to services. Are we going to see more robust like CloudKit or integration with that because we have Firebase right Firebase is elephant in the room. Like where's Apple and this. So anything else guys before we close out? 

René Cacheaux (Guest): [00:34:18] The only I would say is you reminded me of something what happened to Xcode Extensions, like nothing like it was gonna go somewhere. It wouldn't go anywhere yet. 

Leo Dion (Host): [00:34:26] Yeah. Yeah exactly 

Josh Berlin (Guest): [00:34:28] Alcatraz thing. Yeah. I've hardly ever used anything some cool stuff on there though. 

Leo Dion (Host): [00:34:33] And it seems like that stuff is really more developer tools. Just more robust developer tools. That's all I'm asking for but I am interested in Marzipan and how that's going to work out. I've done some mac development and it's not that bad but there's a lot of old old 

René Cacheaux (Guest): [00:34:47] it's painful. 

Leo Dion (Host): [00:34:49] It's old. That's my problem with it. It's very Objective-C focused. And so I think Marzipan will breathe some fresh air. But my worry is that we're going to get kind of how. Lot of lazy companies but take their iPhone apps and just make them really big on the iPad. I have a feeling it's going to be the same on the Mac, unfortunately. Yeah, cool where can folks get a hold of you as far as on social media. 

René Cacheaux (Guest): [00:35:14] I'm on Twitter. My handle is at rcacheatx. That's where I primarily am. 

Josh Berlin (Guest): [00:35:21] My Twitter handle is at jab2109

Leo Dion (Host): [00:35:25] So guys. Thanks again for coming on the show. It's been fantastic, and I would love to have you go again talking more about architecture and how it can help teams work out and expressing. Thanks, Leo.