iOS Interview Questions and Answers (with Sample Code)

Key Takeaways

Interviews can be daunting, but they don't have to be if you're wellprepared. In this course, Richard breaks down 10 popular iOS developer interview questions and demonstrates the solutions step by step. In this video, I'm going to go through the top 10 iOS developer interview questions and not only go through them and solve, but actually uh we'll dive deep into the reasoning behind the answers and probably look into some documentation as well as look at some sample apps and sample code. And to assist me to make it look like a real mock interview, my friend Daniel will be helping. He's on the other side of the call. And uh Dan, say hi. Hey, what's up everyone? So yeah, the first question would be to you actually and uh uh could you tell me more about yourself? Yeah. So, hey everyone, my name is Daniel and I'm a web front end developer working mostly with React and I did iOS like five years ago for a little bit. So I am a bit familiar with the questions so I can assist Richard with the interview. So you'll be my interviewer now. Uh yeah, basically so you've seen the uh question list. What do you think of them so far? Um yeah, it's like nothing has changed much. I'm just wondering why you didn't add any Swift UI or combine questions. Yeah, I think um it's a good idea. I think uh Swift UI and combine are such are new topics and uh they really worth a separate video on that. on the topic. So probably we'll make a separate one and not to miss it just make sure to subscribe to my channel and uh if you want the combinance QI uh separate video just let me know in the comments below I'll make one just on that topic. Uh yeah uh but why I started with those questions basically they are very fundamental and all the companies right now are asking some sort of them uh when interviewing for an iOS developer role and um uh this is really interesting because uh if you watch this video till the end uh there are about 10 questions uh it's very likely that you will get one or two of them in your next interview. So uh I think that's a very good uh training and exercise for for preparation for interview. All right. Yeah. So let's get started. Yeah. Let's go. I'm ready. Yeah. So the first question is can you explain me what is a view control life cycle and what are the most important events? Uh yeah, I think this is basically the classic iOS interview question is being asked for 10 years at least. So uh to actually see what is a view controller life cycle is I've just created this um uh basic app which is printing out uh each method so that we can see what's going on in the view controller while we show it or hide it. So I used the storyboard uh and uh created a very very simple app which will show just the uh model view controller basically presenting a sheet from the bottom and we'll see what events we'll be printing out. Let's run this app and see for ourselves and uh what are life cycle events and what are uh what are uh the most important ones. So open life cycle press button and we start with a view controller. So as you can see the first one to be called is in it with coder which is basically an initializer and in that case it might be called a different one in some cases because for example if you're uh initializing your uh view controller programmatically in it with frame will be called or this one init with nib name or nail. So one of those basically the initializer always going the first. The next one is load view which is um a method when uh asking for a view to be loaded and the view dead load follows it immediately. Basically once the view is loaded you get the viewed load event. Uh I don't understand why load view if needed is called after that. Probably it's some sort of legacy uh artifact because it doesn't make a lot of sense. Maybe it's just to ensure that the view is loaded but in at this stage it does nothing. And then we have the so-called uh uh appearance and layout uh events. So view will appear is called before the view appears on screen and the view will layout subviews is called uh before the layout pass and then after the layout has been completed. Uh we have the view did layout subviews. All of those are available to be overridden. And um yeah and once the view is about to appear once the view already appear you have the view did appear and once I drag it down we have them in the reverse. So we have the view will disappear and view did disappear and the dinit is called last. Uh in case you don't see dinit for some reason in your view controller that means that you have a memory leak and it's still in the memory. So you have to uh work with the memory profiler and uh one more important thing is that if we clear the console that this view will appear and view did appear as well as view did disappear might be called multiple times. So if I try to dismiss the view for example and then I'll decide to pull it back I have the view will disappear. Uh but I never see the view did disappear because it's still on the screen and we are going back view will appear and view did appear. So uh Apple actually has a very nice a very nice um sample for that has a very nice chart. I'll link it uh I'll link it in the description for sure. And um understanding this chart is really crucial to understanding the view control life cycle. So uh you basically have four states uh appeared and disappeared and transitions between them into multiple directions. So uh and what's important you can move to appearing state you and immediately move to disappearing state or vice versa. This is usually emitted by all of the uh candidates and they just think it's one time event and uh this is a big mistake. So these events might be called multiple times in the life cycle of the view controller as we've seen. Uh and of course the one when rotation is happening is the view will uh transition to uh size with coordinator and the same as uh called when uh for example you're in an iPad and trying to resize the uh resize the view controller on a multitasking screen. So I think that's it regarding the uh view control events. So hopefully you're satisfied with this question. What do you think? Yeah, I mean I didn't know that there are that many methods around the like the view control life cycle. So it's also new to me. But what do you think of what are the most important ones to remember because there are quite many and which ones? Yeah, to summarize to summarize really it's uh it's all about grouping them into categories. The first one is the initializer. That's the main one. That's the first one. The initializer is the first and then the deinitializer is the last. Then you have the view loading related callbacks. Load view if needed. Load view and view did load. Those are the next step and they are Yeah. But what which ones are the most important like which ones I guess? I think I think I think I think the load view and view did load. So viewed load is probably the most used one. I think if you create a template right now it will be there. It will be included there. Yeah. Uh and uh what's the difference between load view and view did load? um load uh so basically load view is uh so they going in a very specific order right so you have the load view first and then view that load after that it's pretty clear and load view is the one to override if you want to use a custom view for example if you want to have view equals UI table view let's see how it works like I'll I'll I'll make just this change and let's see if uh I will have a different view there I Good uh life cycle button. It looks like look is it a table view actually? No because probably I'm using the storyboard that's why it won't really uh it won't really plug it in. So I don't know. But uh if I were to use uh if I were to use um where is this dimming view drop shadow? Can't see anyway. Life cycle UI actually UI table view. You see it's here. Pretty cool. Oh yeah. Yeah. So it's there. So yeah, load view is what you use to um connect your custom view uh and override the default. But if you don't do anything, it's basically adds a UI view here like that. And you just can ignore it. Usually you don't need to override it. And view.load load is when the view is loaded and you can do some customizations for example adding in sub view or something else. So uh that's why I kind of prefer to group them by the purpose instead of like selecting the most important ones. And then we have this appearance callbacks. View will appear, view did appear uh and view will disappear. View did disappear. So regarding the presentation appearance disappearance and we can uh add uh a third class which is to layout related to the layout transitioning to sizes and so forth. So yeah, uh initializer, deinitializer, uh view loading, uh presentation, and um layout. And I didn't even go into details like for example things like um did receive memory warning. That's another one. uh or will add uh or sorry add child view controller did add will move to parent view controller. So there are a lot of callbacks to you think about like apart from those but basically view controller is a it's a very important class obviously there are a lot of uh connection points to work with. So those I've listed are the main and of course this project is available on GitHub. So uh make sure to play with it and I think the best way to learn about the view control life cycle is basically open the project and go through each of those uh steps individually and understand how how it behaves and instead of like just reading the documentation. Yeah. So hopefully we can move to next one. Yeah. Let's go to the next one. So I think this is the most common one. Which one? What's the difference between a strct and a class? Yeah, it's a very common one though. So, um uh well, let me try to answer it. Yeah, yeah, go ahead. Go ahead. At least I remember something about it. So, I think the class is reference is reference based and strct is value based. Value based. What does what does it mean in practice? Like in practice like when you create an instance you get like I guess a pointer to it if it's a class and if you create an instance of a strct then you get a like the value instead. So yeah but what if you try to modify uh the same class like will it modify at the other sites which holding that reference or not if it's with class or what do you mean if there's going to be another like for example if you pass class to multiple objects and then you modify uh something like a value at that class for example let's say point uh of the player will it be reflected for each objects who own that class or uh will they act like independently? Yeah, I think it's going to be like a singleton. Yeah. Well, yeah, it will be reflected for all. Yeah, that's that's that's the main that's called reference uh based. Yeah, a lot of but but uh a lot of people are uh going into details like for example uh saying that uh strct is always copied when you pass it or saying that you like something details like uh oh you cannot uh you cannot extend the strct you cannot subclass strct but you can subclass a class right but those are uh the problem with those answers that they are not very uh they they don't always hold true. For example, you can uh you can not subclass a final class, right? And uh you can uh extend the strct using a protocol. And uh the most important thing which usually all of people are uh not aware of is that this truck might be passed by reference to and for example all of the uh collections in the standard library like dictionary arrays and so forth strings sets they use this optimizations to reduce uh the cost of coping. So um if you try to to pass the array it will be actually under the hood passed by reference uh and only when you modify it will actually duplicate the whole array which is an interesting uh idea to know like for iOS developer uh when profiling for performance problems and uh if you look at the iOS uh or actually swift um array code you will see that there is like a buffer which is uh used like internal storage for an array. And when you try to copy that, a lot of uh functions are actually a lot of functions are actually passed to um they are passed to uh to this buffer. And uh there are a lot of optimizations for example like mutations uh for coping and so forth. um simply because uh because it has to be faster uh for those optimizations and this is doing the job of making it run fast and u from from the developers perspective it appears if the array is copied immediately but in fact it's doing this copy and write on the hood so because swift is such an optimized language and a lot of complexity is hidden from the developer so yeah my answer would be that uh classes appear to be passed by reference have the reference semantics and uh strcts are appearing like they are passed by value so basically copied but they just appear like that those are only semantics do not make assumptions of what's going on under the hood and I'll link those nice articles from Apple which describe uh the difference more like in practice it's important to understand those uh those uh differences But basically yeah the main one is the value versus uh like having an independent instance or uh in case of strct or having the same instance shared shared memory in case of a class and yeah of course you can have the identity um hey Richard do you have like an analogy how to compare class and the str like yeah yeah I think yeah I think the class is more like a bank account so whenever you deposit something to it and withdraw uh it refers back to the same bank account. So let's say I put a th00and there I have a th00and I withdraw a th00and I have zero right but uh a str would be like more like a bank statement uh so I have the bank statement for from today which shows th00and I can get the same from tomorrow which will be zero and uh I can copy I can remove it I can pass it to someone else there will be no uh it will be like a different copy basically so independent of my bank account independent of everything so I think That would be the best analogy. Okay, nice. So, so, so, so, uh, that's sort of the benefit why using strikes might be a good idea because, uh, you can pass them between threads because basically it's copied. So, you are not afraid of any sort of race conditions, mutations because uh once you pass it to a different thread, it the struck lives on its own and the class will still have that reference. That's sort of the notion why they wanted to get rid of classes uh as much as possible and move into strcts and move this protocol random programming thing. I think that was the idea. Cool. Should we move to the next one? Yeah, let's go ahead. So, what's the difference between frame and bonds property of you? Uh I think it's important to figure out what what they are similar. I have again a sample app here that will help us to figure out what they are and what they are not. So um first of all uh let's go to check uh the UI view class. We can just take a look at it. And we have the frame here. And we have actually both frame and bounds. And this you can see they are both of type C direct which means they essentially the same uh type and you can set one for another. So that really makes them similar. uh but what's different is their semantic and the way they apply to the way they used to and this is the most important thing uh the most important difference and uh in short it boils down to uh if I launch the app I'll just launch the app so uh the frame is about the they both if we zoom in here like if we go into the uh C direct they both have the origin which is the starting point and the size which is basically a size of the rectangle. So uh they uh they uh the difference is that in case of frame the origin points to the uh position in its super view. So if the view is not added to the super view there is no concept of frame right and the size is well it's clear it's the size which it occupies in the super view. This is one of the important thing we'll get back soon. Uh and with a rect with a with a bounce it's slightly different concept. So uh the origin is relates to the content that the view is showing. So what piece of the content the view is showing uh in its frame and the size is basically the size of that viewport. Let's call it like that. So uh to sum it up uh the uh frame is about position of the view. So size and uh origin in relation to its super view and the bounds it's the uh what portion of the content the view is showing and uh I'll have few examples to demonstrate this a bit further. So uh first one is the scroll view. The white one is the scroll view. And we have two views there which are sort of showing how the view scrolls itself. And I'll try to drag it now a bit. So see how the bounds and the frame are changing. So as you can see there is a frame and bounds and I'll try to drag it to different directions. As you can see, if if you can take close attention uh pay close attention to the frame, uh the frame is actually always the same here. Uh it never changes. So whenever I drag it, no matter doesn't matter. Uh but the bounds of the scroll actually changing all the time in both directions. So uh the size stays the same 350 and 241. It's the same here and here because the scroll view size doesn't change and the content size doesn't change, right? Uh but uh the origin is changing. So uh that's how the scroll view scrolls and decides what piece of content to display. And one more thing of course we have the case when the size of the scroll you bounce also changes and that's when you have uh for example pinch to zoom gesture uh then you will will have your size increasing and uh uh scroll you will basically zoom onto something and then there is another uh demo which I've prepared is more interesting probably it's rotation so the red rectangle showing the frame And the purple is showing the bounce. I'll rotate it a bit. As you can see the area which occupi which this purple rectangle is occupying in its part in super view it has to be rectangular. It's growing once I rotate it but the content stays the same basically right and if we take a look what's going on under the hood is we'll get the same answer. So the bounce always stay the same. That's 100 100 here. Uh but it's the frame that changes and as you can see the numbers are very very complex here. And yeah because we are just rotating. Uh and if we go to the official documentation we see that the if the transform property is not the identity transform the value of this property is undefined of the frame property. So it to be ignored. And in this case it actually makes sense I think because you can see the uh frame of this view is larger right so uh it occupies a larger part of the parent view so yeah I'll briefly show the code which I wrote here uh it's nothing fancy just a regular regular view controller and uh when rotation is being detected I'll just rotate it on the same uh level as the uh as the actual as the actual uh paint gesture or rotate gesture. All right, that was a pretty deep answer. Yeah, I mean I mean yeah, it's not like an interview question and answer. It's more like a bit more explanation. So yeah uh to sum up the the frame the frame of the view it's what it occupies in relation to its parent view to its super view no super view no frame and bounce is how it positions its content in its own let's say canvas. So that's to be the summary. So the bonds are always larger than the frame. The bounds are always larger than the frame. I actually don't know. I mean, could be that the balance will be smaller than the frame. Let's see. Well, may actually no. There is a thing called clips to bounce, you know, right? So, if you uh you can you can clip to bounce. probably some of the subuse might extend to the bounds, right? Uh and they will still be drawn. But if you set clip to bounds property to true, then it will limit to this bounds. So yeah, the bounds uh the bounds can be uh so the content might extend slightly further uh than the bounds. Yeah. [Music] Okay. All right. Let's go to the next one. what is what is protocol oriented programming? Uh yeah, so protocol oriented programming is a new or not so new paradigm which was introduced to Swift and the main idea was to differentiate from object-oriented programming and to uh solve those problems that were introduced with object-oriented programming. And I have actually a keynote a presentation uh about the type system of swift actually I'll link the video as well. And in short if uh the swift has very strong very strong protocol system. So um you can have the classes strcts and enams conform to protocols and the protocols can have the inheritance between them. So there's a very very flexible way to uh define relationship and uh if I compare the objective C the object-oriented language with swift the way this relationship power can be expressed with protocols in Objective C you have the uh for example NS number uh NS number subclassing uh is is a subclass of NS value and which in turn is NS object. For example, the there is such pecul peculiar peculiar there is such issues that you could compare the view controller with uh an s number for example if this number is equal to the view controller which doesn't make a lot of sense and um uh because they are the uh the descendants of the same class and in swift they fixed it by using a protocol. basically protocol can ensure that um that the compared values are of the same time. So the protocol oriented programming is the idea that you can detach the relationships of between of the objects from the objects themselves. And if an object uh satisfies some sort of uh constraints, some sort of rules uh then you can embed this whole object into a relationship without writing too much code and like repeating it yourself over and over again for each uh different kind of object. uh and uh basically that's a the idea of particle range programming is separating the uh hierarchy of relationship of inter relationship and hierarchy of objects of methods. Uh and that's a pretty powerful construct. For example, you have a lot of power in in the thing called retroactive modeling. Like you have for example the equatable protocol and the way uh the equal sign is defined the equality operator and the inequality operator is defined as the uh the opposite of uh of equality operator. So pretty cool. And you can compose the protocol. So uh you can work on a very very high level without touching the concrete types. uh and um develop software in a much much more modular and flexible way and uh yeah so it's focus on the types and relationship between them. uh and if you have a new type created, you can quickly embed it into an existing relationship uh between them and uh basically uh use all the power that you've already developed uh to have new type supported immediately. And I think the biggest analogy for me is um using some sort of algorithm to capture the list of uh to capture the photos of the tallest buildings by using the map of the city and the list of those buildings. So you have to have a map and you have to have a list to go through each of those buildings and take a picture. The only thing that you have to care about is that your uh map and your list are of the same city. Then you'll get the proper pictures, right? So the protocol um protocol expresses this whole algorithm without naming the city. Once you have a New York for example here you can make the same for Barcelona or you can make the same for let's say Los Angeles. You can have the same uh set of photos taken simply by having these two um objects. And uh I guess that's the idea of it. What do you think? Okay. Yeah. I mean, I see the protocols are like kind of like interfaces, so I don't really remember that much of it, but your answer was pretty good. Yeah. Yeah. I mean, the the the most important difference because we have the interfaces in Objective C. Uh the most the most important difference uh in Swift is that you can actually uh work only with protocols. You can combine them. You can uh express more uh more flexible relationship more concrete relationship uh and um between objects and that will give you u let's say more compiler support in while while you develop. So you don't have to type cast as much. uh because protocol already constrains that thing that type to a specific uh subtype and you know that it will be of that specific type and so forth. So you are getting a lot of type safety uh and but but at the same time you have a lot of flexibility which in the object-oriented languages like uh objective C was uh was uh implemented with the dynamic dispatch dynamism and so forth. That's why you could compare like a UI view controller with a number or whatever. Of course, it will return a false, but uh you still can do that. And in Swift, it will just throw an error. All right. It it it will not even compile. I mean, all right. Okay. But let's move on. So, yep. Grand Central Dispatch. Yes. question. Yeah, let's let's try to open the playground. Yeah, let's try. That's a nice one. Yeah, I like this question quite a lot. So, uh I guess the task is to figure out what will be printed out in all of those questions. Let's start with the first one, right? Do you want to try to solve it? I mean, when I look at that code, it's like who who writes this kind of code? Yeah. By the way, by the way, before me write this code for sure. It's it's I written this code a few half an hour ago. But before we start with that, I I I highly recommend watching this protocol oriented programming talk by Apple uh in 2015 with Apple DC and I'll link it of course. So um it's more entertaining probably than this video but it definitely takes a longer time to understand. So uh yeah, let's get back to this question. Uh so uh yeah I think the first thing to say in an interview in my opinion when you see this is that this code should not really be written and if you have if you see this code the best thing is to go back to the drawing board figure out what should it do and uh and uh then uh write it from scratch by understanding the requirements. But uh of that's the first thing. And for example, if you were to be interviewed by me, you'd get definitely some bonus points for that. And uh yeah, but what do you think uh what do you think uh the answer is here? Um so defer does things as the last stuff and um so the print f is going to execute first this one. Yeah. Yeah. Let's try. And [Music] um yeah. So yeah. So I think I think the the next one is going to be the print e because I think the defer goes in a reverse order. Yeah, they this is very important thing to remember. They go in the reverse order. So uh if this defer is called first, it will be executed last. And the defer stage what uh for those who don't know this it's basically a a way to work with a legacy API for example if you have some some resource acquisition happening here and you want to clean it up immediately instead of remembering to clean up in all those if cases you have in the code you basically write as soon as you lock onto something you write a defer statement immediately and you'll sure that the moment the function is closed that resource will be closed too basically. Yeah. So uh then this one is obvious to be the next one. Which one is the next after E? Yeah. So it's going to be the one above it. So the where the print B is. Yeah. And and in my in my opinion, just do this. So um whenever whenever you have something complex just hide it here with the um with the uh code folding and um then you can unfold those ribbons. So you see the F help make Xcode help you. Then you unfold this one which is the next one, right? Makes it really clear. E then we unfold this one, right? Yeah. because we we go one level up and uh what is the order here? So it's going to print B the first one B because it's the Yeah, the B running the B here and then it's going to go to the print D because the defer statement is deferred right we just hide it yeah it's going to be excuse or flash then D and then we have C because uh we are exiting this whole close right and this is the last one oh yeah let's check this I think I agree with you. F E B Dca F E B Dca Looks like we are correct. Cool. Yeah, cool. Let's let's let's tackle the next one which is a bit more complex. And again, the idea is that this code should not go into the real system into the real application. So uh it's better to refactor it than trying to decipher understand. So what would be your approach? So actually how would you refactor a code like that? Yeah. Well well it's a synthetic code. So the like I don't know the purpose. I'll go back and look at the look at the look what this code is doing and then try to restructure it. But yeah we can actually this is a good help. Um in the preferences you can actually set up the code uh uh in a text eding you have the code folding ribbon here which will add you this ability to fold the code and this really convenient to solve this kind of tasks that this actually asked quite a lot in the interview for some reason. Uh so yeah just fold the ribbons and you can focus on uh what to be executed first. So yeah, how would you tackle this question? Yes. So dispatch Q. Let's go. So the first one that's going to print it is the A A because it's the first in the um yeah it just first line of code then this dispatch Q line gets executed. So it like creates a new queue. Yep. It doesn't create a new queue. It just dispatches to a different queue, right? Oh, yeah. Well, yeah. Yeah. Lower level stuff. Yeah. Well Well, yeah, sure. But uh it's it's an async uh it's an async Q, right? So uh this Oh, yeah. Yeah. Yeah, that's true. It's in the sync one. So, okay. Well, yeah, it's it's a sync. It's gonna like I guess go through this function first. So it's gonna the whole thing print the Yeah. So I think that's correct. We can just hide it because it's dynic, right? So it's separate Q. We just hide it. Yeah. So yeah, the I is going to be next. Correct. And what else? So we now need to look here, right? Yeah. So then it's going to check out the the async Q and it's going to print the B. All right. Pretty clear. I don't think I have any concerns regarding that. Okay. And then there's the sync Q. So it's going to like skip this. Well, put it on another Q, I guess. So we are hiding this for now. Yeah. So, it's going to go to the D. Press D D, right? Yeah. And then uh Okay. So, there's a sync not async but sync synchronous. Yeah. And so, they are in the same queue, right? The main queue. Yeah. Yeah. Yeah. So, so first of all, what what is the sync doing to the queue? What is the purpose of the sync? How is different from this? Like you have two of those. Um, you have the async here and you have sync. What's the difference between this and this? I think it's going to block the UI until the print e gets well. Well, it it it won't block the UI. It will it will block the execution. So, basically, uh, you you go the B, then you go to D. This is scheduled, right? This is async. it just skips it. Then you have D and then it goes to this line and then it waits basically it schedules this part to be executed on the main Q again but it will wait until this finishes while it waits uh it the main Q has uh there is one more important difference uh there are serial and parallel cues right so we know that main Q is serial Q so uh it will execute the tasks in the order that we send to it. So it will not start executing this task before it will start uh it will finish this one. So the C will be finished first and then only it will go to E. Right. Oh for me. Yep. Because it is serial Q. So it will uh take task by task. So it will not uh execute them in parallel. So it will not be able to there would be no race condition between the C and the E. This is very important. Yeah. So even though there's the sync like method or like Yeah, it it is it is as it is as sync right but you see it's it's being as sync in relation to this global queue. Uh but but then it sends it on the main Q and um and uh it is scheduled there. So uh the task has been put to that queue. Right now you go next to the you're printing D and now the sync is again with relation to this Q basically waiting synchronously while this whole thing executes on the E uh on the main Q and uh you're waiting waiting waiting but uh it takes the first task which is C it prints C and then it will print E because yeah and then it will skip for them. So uh actually I'm interest I'm I'm I'm I'm interested. Yeah, I think it will block the queue, right? So the the H is still here. So it will not reach it, right? So this should be Yeah. So then again we're having the async thing, right? Yeah. So we skip so we so we are skipping this, right? Yeah. So H is going to be next. H let's see. I'm not even sure myself. Uh but I would agree with you. It's H. And now it's time to unwind the async. Yeah, then it's gonna be F. F, right? H I is already here. So F. How about G? Well, yeah. I guess that's the only thing left. I think it won't be printed out for real. All right. Yeah. Look at look at this. Look at this. So we have the we have the dispatch Q uh main as sync. So basically dispatch tasks and move on. Dispatch the task and move on. So the age is here. So dispatch the task and move on. Uh but then inside that task you're again uh scheduling a next task to be executed synchronously right just in front of your current task because this one is still haven't finished. Remember the main Q is the synchronous Q. It's oh sorry it's a serial queue. Takes one task after another. So until it finish executing this task, it can't start doing this one. So uh and be and because it never finishes this one because it waits for this forever. This is called a deadlock. So basically the G will never be printed and uh uh yeah that's my opinion. Let's take a look. Uh this is not an easy task I would say but let's see what will be in practice and how so a i b d c e h c e hf and as you can see the g is not printed right so just zoom in on this one. Yeah, really interesting. So, uh these are actually uh the questions are asked in the interviews like uh some of the variations of them. You might get a different one. You can get the guardlet question, not necessarily defer or not necessarily dispatch, but the idea is the same. It's some sort of spaghetti code. Uh I wouldn't call it something else. and um and and they're trying to trick you into uh making a mistake with understanding of those intric intricacies let's say like that this is actually very high level questions a very high high complexity questions so yeah how was that for you yeah it was quite difficult the last one definitely is a bit more complex than the first one and I think because this test so much uh you need to learn about the synchronous versus asynchronous scheduling. You need to uh learn about the deadlock and serial and parallel cues. So there is a lot of things to to um to dissect in this question in a way even if it's it looks so simple and uh and the the difficult part is that it's actually quite easy to mistake the sync from async. it looks almost the same like there is one letter difference and you just can like um make a mistake by not looking uh well enough let's say yeah and I think it's quite important to make the code readable also for others yeah yeah so that you know like if the guy leaves the company the other one comes in can I think I think I think this code is unreadable if we have to spend like 10 minutes and if it's asked on the interview is definitely unreadable But it's a good thing to it's a good thing to mention that in my opinion. Yeah, absolutely. But okay, let's go to the next one. So yeah, let's go. Um, could you explain what is MVC architecture and what are their main components? Uh, yeah. So the MBC architecture is actually pretty old and the best way to learn about it is to uh read about the Apple's document and I believe it's actually retired document so it's not supported anymore. Uh so there are plenty of materials if you um there are plenty of materials but the gist of it is that you have a separate classes for uh each of your uh components let's call like that you have the model which is defining the uh data layer and the logic of the app. uh you have the view which is uh responsible for the uh presentation and for the uh user input controls and the controller is actually linking those together. For example, user presses a button, the controller gets that signal, gets that event and then it does something to the model uh and the model somehow um doing some job and then it notifies the controller about the changes. So basically that's the idea of structuring the app in a way. Okay. in and in in iOS of course you have the view and the controller really really closely tied together so that they are view controller uh basically a very very uh let's say uh sandwiched approach and the model is usually uh might be different because it might be a core data model it can be a remote model on the server or something else but um yeah this is usually the architecture of the UI kit iOS applications So is the controller only used for the UI or could it be used for like data fetching and stuff like that? Um no not really. I think if I uh the first which I remember is actually the fetch results controller. I don't know why I'm looking at the objective C but I think that there is a swift version of it. So um of course so the fetch results controller is basically uh having a fetch request to core data basically responsible to preparing the data to be displayed to the table view. So you have like a table view controller, fetch results controller and you combine them together and you basically got your data presenting showing up in the table view and that's more like the idea of this model view controller approach to have the modularity uh that you have the building blocks and you combine them together and uh you have the ready ready making like ready working app and um fetch results controller doesn't have any UI classes in its import declarations because it's just a it's just a uh model controller let's go like that and then there's a UI document which is doing the same job essentially uh model layer model controller layer for uh uh reading and writing documents for the um both Mac and iOS so not necessarily uh UI view controller is the most known one and but uh it's not necessarily that you Yeah. Yeah. You can have the combining roles like for example uh both controller and view roles. This is a view controller. Then there is model controller. So definitely you can have a different as you can see there is like a different controller uh objects and there is not necessarily like a it's not necessarily controls the view and the model. There might be it might the controller can connect together different pieces. It can connect for example multiple controllers like a navigation controller for example. It doesn't operate on the view level mainly operates on the controller level. All right. So how about like when you have modern apps they combine a lot of different content on a single screen. How would you kind of how would you tackle that? Are you going to have like many view controllers like Yeah. Yeah, I think I'll do that. So, I'll just uh uh instead of putting everything into uh one view controller, uh I will uh split the content, I'll split the responsibilities among multiple view controllers. And then I'll use something similar to a child view controller approach. So, I'll add one controller in a way like you add a subview. I'll add the same way a controller on top of each other and have them handle specific responsibilities. Uh and one of the examples is like of course there is a official guide for that uh for uh making a custom view controller but uh there are already so uh many of those controllers like navigation controller is one of the examples and everyone use is using it and split view controller is doing the same job and doing quite a lot of uh work uh by adapting the interface to the iPad and iPhone and split view and iPad. pads. So, uh, without even knowing what's the interface all about, it just has two controllers and coordinates between them. So, I'll definitely go with this hierarchical controller approach. All right, clear. Let's go to next one. So, the weak and unowned keywords. So, where are they used and what are they for? So uh those keywords are related to the uh uh they are related to the memory management. So um if I take a look for example on the UI table view uh if I just go to the UI table view and uh for example data source and delegate are both declared as weak. uh which means that it will not hold uh a reference to the data source. Basically it will just use it, it will query it but it will not hold the memory. So whenever the table view uh whenever the data source has no references outside or if it doesn't have any anything else it will be deallocated and it's usually uh made so because the table us and that's why it has to have let's say usually the controller provides the data and that's why it has to have the delegate weekly held otherwise we have this reference cycle. So usually the uh when the weak is used it's used during the uh reference uh to break the reference cycles and uh unknown is very similar to weak. So in the fact that it doesn't add the uh reference count but um so it will not hold the object strongly in memory but uh the difference is that it will not be declared as optional. So you you you use usually unknown salt unknown salt when when you 100% sure that it will never be um it will never be nil and you just want to like work around the compiler to make it uh to make it um to make it a nonoptional type so that you don't have to like unwrap it all the time and so forth. Usually you can use that in closures for example or yeah if you for example refer to uh if you for example refer in a lazy uh closures in a lazy variable or u just a closure you have to use either weak or unknown so not to create a reference cycle all right usually it's used with usually it's used with the delegates like usually all of the delegates in Apple platforms they are uh they uh connected as weak. So they don't hold the the object they are referring to strongly. So are there any exceptions when the delegate is not held weekly? Yeah. Yeah, there are some exceptions. For example, um there's an SL session. It's a very interesting case. Uh the basic networking object on iOS or URL session is I'll just switch to the Swift version of it. and uh session delegate and the session delegate which is basically an object that receives the events from the session uh it's a strong reference. So you create a session, you set a delegate, but the session will hold its delegate strongly. And this is important because it might have a memory leak uh if you don't remember this specific case. And the task is really simple. I guess the intent was that you just instantiate um this delegate and the session basically handles it. The the only purpose of this delegate is to be held by the session. you don't really uh need anywhere else. That's why it's was designed that way probably because if the table view if you think about table view uh the table is table view is held by the controller and the controller usually is a delegate but in this case like the session is the main object and the delegate is just a um additional behavior that you want to customize. That's why it's okay to hold it strongly. But this inconsistency is really actually quite tricky. And if you forget about that, it's really easy to to um to make some problems in the app. All right. So, always refer to the documentation uh whether it's a weekly or uh strongly held uh property. Got it. Cool. How about the lazy keyword? What is that one help? Yeah, it's an interesting one. Uh lazy is basically a lazy initialization. So that the let's let's take a look at this one. Uh I'll find viewed load for example here for patient view control. I'll create something here. Lazy variable. Um what what could it be? Um another view. So for example, you can use something to add like a customization here. So uh first of all it's really convenient to have something customized. Um like instead of uh if I were to create a lat constant let view two view two it would be I have to have like that have to have it like that and then I have to use a view load to configure it. But here I can just add all of the configurations here. And yeah, so the lazy one is used for um mainly for uh calculating values that you might not need. For example, if you don't want to add another view all of the time depending on the on some conditions. So like if uh uh random you um view adds a view another view. So in this case uh in some of the cases uh when this would be a false the another view will will not only will be added to the uh sub view but it won't even be instantiated. So that will increase the performance of the of the app a bit. So that's one of the uh cases and um another one is that you have some customization here available so that you can sort of add a tags and so forth. So it's really convenient to uh to add something that you will otherwise have to write in the method. So to keep it close here how about can the easy keyword be used on the collection on collections like uh yeah yeah yeah it can be used on the collections too. Uh so if I create an array then I have to create lazy it will produce the lazy sequence and then when I have to when I execute a filter it will um take it one by one basically so or map so it will not uh it will not uh go through each of those uh it will not execute the the whole code for that but it will execute it only when I need the values. So map then map something else. If I do map like that to string just try string in it then map and then double in it. And if I uh take the first this will only um take the first value out of this. It will not map those. It will not touch two. It will not touch three. So if you have a really really huge collection, this will be quite efficient to use lazy on the collections. What if you remove the first? Would it still go through all? What do you mean? If you removed the last method, I I don't know. Probably it should not go through any of those. Okay. I don't know. The only the only way the only way is to run, I think. going to check it out. So probably it will be not even execute because it's just a uh because just like a unused result but let's see trying to figure out what this result is. You can see it's lazy map sequence integer doubles. So what is this result? lazy map sequence optional dowel and the base sequence is three elements right so you have this three elements one two three which are here and the transform which is like combined function which is probably uh combination of everything here and let's try to execute the first so we're getting the double here right so it went through this mh And let's print out the result again. Uh yeah. So we have again I'm not sure if it's actually caching but uh but as you can see it didn't execute anything but it will return you whenever you ask for it whenever you ask for something. Okay. All right. So, let's go to the closures. And I hope it's the last one. Yeah, it is the last one. So, closures, there's those two keywords that always kind of as a beginner kind of made it difficult to understand. And one of them is the escaping key keyword and the non-escaping is the other one. Yep. Maybe there's another one as well, but I'm not sure. But can you tell me about what is an escape enclosure? Yeah, sure. There's a there's another one uh auto closure auto closure, but that's probably a different auto closure. Yeah, but that's in a different video. So, yeah, uh I've added this this simple class here to uh look at the escaping and no escape. So, uh the difference is really simple. uh if you so the f first of all uh the escaping parameter applies not only not really to the closure itself uh but to the closure as the parameter of the function. So um and and what what it says essentially is that you can uh it tells compiler you can store this closure in some variable that's it because if you uh don't have this escaping modifier attribute you you will have to execute it only in the scope somewhere here in the function as the part for example all these UI view UI kit completion handlers they exe executed in the scope. So there are no escaping closures. Uh and of course you can execute the escaping closure here as well. There is nothing wrong with that. Uh but if it's uh a no no escaping closure, you won't be able to assign it. So I'll just uncomment that and I'll get a warning. Assigning a non-escaping uh parameter handler to an escape enclosure. Whenever I try to it's implicitly non- escaping. Uh at some point in swift it used to be the other way around. So the default was uh the default was escaping and you had to add this no escape attribute to um change it. But if I fix it, it will basically add the escaping. Um and uh not sure if I if it still has no escape. No, it does not. So this one is removed. Yeah. Cool. So yeah, escaping is the one you can store in the variable. No escape is the one you can't. And the and it's no escape by default as of Swift 5 something. Okay. So like are there any performance benefits if you kind of do not? Yeah, I think it has to do with the performance uh issues or with the performance optimizations, but I don't know uh the details. All right, cool. But yeah, that was all the questions I had and I think you you know pretty well all of them. So, you definitely passed the interview. That's good. That's glad to hear. I'm gl