Leo Dion (host): Thank you for joining me for another episode at Empower Apps. Today I'm joined by Tjeerd in 't Veen. Tjeerd. Thank you so much for coming on. Tjeerd in 't Veen (guest): Yeah, thank you so much for having me. Really excited to be here. Leo Dion (host): Yeah. Before we begin, I'll let you introduce yourself. Tjeerd in 't Veen (guest): Okay. Yeah, so my name is Tjeerd. You may know me from maybe writing Swift in depth.
I've been working at Twitter for the last year, which circumstances change most people may know. And before that I also worked at i g for five years, but I helped scale up quite a substantial code base. So yeah, been Swift, developed iOS developer for, since iOS 4, I think. So kinda Leo Dion (host): while. Nice. That's a, that's a long history. So today we're gonna be talking about a book you're working on. You wanna talk about what that book is and yeah. Why people should be interested.
Yeah, Tjeerd in 't Veen (guest): so it's, it's kind of interesting cause so I'm writing mobile system design but it's more I, I guess a contemporary topic because nowadays people are honestly quite, quite a bunch of layoffs and people are are applying to jobs and and they really associated it.
With interviews, but, but what I find interesting is if you ask someone what mobile system design is, they kind of go like, yeah, maybe it's about a modular app, or it's, some say it's about interviews and some say it's about like UI flows or any type of answer. But what. What I think you see a lot is like, it's usually backend associated, right? Like if you think about mobile or if you think about system design, you think about backend, like, like the backend interview process.
But I feel like, what about mobile itself? Like I know the joke is we just make JSON apps, we rendered them in some scroll view, but like if you take a serious app, that's totally not the case. You have like view like thousands of little decisions you're making just to make features, to keep adding features, like abstractions, et cetera. So I figured like, yeah, like mobile system designer would be nice to write. I have been writing before, so I'm just taking a step at it.
Leo Dion (host): Yeah. So can I describe exactly what you mean by mobile systems design? Like, yeah. Are we talk, are we talking UI design? What do we mean by system? Like kind of break that down. Leo Dion (host): Yeah. So, Tjeerd in 't Veen (guest): Well, the fun part is it's not really defined, so I'm just trying to defy it, right?
Like, like if you, if you look at the dictionary, maybe you can find something, but well, how I look at mobile assistant design is You have, you get like a requirement, something to make as a mobile developer, right? We make things obviously but how you approach that can be, can be well varied, right?
Some person just goes straight into UI and just makes stuff and makes it work and another person thinks about maybe all the sks and draws the diagrams and like thinks about like all the domains that are happening. So, When I think about mobile system design, I think about like receiving the specs and requirements and coming up with some sort of system like, like, yeah, almost like in a graph way. Like what is needed to make these requirements work. So let's say, let's take an example.
For example let's say someone asks Hey, can you make a video upload? One person may think like, oh yeah, I'm just gonna, this may seem fair ui, right? Right. They may think I'm gonna grab the photo picker and fill it on video and then I click and then we'll upload. But another person may think, you know, video upload videos they're large files, so they need to be stored.
They need to be uploaded in a, it's gonna take a long time cause they're large files, so maybe we need to chunk them whatever the app is, backgrounded so they can think more maybe in these edge cases and all these. Constraints. And I think that's more what I'm leaning to with mobile design is like you get like a requirement and like a thing that needs to be made and you. Figure out all the parts that are needed and also all the problems you may hit.
Also working with your team, like like how does it work for backend and what do they need? So for your, for your feature to work and, and so on. So I think it's maybe a long answer, but I feel like that's kinda where it goes. Right. And sort of the domain times. Leo Dion (host): Well, that's what I found really interesting about the book is one of the things you really tackle is asking the right questions. Because I feel like. That's a real difficulty.
I think you use, used the line like, so there's, there's known, known unknowns and then there's unknown unknowns and that's like the, one of the bigger challenges with designing a mobile app. Right. Yeah. Yeah. Tjeerd in 't Veen (guest): Like if you receive a feature, usually as a mobile developer, you get them by getting UI designs.
And I think the, the real power there is to really dive deep because if you ask the right questions, you can maybe even skip a couple spins of work cause you may already tackle on some problems. So, yeah, like you said there, like known unknown. Like, like, I know, I don't know yet how I'm gonna make this. I dunno, back in call or I know, I don't know yet how I will have to cash this data, but I know I have to. And then there are, like you said, the unknown unknowns.
Like Yeah. Like I'm gonna hit more issues or maybe not. And, and I'm, I have to keep that into account. And, and it's about asking proper questions to sort of uncover those during the briefing already. Yeah. Leo Dion (host): So like, what, what do you think is a good way to like, make sure you ask those right questions before it's too late?
Tjeerd in 't Veen (guest): Yeah, so for a couple ways you can do with this, I think one thing I like to do is sort of try to break the feature and like, there's maybe like a negative view, but like, like thinking like like what can I do to make this feature? Go bad. Like, like so yeah, let's take an example. Let's take again, again this video uploader, right?
Like if I, if someone gives me screens and says, here, make this video uploader, I'm gonna, you know, open SwiftUI and I'm gonna make a video uploader screen like you are gonna hit some problems later on. Cause like, video uploading is this own kind of beast. So it's about figuring out, like going through the motions. Like, okay, just pretending like I have the feature working. How would that look like? I have No, no, I. Think about like where does the data go?
What kind of data models do I need? But how does that reflect in ui? Is the video, for example, on my device? And if not, well that maybe needs to be downloaded. Maybe the designer didn't think about that first. Maybe they think the videos are available. Right? So it's about. Asking those kind of questions and going through the feature and trying to find those kind of pitfalls.
Because if, let's say the designer did not think about, like the video needs to be downloaded first and you figured it out, like you, you can already get the designer started on iterating their design while you are already working all the things. So you may save maybe a week of work. Cause maybe if you do it later, You're like, oh crap, the videos are not downloaded. Well then now the design has to work more late in the process and maybe you not delay the project. So, right.
So yeah, it's about finding those problems. Leo Dion (host): One thing I wanna talk about and especially this could be the case with video uploading is error handling. . Some like designers think that the app is gonna work all the time, but with video uploading, that's as somebody who's uploaded tons of video, trust me, like you, oh, the upload quit in the middle, or you lost internet connection or the, the video coding. Is it right for what the service is expecting?
I mean, there's like tons of issues we can run into that just happen in the real world. How can, how can you best address those issues, both for yourself, but also something that the UI designer should consider? Tjeerd in 't Veen (guest): Yeah, so air handling is a very deep topic. It can go from the ones in zeros all the way to the customer ui facing errors.
I think from a designer perspective, I. You're more in the realm of customer facing ui, so like errors that cannot be handled by the app and you have to present something to the customer for them to take action or from them. I think it's good to think about like what kind of things can go wrong with errors. A couple things. So. Like, you have to think about like, what kind of errors are customers gonna see? How can they recover? Can they recover? But also maybe, what about partial errors?
Let's say you have a screen that needs to fetch four types of data to populate the screen. What if we go three of those API goes go, well, one doesn't. We can be lazy and just throw up an alert. Okay. But we can maybe make it more like nice where each component has its own little. Error message option in there. So it's more embedded. Yeah. And, and that may make the component more reusable as well. You can maybe put it somewhere else and handles it can maybe show errors better.
So I think it's good to think about like how your data loads, if it's going go gonna be one package or piecemeal pieces and how the customer can, or your a user can. I think there are already good starting points other than more, just more than just show alert. I think that's the easy way, . Yeah. Leo Dion (host): Right, right, right. Yeah. That's a, that's a good, that's a good way. Like just ha having a way that the user can actually recover from that error or retry or whatever it is.
Yeah. Stuff like that. Yeah. Yeah. Are there ways that a UI design possibly could be misleading and maybe also like, Well, let's, let's address that one first before I jump into the next question, but yeah. How, how could UI designs be misleading? Cuz that's something you talk about in the book. Tjeerd in 't Veen (guest): Yeah. So a lot of people also wonder sometimes, like is the design the truth? Like if I get designed is do I make this pixel perfect?
I know I'm gonna be on a touch subject here, but like if you think about like, especially nowadays, maybe not so much. When I started, I was, iOS 4 but nowadays you have so many variations with screens, right? If time, dark mode, accessibility left to right, right to left. Like, like when the designer gives you a screen, That's not really always the screen. Like you can make it pixel perfect in the sense of. You know, you, you make sure the colors are correct and the boards all it's correct.
But the side I I, I see a screen way more as a as a thing that is very dynamic nowadays, right? And, and, and designer cannot give you 12,000 variations, be like all the dynamic phone size times, all the dark mode times, all the themes, times, whatever. So I think it makes sense to, to figure out with.
I guess the, the clue, the, the part of the story is to really work with a designer to figure out what is really important and figure out what is sort of set in stone, like certain margins and certain mm-hmm. Colors and themes and what things are sort of like, Open for interpretation and for variation. So, I dunno, XE have like a, a large device to test on, but the next person may have a smaller iPhone. For example, the xe may wanna do another round for just those devices.
Like, so I guess it comes down to really figure out like what is really important for them, for the company. And not take a design as sort of the the truth because there is no one design. And yes, you can scale up the designs in some tools. You can scale up so you can see how everything stretches, but it's still not, for example large font size with battery left and I don't know, custom layout. So you're still missing some versions. So, yeah.
More Leo Dion (host): closely, I guess , I'm just thinking like if you've been doing this since iOS seven when, or iOS 4 like. the amount of devices. I just re I was thinking the other day about like size classes. Remember Size classes? Yeah. Yeah. Like we don't, like now we're SwiftUI. I, we barely talk about that. But like that was a big deal when they added that because like they had all these new phone sizes and iPad Yeah. And all that stuff.
So yeah, it's, and the accessibility stuff you talk about. So one of the things you mentioned in the book that I have not, I'm not against them but I've found them to kind of be abused a lot in the enterprise. And you're a big fan of is diagrams. Do you want to talk about how maybe diagrams, like kind of in your opinion, fixes a lot of the issues with misleading UI designs?
Tjeerd in 't Veen (guest): So you mean like diagrams in terms of the landscapes drawing out the components needed or mm-hmm. , yeah. Leo Dion (host): Yeah. You had, yeah. You have some really good stuff in the book too, like you're talking about, okay, this is the data flow and this like, yeah. I, I guess I'll just get into it. Like, my, my problem with the diagrams is they kind of, they, they can be misleading to in how they might show. How we, we know exactly how this app is gonna work.
Yeah. But then when you actually get into it, it's like, oh yeah, we had this one thing. Now we have to change this whole diagram. Yeah. to me sometimes, like diagrams add more work than help, but you have some really good stuff in the book talking about how diagrams can actually be helpful. So, Tjeerd in 't Veen (guest): So first of all, first yeah, I'm using the diagrams in the book for, for the book itself, right? It doesn't mean whenever I'm opening code I op I'm drawing diagrams.
But I do think, I do think they're definitely a design tool for teams to align on what needs to be built. If, if you sort of, let's say you have a team, of five iOS developers or whatever developers, they, they have to make something. you can talk about what you need, but you can also draw it on and diagram could just be even a, a little post note with a little a pencil sketch. Mm-hmm. just to get people online.
So because there's a lot of risk of miscommunication, I think, when you work with people. Like everyone thinks they know what they know, but actually they don't. Yeah. And, and they may and, and that. And it's good to know what people are working on, what diagrams don't really capture the details. I think this may be the, the problem because I can draw in a diagram. I can let's go back to the video uploads just for consistency.
Let's, I can draw like, like a data chunker and like a background upload and I can draw it in the diagram. Mm-hmm. . But it's, The program, there's a lot of details missing, right? But I can at least align with someone, like what are they gonna work on? What am I gonna work on? Right? Right. But how to do it is sort of yeah. Fair platform specific, which is kind of like how I see it at least is there's room for interpretation.
How we may agree, someone makes a video uploader and someone makes the ui, but how you do it is maybe outside of diamond, a diagram scope. Leo Dion (host): Yeah. Yeah. Yeah. So, I mean, it sounds to me like you think the big plus with diagrams, and I totally agree, is probably like communication across like when you have more than like maybe like three people.
I think a diagram, and like you said, it could be a post-it note and it is also, it sounds to me like the diagram is Temporary, I guess would be a good way to put it. It's not, it's not something right in stone. And then it's like, okay, it goes into the documentation and it's forever there where Yeah, it's not in stone. Sometimes it can Tjeerd in 't Veen (guest): be.
So, so I've been in projects where we had like tech, tech documentation where you actually there was like a, a complicated flow and this diagram was really like great because it was sort of the communication tool to decide when data is loaded and uploaded. Oh, yeah, yeah. Yeah. So it sort of was like a source of truth in communication, but depends. A company. Leo Dion (host): Yeah.
Yeah. Yeah. And that I think makes a total total sense when you have a big team and not, you know, just, just in case you're ever wondering, nobody stays at a company forever. So if you're gonna pass that information down, like it's a good opportunity there. Tjeerd in 't Veen (guest): Yeah, of course. The hard part of the documentation is keeping it in. Right. Yeah, Leo Dion (host): yeah, yeah.
With a lot of larger companies, what are like some of the best ways that mobile, web, whatever, honestly, can align, especially with the backend team and making sure that they get what they need, but also like the, the front end teams understand like, what, why mobile is doing things the way they do, if that makes sense. Tjeerd in 't Veen (guest): Yeah. So may maybe is good like talking to like an in terms of example Leo Dion (host): as, for example, on video uploader, let's do video.
Yeah, let's take the video. Uploader. . Tjeerd in 't Veen (guest): That's a great iactually. It's a great point. So video uploading, let's say you wanna do like a background uploading thing, right? Cause you have to video. That means you need some sort of way to, to chunk of data, right? And, and upload it. So yeah. So when working with backend, I think there's a couple things I. One thing you wanna focus on, I would say is getting to the integration as fast as possible.
Because I think with integration, I mean making actual API calls. And I know that's kind of like the whole world of mobile, like how to make API call. But I do think sometimes people focus too much on like the UI where they get a design, for example, again, the video uploader and they make it all like nice with the shadows and then. integrating it, and then they realize, oh wait I have completeness alignment here with the backend Leo Dion (host): developer.
So I got this really cool swift UI animation, but it's totally useless because our backend doesn't support it. Yeah, yeah, yeah. Tjeerd in 't Veen (guest): Whatever. So the, so one thing I, I. Try to steer it towards and also do the, in the book is to get the integration as quickly as possible. So when, when you do this, when you make an actual API call, you learn a lot and the backend doesn't have to be ready, by the way. They can just have like a mock response.
But you learn Leo Dion (host): like, By the way, I wanna, I wanna just say it like, I like what you did in the book where you had like the fake, the fake api. And I was like, why is he using threat sleep? Like, why? And then it's like, oh yeah, I see what you're doing, because you wanna like mock up the, the, the backend call in your, in your, your app. So yeah. Sorry, I just wanted to mention that.
That's like a really good that's a really good way to like, Get some velocity on your mobile dev without necessarily, yeah, depending on your backend, assuming that you, you stay in sync with your backend. Sorry, I just wanted to say Yeah, that that was really cool. Tjeerd in 't Veen (guest): Totally. So, yeah, so what I want steer towards to usually is to get a the, the complete end-to-end sort of call ready as soon as possible.
So like if you have data and it needs to be uploaded common scenario, but don't wait till UI is done. Like do the way earlier because you're gonna learn that you, for example maybe the backend assess is ready. But your laptop cannot connect to staging and like, oh, oh wait, I need, I forgot. You have to give you a token. Oh wait, now you need some special rice. You have to request and now you're weak. Further depending on your company. Yeah. Right.
Or maybe, or maybe you need to get some tokens from this third party SDK you use and you're like, oh wait, I have to actually get more budget now cause I'm a new employee and I need the budget for it. So whatever it is, like you, there, there are these things you don't know what's gonna happen when you postpone the actual integration. So I think by. By moving them more forwards in your development process. And I know maybe it's not as exciting as you are for some people.
You're gonna learn a lot quicker what problems already there. And what's nice about that is you can sort of like quote unquote activate your team members to, to fix these issues while you're doing the rest of, as opposed to. Getting everything ready and then you're making your sorry, make a backup call and then realizing it's actually not working and then needing to add a couple more weeks of time to get everything ready.
So that's one thing I would really recommend is to do to, to talk to, to integrate as soon as possible. But regarding alignments, yeah, that to me just comes down to regular communications. Hard to give you p made answer for the situation. But like in case of video uploading, you know, you have to think. Like what could go wrong? Like how would, what performance do you expect? Like how often like can we hammer the server? Like how, like uh, do we need to take some measures or even loading data?
Like, like is there a, a problem if you start loading a lot of data from the back and like, do we need to do some local storage? Something you may wanna consider, right? Yeah. Common one is I have a screen and I need four types of data. Can you talk to the backender to just give it in as one API call? That's always gonna be in nice discussion. I feel like it can be worth it.
For example, if you have more traditional rest api, you can say, you know, can you give me the data in one format, which may me be more work for a backender and they may not want to do it. They can just say, make four API calls. But if the Android developer also has to do it, and now the web developer also has to do it, it's actually a lot of work for all of them. So they can have those conversations as well. Like, how can you consolidate certain data? So that is more consumable from mobile.
So those are, I think, discussions you can have. Leo Dion (host): One thing I think is really helpful is demos weekly demos of like each team, like, okay, let's see how the Android app works. And then like the iOS folks are like, oh, interesting you did this. And the backend folks are like, Let's not do that with the api. If you upload like that, yeah, it's gonna hammer our servers.
Like you need to do some and you know, and I think that's really, like if we talk about meetings, like meetings can be awful, but like a good demo every week just to show off a feature that everybody is working on in parallel. Yeah. I think is gonna be super helpful. Making sure everybody's on the same. Tjeerd in 't Veen (guest): Yeah, and or even internal bills. I love internal bills because it gets people excited. I think people see, actually see their work actually working in their own hands.
I think it's also an amazing tool Leo Dion (host): on top of them. Right, right. Yeah. So one, one term you used throughout the book is holistic driven development. What? Yeah. What does that mean exactly? I made it up . We just, we need one more. We need one more driven development. we need more Tjeerd in 't Veen (guest): ATDDs, TDDs. I know it's so, I'm trying to, you Leo Dion (host): should sell, you should make a whole business of selling certifications for that, along with your book.
Yeah, yeah, Tjeerd in 't Veen (guest): yeah, that's true. So well the thing is, it's not really one thing. So that's why I tried to give it a new name. But with what I call holistic driven development is a way to start from scratch so someone gives you a feature requirement, and to have something working really quickly. On not only to just throw away in as experiment, as an experiment, but also to have it working for the long term.
So you think about the domains that you need like which types, which classes you need. You think about API design, you think about binary the, the boundaries of APIs, and then with that, I mean the APIs of your own types but to make it more concrete Let's talk about the video uploader. It's, it's about sort of top down design method, which is not a new thing, but what what I really propose is you work your way down. So you start at the top at sort API design.
How, how you would use this video uploader. So let's say I'm in let's, you have a teammates that also does does the UI part and you do the uploading part. Your teammate would. Only be interested in the API of the video uploader. It doesn't care if it uses offline storage. It doesn't care if it uses background uploading like the, the, the, the UI part only needs to know like, Hey, I'm picking a video, I'm sending this video to you and you handle the uploading.
So these kind of barriers become really important. So the holistic driven design, what I try to share there is you start this sort of top. Driven development where you think about what's most important from the API side, but then internally it's our placeholders because it doesn't matter to the call side whether or not things are working right. This can really speed up the, the process for everyone.
But as soon as the, but as long as you properly design the API boundaries of these types, then what happens on the water yeah, can just be updated over time to like review implementation later on. So this. Yeah, it's so, so I guess what, what you, what that means is like over time you'll go deep and deep and deep in your code base to actually hit the real network calls and the real data storages. But those problems will become so trivial at that point.
All you have to do is quote unquote just make a URL session call and make a background task and you're done. But cause you've thought of everything else already and you've thought of all the bits and pieces and how everything is calling each other, you can defer the complicated parts. Maybe a long answer, but Yeah. Leo Dion (host): Yeah. It's kinda relative.
It's funny you're talking about the complicated parts and, and breaking things down because we were, we were talking before the show about your neighbor and our, like one of our 500 Dutch guests that we've had on the show. And Donnie your neighbor had a tweet about abstractions and, and how abstractions can sometimes be unhelpful. And you, you had some interesting thoughts about like, over-engineering and abstractions.
Yeah. And, and, and like when they're helpful, when they're not, you want to kind of break that down as well? Tjeerd in 't Veen (guest): Yeah. Yeah. So I dunno if I could do it in a few minutes, but for sure. So I've been involved with tons and tons of teams who have made tons of abstractions or lack of abstractions and me included, where I've seen everything go wrong and everything go right basically. So I have a lot of I try to distill a, a lot of.
Like best practices that you can think of when you make your own code? Like, should this be an abstraction, like very common? Like let's say you have another team that has like a component. You wanna use it, but it, it's slightly different than what you really need. Like, what are you gonna do? Why are you gonna make an ex an abstraction and take something out for what you need and then offer like a thing that you can build on top?
Or are you going to duplicate it because it's too different and it's going to be too different or you know, I see people post these tweets like if it's used three times then it needs to be made reusable, but not before, but like, that's kind of true. But I think strike is such a deep topic, like mm-hmm. for example. Just because, you know, just cause code is reusable doesn't mean it's generic. Vice versa. Oh, Leo Dion (host): interesting. I like that. Tjeerd in 't Veen (guest): Yeah.
Yeah. And, and also sometimes it can be a good thing to actually start with the generic component, even though everyone says not to. Because like I give an example in the book, like I make a little store. And the store is generic. It stores just, just generic things. Like it stores data that in an offline store, in an offline way. Mm-hmm. But it's generic right away. It's not like used three times and then it's extracted into its own thing. It's already reusable component, which isn't re reuse.
Yeah. But then is Yeah. But then is an over engineering. And I go about I go over that actually, and. Depending on where you are in the abstraction layer and where this component lives, you can also decide if it should be generic, if it should be serving other features, and if so, should it know about this other feature? Right. Why or why not? So, so those are topics I'd like to uh, touch upon. Cause I think a lot of stuff goes wrong there. Yeah. Leo Dion (host): Yeah.
What, what do you think is like the biggest mistake one can have when they're like abstracting an API in such a way? Tjeerd in 't Veen (guest): I think. Well, maybe not the biggest, maybe the most common one is people con conflating the type name with the instance name. So I'm gonna give a classic example and then maybe I'm gonna maybe be a bigger example. Leo Dion (host): Will it involve a video uploader? That's the important thing. Yeah. Tjeerd in 't Veen (guest): Oh yeah. Has to . Exactly.
So let's say I have an image description and I'm using it for the video uploading, right? Mm-hmm. to show you what the image is about. Yep. People may call this type, they make a component and they call it video image description. I have no better name right now. But I think that's, that's actually already the, the problem that I see because that is how you would use it. Because how you use the thing is for your video image. So there will be the instance name, video description, for example.
Mm-hmm. . There will be the instant, what people call it, the type video description or video image description. And the problem with that is that if you think about what the type is, so it's nothing more than an image with the description. It has nothing to do with videos at all, right? Leo Dion (host): It doesn't have to, right? Tjeerd in 't Veen (guest): No. No. So what happens now is someone else also needs an image and description for an avatar, for like a person profile.
Can they use the video image description or They could, but the name doesn't make sense, right? It has video in it, so something went wrong, but it is the same thing. Maybe the dimensions should be configurable, whatever, but like it's the same thing. So, What I think goes wrong there is that people give the name of how it's used to the type. Okay. But it should be only given to the instance. But this is like a very maybe basic example, but it goes really far.
Like you may have let's say you have this payment flow and yeah, it uses Screens that are backend driven. So like, let's say the backend decides which screens are used to render the, the payment to render the payment flow, right? This may be called like payment flow backend I dunno, call it backend ui, p b ui. And then, and now, now everyone is using this P B I system. But guess what the, the whole flow doesn't need to know about payments at all.
It's, it's about right, it's about a backend UI driven thing. It's used for payments. So people call it payments ui back on UI flow, but it's actually it's actually standalone backend UI flow on its own. So these naming things, they, I see them go wrong a lot. Because if you would call it backend UI only now I can use it for anything. And it's still just as reusable and, and generic as before, but it's the same thing, but the name is just better. Right, right.
It doesn't sort of hint at how you should use it. I think thinking and more like an instance name, so the instance name could be a payment UI flow, but the type could. Second UI flow or something. Mm-hmm. . Mm-hmm. . That is really, that's gonna solve I think, a lot of problems already people have. Yeah. Cause now you can reuse it. Now the name is more clear. You know, you know, kind of where it fits in the abstraction layer.
It's like, it's not really a feature specific, it's more like a, a tool to help features and so on. Leo Dion (host): So let's talk a little bit about everybody's fun. Like favorite topic architecture patterns. Yeah. How. How do the ar, how do architecture patterns fit in with the design of your app? Like at what point should you be like, okay, I need to use this pattern or that pattern with, as you develop the app or as you design the app. Tjeerd in 't Veen (guest): Yeah.
So this is quite a, a minefield of a topic. I'm gonna step into it anyway. , I think yeah, yeah, yeah. So when mobile developers talk about patterns and architectures, they usually only mean UI architecture like, you know, fiber perfume models you know, post architecture, whatever, MVP and, and you know, reactive, whatever. But it's usually UI based and. The problems are common. Common problems are related to binding data to ui.
Mm-hmm. If I want to sort of maybe simplify it Leo Dion (host): too much. No, totally, totally. Tjeerd in 't Veen (guest): But the way I, sorry, what was your question? Exactly? Like how does it Leo Dion (host): fit in the development? Yeah. When you're designing the app, like how, how can you look at that UI design or maybe the diagrams that you've built and be like, okay. Like this is the architecture pattern we're gonna be using for developing that. Yeah. Tjeerd in 't Veen (guest): Yeah.
So well I made have a strange opinion, but I feel like it usually doesn't matter in my experience, it's more about preferences from what I've seen cause I, I've seen people make great apps from, with many parents, but I feel like there are like some, some guides there you can say. If your app has a lot of like life updating data, then maybe you're more partial to using a reactive pattern because it's hard, hard to keep everything constantly updated.
But but, but I would say what I'm usually leaning towards to is, Try to keep things as simple as possible. And that's easy to say. But I feel like sometimes panels can be too much of a crutch. Like if someone says, I need like a five acronym to make this app, then I'm kinda getting nervous, Leo Dion (host): like, hold on. Like, Tjeerd in 't Veen (guest): Like, like why? Like, like some, to be honest, sometimes screens are. It can be simple, right?
We've had some data and you, you render it like, right? There's million of tutorials on that already. So why do we need like a, a six letter acronym or something, or five letter acronym to solve this? But I think the view issues is, are more related to different issues that people face. And I, I think pattern may help sort of get people used to how to make an. So there's sort of like a crutch, like you like, oh, I'm used to using MV mvpm, I'm used to using street with architecture, whatever.
Like I'm gonna use that. I'm gonna solve, it's gonna solve a lot problem for that person, but I feel like over in two years there's gonna be next pattern and there's gonna be next one after five years. So, yep. That's what hint as well. Sorry. No, Leo Dion (host): I think you're, you hit it on the notes. I think it's helpful for teams like larger teams where they need to agree on like, okay, we need to add a new screen. Okay, this is how we add a new screen for this larger app.
I think that that's helpful. I think. Yeah. Yeah, I mean, I, I agree with you. I think it can be too much of a crutch because like you said, you a, they change a lot, which we'll get into third party libraries. It's the same situation and it's sometimes over, like, it's sometimes a bit of an over-engineering of how something worked to me. Like patterns come out of how you've designed the app, not, it's not something you go, okay, this is what we're gonna do and we're gonna move forward with it.
Yeah, and then like there are definitely anti patterns. There are definitely, I think it's, like I said, based on your team. It's also based on the underlining platform. Like, like in Swift ui. Like you never wanna do nbc. Sorry. You just, you don't, yeah, like don't do nbc. Like that's obvious. But like there are. Multiple patterns you could use. So there are ways you can use combinations of different patterns.
And I think like that's where, that's where like how, you know, in my opinion, architectural patterns fit in really. Yeah, I do, I Tjeerd in 't Veen (guest): do agree too. It's a good alignment too. In, in larger companies it is nice to have like a sort of alignment. Okay. Like these are sort of the payments we, we will use. Yep. because large company people say, can I use combined? Can I use RFI or mm-hmm. or whatever. Like they, they will ask and it doesn't make sense to just make and match.
Cause everyone has different preferences. I would say try to pick the parents that work for your company, right? If you have, if you just have a bunch of table views, you know, why, why go all overboard with all fancy stuff? Just, just make a little small view model. But maybe you have a live updating chat service and maybe reactive copies. Makes a lot of. Leo Dion (host): You know, but Right. Exactly. What Tjeerd in 't Veen (guest): makes it all up, I would say try not Leo Dion (host): to.
So let's talk also about like libraries and like trends in development cuz that kind of piggys back off of that, where it's like sometimes using third party libraries can be a crutch as well. Sometimes it could be helpful to get something done quick. Yeah. Like where do you fall on that spectrum, I guess. Tjeerd in 't Veen (guest): So early in my career I was really like excited about third party libraries.
Like, especially for did like Ruby development and I could just get, grab a couple gems and it's working and I'm good to go. But now I'm a bit more apprehensive because well, the problem I find is there's another couple problems. I feel like the third party library should really solve a major issue for you. Cause if, if you just very easily add a part, a third party library to your application, then well, you list that the main, the maintenance is slow, so you have to do some due diligence.
There's maybe a legal department in your app team that also has to approve. There may be issues with, like, I remember having had issues with Swift releases then that impacted some of their party libraries and they were just one week too slow. So now you were actually depending on them to do the work. People you don't know. And it's kind of, I feel like a problem, but. There are safe bets for sure.
And for example, if I'm gonna wanna do image catching on you like it, I'm not gonna reinvent the view, I'm just gonna grab kingfish or something. Right, right, right. Like basement time. So some I would say be like treat, like I say, treat like cinnamon like a little bit here and there is good, but not, not too much. Yeah. Don't wanna eat Leo Dion (host): spare. That's kinda my sense.
Yeah. Yeah. I think like, to me, like a good, a good indication is an open source like, For some reason people aren't like, you gotta think like, if people aren't, aren't maintaining it, then at least could you take that for kit and put it in and use it yourself and do whatever you need to do. Yeah. Because that's always an option. Tjeerd in 't Veen (guest): Well use investments. You have to keep that in mind. Yeah. Leo Dion (host): Yeah.
So like, you know, is it worth building it yourself or is it worth using the library and then maintaining yourself if need be. Like, yeah. And like, is it, is it used, is it updated? You don't want to, I've seen libraries that are still on Swift four, swift three, and I'm just like, yeah, okay, this is, this is dead. Like and just, yeah, keeping that in.
Tjeerd in 't Veen (guest): Yeah, sometimes teams are really, I mean, I, I think it's wonderful that people work for and, and you know, use their free time to build something for people that they can use. But I, I think we just have to be careful to to make sure that yeah, things are not slowing down your company, your business, what that's then that's gonna be painful. That time gain you get is gonna be lost when teams are just slow to update their stuff.
Yeah. Yep. If a helping hand, if you can contribute stuff like that, you gotta keep it all night. Yep. Leo Dion (host): Yeah. Let's, so I wanna talk about, we'll talk about testing first and then I'll get into interviews last. So one of my fields, Yeah. So you had some, you have. Some interesting things you wanted to talk about when it comes to testing and yeah. That you wanted to talk about. So, cuz I mean, I think testing is super important. I think.
Yeah, like code coverage is a nice indication, but not the be all, end all. No, but to me, like testing also is a good way to have a healthy architecture in the end as well. What, what, what's your take on testing when it comes to systems design? Yeah. So I feel like Tjeerd in 't Veen (guest): it's good to know kind of the, the things you're really trying to solve in a mobile app.
I think a lot of people, they they make something new and they write a test for it, and they merge and then you know, and then if there's something in, during the release cutoff and you like, make a release bill for internal checks before you submit it. I think that's where the real testing happens sometimes where you make so let's take about the process, right? Like you have the main. You're gonna make a release. You cut off the branch, you make a release branch.
And then maybe, let's say in a company like a week long where people check the co, they translate the copy, they check the, the manual test, all stuff. It's your the write test or your unit test. But the real issues usually come out there because the hard part about mobile, what I find is the whole release part process. We can't just quickly roll back a release. We just have to push forward and Right.
We can use feature flags and, and stage rollout to sort of remedy the shortcomings, but, Once the crappy broken bill is out, you're, Leo Dion (host): you have to be quick Yeah, yeah, yeah, yeah. Tjeerd in 't Veen (guest): So, so what I wanna focus on is how can you get more guarantees before you merge and not just for your own piece of code. And I think. What I see a lot, which is also what I used to do, is like I make a new class. I have to test it.
So I, and interface, like a protocol and now I can test it and now it's swapable and looks green, it's great. And the CI says everything's green. I merge it and then it goes on the release train and then we see like, oh, it's actually not working as well as we hoped, and it's already too late. Mm-hmm. . So what I wanna focus on what I've, what I've seen a couple lot the results with. Testing with more actual code, which is, which goes against the entire concept of units.
So a lot of people don't like it. I know they don't, but it actually does work well, if you can let's say I have like a complete stack. Let's take the video uploader and I have like sort of data chunking logic, and I have like uploading logic and have like an API calls and I have like the video uploader component itself. Some people may say, you know what, I'm gonna take the video uploader and I'm gonna mark everything up below. Cause now not cause that's the only thing I need to really test.
It's the most important thing, and my test will run quickly and so on. What I would say is well test everything. Test the video. Uploader make, could use all the real types. Mm-hmm. only, only mark out the tiniest part. API call itself, not complete API domain, only the tiny function that makes the call. And now when you test the uploader component, you indirectly test everything. So it's.
It's kind of like integration tests almost, but without view API calls, it's kind of like you can make all the component testing. Okay. But I, but I wanna take it a bit further and say you wanna test as much as your code as possible, and that gives you a lot more guarantees and how Yeah. And how your code is actually used. Okay. Leo Dion (host): So is it different from like, because it sounds like you mock the api, the backend, but then you.
but you're not testing the individual pieces, you're testing a whole set of pieces as they integrate. Yeah. So except for the back, I guess. Tjeerd in 't Veen (guest): Yeah. But let's say also I'd like foul storage. I would probably, in some cases also test foul storage. A lot of people would say, don't do that because it's like global immutable state. Mm-hmm. . But well, I actually did work on a few upload and I called issues by actually testing the file storage.
Now the problem is it's slow, it's io things go wrong. But I'd rather know that during my unit test phase than merging it, having Gotcha. On my test screen and then go to the release and then like, oh wait, it's actually not working on Mac or something. Yeah, Leo Dion (host): yeah. Yeah. Oh, interesting. Yeah, cuz I've, I've run into that before.
That's a really good, good point where I've had like downloaded large files or uploaded large files and like yeah, if you can test that out, would that be a good case? Like in, in iOS world, would that be a good case for like doing a UI test maybe? Or would you still do it as a test case? So, Tjeerd in 't Veen (guest): so I think rights are amazing. And a lot of people actually don't like 'em. I like 'em a lot because if I give a manual tester my new.
They will go, they'll grab, I know, four phones and they'll test it for me. Right. And but they can only test so much. They will not test that. If I have like dark mode and a large font size and right to left iPhone five only, then there's a major bug. Yeah. But like it's hard to find, not saying you right as will also find those, but but like I said, I minimize my screen. Like a background, the app at one of the 60 screens and on one of those screens, the app crash. Like I've had that happen.
Manual testing is, is not really gonna find that as quickly and I find U are amazing that you can really scale up all these variants. You can do. Like, let me just take 12 devices and all these variants and, and just go ahead. But people don't like them for good reasons. They don't like 'em cause they're slow. They're slow to write. They're slow to run. Yep. They, they, they're brittle, they're flaky. And I get all that. Yep. But I do do see a lot of value that even running them like nightly.
And getting some reports can already be like like a little bird in the coal mine. Like it gives you already some warning, like careful, like, like one week before the release cutoff comes. Yeah. You already can get some problems. Not even though maybe some tests are flaky in the red, but maybe they're fine. Yeah. It tells you something, right? I, I see a lot of failure in that actually. Leo Dion (host): Yeah. Well, before we, sorry, I wanna, let's, let's ask one more question about Sure.
So your book is actually pretty, like, it's not focused on, I, like, obviously your expertise is in iOS and Swift, but it's not really focused just on that. There's sample code mostly in Swift, but you're, A lot of this could be applied to. Web developers, Android developers, et cetera. Is there anything in particular iOS and Swift folks can take advantage of when building, building an app in particular to their platforms?
Or Tjeerd in 't Veen (guest): in In regards to Leo Dion (host): system design. Yeah. Yeah. Is there something like you're like, here's an example in Swift or an Xcode or iOS development where it's like, you definitely, this is one mistake I see folks do when it comes to systems design for iOS or Mac Os, or, I see whatever. Tjeerd in 't Veen (guest): Yeah, exactly.
I think system design itself is more it's not so much focus on the details, it's more like language agnostic and and like, yeah, like you said, like the book is not specific for iOS. But once you go into the details, it does matter which language and which platform you're using. So I don't think there's like one specific. Problem that I developers do, that energy developers don't. I think it's more about the constraints and limitations we have.
So how Leo Dion (host): would you, like, is there something about Xcode that can maybe help you like be more consistent with your design, I guess. Tjeerd in 't Veen (guest): Yeah. So I do think largescale iOS apps are it's maybe not every company, but it's not really something that Xcode is really fantastic at yet. Mm-hmm. , like, I, I've file packages for years now. Like, yeah, like I remember when Swift came out, you can only have six swift packages. There was the. The limitation.
Oh, you serious? Oh my gosh. Yeah, yeah. Something like that. So, cause the, it was all like you three something, it was early, early days. I didn't get that. Yeah. So I do find in iOS you're more limited to having fewer packages, or at least how it used to be, whereas the could just have like 80 no problem. Right, right. So that, so that, those impact, like how you think about like maybe larger modules versus like lots of tiny little interface modules everywhere.
Yeah. So I do think that matters. Leo Dion (host): One thing I've I've started doing is breaking down. So I, I, I don't know. I'll call it's package driven development because I, I want the, I wanna make the Yeah. That, trademark that so I can cash it one. Yeah. So one thing is like my, most of my apps are all stored in swift packages. There tends to be very little code in the actual app, and I've started breaking down my Swift package targets.
As much as I can both for faster development, because obviously you got parallelism going on, but also just easier maintenance. Like, okay, this is the part that does networking. This is the part and it's a separate target. Yeah. And, and that I found a bit like very helpful. We can get into modularization. That's a whole other episode, but I think that's a big, big big thing.
And I, I don't, I can't speak for my, my friends who do Kotlin or, or type script or whatever, but like, When it comes to Swift, like taking advantage of making packages as as tight as possible and as small into as small as possible, and then making those dependencies much easier to maintain I think is super helpful. Easier. Yeah. Yeah. Yeah, Tjeerd in 't Veen (guest): absolutely.
I, I think it's not like a unique swift io thing, but it's definitely helped that Swift is so much easier now to set up package environment for sure. Right. There may still be some issues with object to c mixing and like other problems people are having, but like when it works, it works really. Leo Dion (host): Right, right. Yeah. And I think like that's a, that's a big thing, I think is just breaking your things down as much as possible.
When we had aviel on, we talked about like, don't, don't just have one giant environment object. Break it down, like and yeah, breaking things down into smaller pieces is both helpful for maintenance and helpful for building and helpful for testing. I mean, there's just so much, so much you can get. I definitely agree and, Tjeerd in 't Veen (guest): and, and creates these hard boundaries between domains. If you. Grab the right domain, right?
It's, it's really powerful that someone isn't accidentally inputting UI in a, in sort of a data part, you know, that can happen with, and you don't have these boundaries. So it's really great. Yeah. Leo Dion (host): Yeah. So before we close out, I wanted to talk about interviewing and interviews. That's something you talk about a little bit in the beginning of the book. I know there's a lot of people who are interested in interviews and getting the right job nowadays.
So yeah, and you talk about that a bit, especially in the context of systems design. Do you think, do you think the process is broken? Do you, what do you think as developers who are interviewing, we should be doing better? Yeah. When we are interviewed and also interviewing, I guess. Tjeerd in 't Veen (guest): Yeah, so, so it's kind of interesting cause it's sort of like a new thing where there are already assisting design interviews for backend and now more and more for mobile. Mm-hmm.
, but it's not really sure what you're gonna get. So I've heard and seen interviews where you get a, a, your UI screen and they're saying like, Hey, how would you make this? And you would write a pseudo code, right? Mm-hmm. Like, like a shared text editor and you write some view controllers, but it doesn't have to compile anything. They would say like, oh, would you use a table view or a collection view? Like what if there's lots of data in CB store? Mm-hmm. , how would that work?
But I've also seen interviews and also been part of interviews where people just just give you like a prompt. They, they just say like, Hey, make me this thing. Like, click video, upload it, , how would that work? And, and they just give you nothing else. And you have to ask questions, figure out what they need, figure out what the requirements think, think about the limitations. And they're really looking for these signals that you come up with.
All the edge case, all the problems, all the components that are needed. What I find hard is to say, you know, study these five things and now you're ready for interviews because first of all, you don't know what you're gonna get a second. The interviews all over. All, all over the place. Yeah. So, so there are guys, like they say, like, you know, learn about, you know key chain versus core data versus property list, you know, and, and, and I think that's good to.
But it will not guarantee you a good interview result. What I think is really important, which is also why I'm writing about it, it's more like to be able to come up with a solution for something you've never done before, but. That's one thing you can expect. You're gonna have to make something Leo Dion (host): you've never made before, right? Like, like, Tjeerd in 't Veen (guest): yeah, like if someone asks me like, Hey, make an ar image video filter thing.
I've never made that before, but like, how would I approach it? Come up with, you know, components and domains and like limitations. Maybe mobile limitations maybe processor capacity. I dunno. Those are kind the things that interviewers wanna hear.
They want see you think about all the important parts that are needed and So, yeah, I guess one, one big takeaway would be you cannot really prepare for one interview, but you can train yourself to to ask the right questions back, to get like a better idea of what's being asked of you. You can use some tactics to like design your application without knowing the details. And that's exactly what I've been trying to help people with.
. Leo Dion (host): So do you think it's something that's easy to study for or is it much suited for a mobile developer with a current position to build experience so that way they can, because it seems like it's an experiential thing more than a studying thing to be a mobile systems designer. You know what I mean? I Tjeerd in 't Veen (guest): think. Yeah. So I do think it's an it's an awareness thing.
So if I give maybe someone just starting out like a feature, they may go straight to ui, for example. And if I give like a staff engineer feature, they may ask me if it should support all the teams in the company. I don't know. Completely different angle, right? And I do, I, I do think you can you can study and prepare for. Like asking kind of what's required of you. Mm-hmm. , I think that gives that, that goes a long way.
Yeah. So if, if, if, if you know what to ask for, like know, like, hey, they're giving me half the information. I need the full picture. That's already a great step. Yeah. If you just start programming, I think that's more of a problem. So I think you can. Train it to Leo Dion (host): some extent, I think, yeah, I think it's totally healthy to have like a two-way conversation when you're getting interviewed on a complex question like that.
I think sometimes people who are interviewed get a little bit intimidated, like they think they're supposed to know the answer. Like it's just, here's the question, here's the answer. But yeah, I think sometimes when they interesting, like, and as somebody who's it done, the interviews like I think it's important to realize sometimes those open-end. Questions are there because they want to have a conversation with you. They want to know that you're asking the right questions.
Yeah. And like, like it's just to get a good feel of someone being, like, having a little bit more confidence. And instead of being like, okay, I, I'm gonna go make the best video uploader, it's like, no, slow down. Like, The right questions. It's not, it's not a right and wrong answer. It's much more of a yeah. Of like, we're trying to get a good feel of this person to see if he's gonna work with us or she's gonna work with us and she knows and has that experience.
Yep. Yeah. So. Tjeerd in 't Veen (guest): And, and they may test your communication skills and Exactly. Test your iOS knowledge. You, you don't know, but like, it's good to, Leo Dion (host): It's not a binary, there's no right answer, especially, no. There, there is no right answer to a video uploader. Sorry about that. If that's what you're looking for. I think, I think we, we've talked about everything except the most important thing. when is this book gonna come out and how can I get it?
Well Tjeerd in 't Veen (guest): I'll give it one to you, , but it's coming out, but it's coming out in 2023 somewhere. Okay. I'm definitely there. So but I can't exactly give a date yet, but I'll make very few orders once they have the Leo Dion (host): book is done. Okay. Do you have like a mailing list folks can sign up for? Tjeerd in 't Veen (guest): Yeah, I do have one. I can send you the link. Leo Dion (host): Yep. Yep. And we'll put that in the show notes. So, yeah, definitely.
Oh, This, this is awesome. I'm so glad somebody's coming out with this book because it needs to be done. There's way, there's way too many books about how to make Swift UI do, do a shiny animation and we need more. More. Everything has its place. , everything has its place. That's true. That's true. Yeah. But if you have a, will run a large team or you have a large enterprise app and or your mobile developer and you're looking to take it, take it to the next level.
I highly, highly recommend checking this out. The link to the mailing list will be in the show notes, so you can check that out and get get an update when that book is ready. I've looked at it. There's a lot of good, solid stuff in it. Cheer. Thank you so much for coming on. This has been fantastic. Thank you so much. Tjeerd in 't Veen (guest): I really appreci. Yeah, it's fun. Yeah. Leo Dion (host): Where can people find you online?
Tjeerd in 't Veen (guest): It's probably better to spell but che in Spain, t j e e r d i n t v e e n. And yeah, I guess that's the best way to Leo Dion (host): go. Just find me on Twitter and we'll have the links to, yeah, Twitter, LinkedIn, as on all that fun stuff. In our show notes. People can find me on Twitter at Leo g Dion. My company. Digit. I'm on ma, I gotta say Ma, on now I'm on massed on two. At Leo G Dion, at cio, IM and LinkedIn as well.
If you have any questions or feedback, let us know. We'd love to hear you from you if you're listening to this. On a podcast player, please take some time to put in a review. This, so you too, please like and subscribe. Really would appreciate that. Next episode in two weeks, we'll be with Marin on his new app Data Tile. So definitely check that out. Have hope everybody has a good week, and we'll talk to you later. Bye everyone. Bye.