You can check out the links to everything you see in this show in the github repo. The link to the repo will be in the description and, as a quick note, i started creating bundles for my courses. So if youre interested in those topics, you can get multiple courses at the same time for a pretty decent discount. All right lets set up the rundown and get into the show to kick things off. We have the latest project from dave verwer, who runs ios, dev weekly, very popular newsletter, check that out, if youre not signed up for that, but here we are ios dev jobs. Another thing you can sign up for to get notifications its also a mac app and an iphone app again. I know im plugging this, but this is not sponsored or anything like that. I just thought its a cool tool for those that are looking for a job, and i know much of my audience is out there trying to get that first ios developer job, so heres a nice way to get notified of a bunch of new jobs. Uh that have been listed right. You see ios engineer at epic. Theres no notion, i believe, is on here as well. There was amazon, yep, theres notion, so all kinds of different ios developer jobs, if youre in the market, definitely a great tool for you to check out next up. We have creating slick, color palette, apis from joe fabis fabasevic.
Now he talks about writing maintainable code and building maintainable systems that you can transfer from project to project and color. Palettes are a perfect thing that you know once you set up once it is nice to take from project to project. Now, of course, the colors are going to be different, but were talking about the structure that is set up in this article that, i think, is very handy. So, of course, i wont go through the whole article, definitely check it out, but ill give you the highlights. So essentially were creating a new asset catalog for color palettes and then down here uh, you see a whole bunch of different colors for light and dark mode and on the left is probably too small to see on the video but definitely check it out. All of these colors are named generic names right background, all background main primary quaternary secondary tertiary text, alt text primary. So the reason you name them. Generic names is because, like i said, the colors you know are going to change from app to app, but they can always be named the same right because its always like that design system right, youre always going to have like a in my apps. I usually have like a brand primary brand secondary that kind of thing and again, if you name them generically, you can transfer them around because, as we scroll down, you can see were going to be getting into the code and how you access them.
Well, if the names are all still like background, all text primary whatever color you change up here, you know in your color palette its relevant, its all its all going to map. You know to the same thing, so all you have to do from a new project. Is change these colors here in the asset catalog and everything is set up good to go in your code and you can access them uh very nicely and easily, as he shows down here at the bottom, keep scrolling yeah here. It is where you know you put them in the environment in swift, ui right, you have your color palette, environment value, and then you, just you, know, palette dot, primary text or palette dot, background main or whatever and again. The idea here is to have a system that you can transfer from project to project where all you got to do open up your asset, catalog change these colors around and then you access them the same way you did in all the other projects. So again, i like the idea of this reusable system that you can transfer from project to project moving on. We have confirmation, dialogues and swift ui by majeed here and ive, been using these a lot in my latest projects. Ill show you that in a second but heres heres the code, you can check out the article for that uh. What are they, though, heres the image right this little action sheet at the bottom? I like these a lot better than you know, showing a system pop up like when youre deleting an object in your app, and you want to say: are you sure you want to delete this rather than showing like the system alert that takes over the whole screen? I like this little slide up at the bottom, but i especially like it on the ipad, as you see here, where the confirmation dialog appears as a pop over and it just fits nicely in that ipad environment in the screenshot youre.
Seeing i used to have like the typical system alert pop up. That said, are you sure hit yes or cancel, but then i switch to the confirmation, dialog – and i like this – look a lot better and ill be using these confirmation dialogues all throughout my app rather than system alerts. You know when it applies, so i definitely wanted to share this article by majid, showing you how to use them in your app next up. We have an article from federico of five stars blog every swift, ui environment value explained now. I recently did a video basically introducing the concept of environment values and i showed a couple different examples using dynamic type and you know dark mode light mode, and the point of that video was just to introduce the topic well again. Federico goes way: deeper. Every environment value explains so what i recommend, if youre not familiar with environment values, watch my video to get the introduction into like what they are and then, when youre ready to do the deep dive into each. You know single environment value and what it is and how to use it. Federicos got this great uh, blog post for you, and i appreciate that he grouped them right. You know generic component values youll scroll down here, like display values like i said, we use dynamic type size uh in my video, but theyre the group nicely with examples and explanations on how to use them.
You know view specific values that kind of stuff. So again, its a very long in depth, article that goes through every single environment value. I know im scrolling kind of fast, but the point is to just point you uh in this direction, so you can check it out for yourself. So, like i said, check out my video for the introduction and like what they are and like how to use them and then the deep dive. This is a great resource for all the environment values. The next topic i want to discuss is near and dear to our hearts and that is force unwrapping. I originally had this image in the lol section, but i thought it was a good intro to the force unwrapping section you can. You can read the meme pretty pretty funny, but uh. The discussion that i wanted to share was a tweet from matt here that says i dont understand why forsen wrapping has such a negative connotations in swift uh. Its almost always uh demands less thought from the reader than an if let no guard, whatever all the different ways to unwrap optionals its just a concise precondition statement and theres a great great discussion all in the replies. So i highly recommend you check out this thread and read through the discussion. I wanted to share this because, especially among developers just learning they may hear like never ever force unwrap that fortune rap is always bad, and that is a very pervasive uh meme.
I guess throughout the ios developer community and i will say that, like 95 of the time foursome rapping is bad but anytime you hear an absolute like. Never ever ever, you know, theres probably always exceptions. So i guess i wanted to share this and share this discussion in the thread for those that may be subscribing to that. Never forsaken rap thats, always bad, because somebody told me that when i was learning and my take on it is unnecessary force unwrapping in those that certain situations where, in my opinion, its fine to force unwrap. If you just force and wrap everything all willy nilly. It does clutter up your code with all the ef lets guard and all you know, just following that control flow makes it harder to read than a simple you know, force and rap now, again, im not saying force and wrap everything. Of course not. Let me repeat myself: uh force unwrapping is bad idea, probably 95 of the time, so you should probably default to unwrapping them, but i wanted to share this great discussion in this twitter thread to maybe get you away from that absolutist state of mind of never ever Force unwrap, i dont know why i just heard thats a rule, so im never force unwrapping, think about it. There are certainly times where its better to force unwrap and again. This thread is a great discussion on that topic, and a great segue from that topic is this: article from antoine van der lie: unwrapper, throw exploring solutions in swift, and even though we were just talking about unwrapping optionals and all that stuff really the point i liked About this, article was exploring solutions in swift and well well get to more of that in a second.
But the story here is antoine: uh was exploring different ways to unwrap her, throw like i said, and he was exploring this thread sc0217. The unwrapper die operator that ultimately got rejected, but going through that thread – and you can click on this article and dig into that. If you want, he got to see many different approaches. Many different methods to solve this problem and thats kind of what hes talking about exploring different solutions in swift. So the example he talks about is, you know, unwrapping an optional and throwing an error in the nil case and how you can do that right so see. Exploring solutions for throwing an error on nil right, you can uh use a closure and he gives the example there by the way im going fast, because this is not about how to do this right. You can read the article for that. The point im talking about is exp how you explore these solutions right, you can either use a method, use a custom, no coalescing operator, which is ultimately what he did, but this is a controversial solution and another reason why i wanted to talk about this is: there: Are many different ways to do things in programming and you may hear again back to the never force unwrap thing you may hear all these rules, but remember your code base your product, your problem, your team. That is all unique to you. So, just because someones general solution, you know, may tell you not to do this.
It actually may work for you so thats. What hes talking about with this custom? No coalescing operator right. Many people dont, like these custom operators in swift theres, like a high learning curve, for example heres the operator ill, show it to you in code down here right. You see it here like imagine. If youre new to a code base and youre just used to swift, and then you see this operator, youre like what the hell is that i dont know what that is right, its a high learning curve so thats. Why people may not like them, but, like antoine says he prefers it? He likes the compact and the readability of it, but the caveat here its up to you to decide whether you, like operators or not in this case, to share you my opinion. He loves using them yet. I also have to agree with my colleagues before implementing this into our projects. Again, if your team agrees on a certain style, a certain method of doing things, great go for it as long as everybodys on board and thinks thats the best solution for you in your code base, so that was a little mini rant again. The main lesson of this article and i wanted to share it, and i highly recommend reading it to read through the examples, is you know what he says in the conclusion right: exploring various different solutions and seeing other way people approach things and why they like that Solution or why they dont, like that solution hearing all that, like you said, makes you a better engineer and youll find solutions written by others will inspire you to improve your code right.
Even if you dont end up using those other solutions, you still learned a lot and, like you said it can inspire you to come up with your own solution. So exploring various different options is a great idea in swift, since were pretty much just professional googlers like thats, really all we do all day. I wanted to share this thread from chris here right. If you use it right, google is the most powerful tool in the world, but the truth is most people suck at it. Improving your googling skills as a developer will be very beneficial to you in your day to day job so heres, eight googling tips that you probably dont know ill just go through a couple of them. So if you put the search term in quotation marks, it will give you exactly that right, not just like partial or you know, fuzzy search results, if you will right dashes, will exclude a term right if youre searching for dolphins and you want the animal you dont Want the dolphins football team, like he says here, you can do dash football to exclude that and thats great, because sometimes programming terms are also like real life terms and you get mixed up search results so thats a way to like uh, eliminate certain words you can Use a tilde if you want you know synonyms for that word. He uses classens lessons coaching again, just im not gon na go through all these theres a whole bunch of great googling tips that will help you in your day to day because, like i said, thats what we spend most of our day doing moving on, we have A great blog post from omro here it says software engineering, isnt magic, and i have this conversation a lot when im teaching people how to code because oftentimes people that are just learning you know they may ask somebody more experienced or more senior than them a question And the more experienced engineer comes back and just says, bam heres, the answer – or at least they point you in the right direction.
Right, because every problem you know is unique for the most part and the the junior person or the person just learning how to code. Like thinks its like magic wow, this persons so smart, they they know everything they. I will never be that smart and what they dont realize – and i say this all the time is the reason that more experienced engineer knows. That is because one theyve either done it. A thousand times its something like a a common table view issue or something or it is a relatively unique problem, but theyve encountered a that problem or a similar problem before and they banged their head against that problem. For you know weeks, and then they finally solved it right and then now they know that theyre never gon na forget that uh so thats why it seems like they know. It is because theyve gone through the struggle right and then learned it ill. Give you a quick example of something i just did like two days ago, so i was having issues in my latest app with core data drag and drop and getting swift, ui updates to trigger, like that kind of, like combination, kind of a you know, niche problem To have well, i was banging my head against that problem for like two straight days, i was dejected. I hated life at the moment, like you know that feeling right where youre just so frustrated, right, youre hitting that roadblock banging your head against the wall and then finally, i got through it and to be fair to myself im.
You know, im, not a core data. Pro im just kind of like really getting into the weeds of core data, but anyway i finally like solved that problem, but because i went through that emotion of like banging my head against the wall, hating life like being so dejected and then i finally got through It now, if someone asked me a core data, drag and drop type question and how to handle that im, gon na kind of know, the answer or point them in the right direction really quickly and that persons gon na think im a genius and like no im. Not a genius, i couldnt figure the problem out for two straight days. You know so thats why i know it, but that is why software engineering isnt magic 99 of the time. If a more experienced engineer knows an answer quickly to a seemingly tough problem, theyve either done it a thousand times or theyve gone through the struggle to learn it and going through. That struggle is really how we learn – and i say this all the time learn to embrace that struggle, because again thats, where the, if theres any magic right. The magic of learning happens in that struggle, but yeah software engineering, isnt magic weve, just all gone through hell to get here. Moving on to ar corner to kick things off, i want to start off with this thread from andrew hart about how apple has been like building in public with their ar and weve been mentioning this.
You know throughout previous editions of swift news. You know with things like app clips, you know many people arent using app clips in their app. But to me that is a very clear ar feature right when you have glasses looking at app clips thats what those are for, not necessarily on the phone but heres more examples of that right. Swift ui is a way to describe the ui without writing layout code, which magically constructs your ui across any form factor that could reduce the need for building like a brand new interface for ar you know, swift only frameworks are super lightweight uh. They kind of shifted to reality kit, as he says, you know, replacing ar kit and thats a ar first developer: api apple silicon, which you know, powers small devices again app clips. Like i mentioned, if youre really paying attention, you can see apples ar plan like slowly taking shape over time, and i thought that was an interesting thread uh to share, but now lets get on to the acid trip that is ar voxelize ar so basically turn your Real world into uh minecraft, i guess well see coming up here. Yeah you can just like pixelate everything ill fast forward, a little bit. Um yeah! You can see everything get pixelated around you if youre into that sort of stuff. Again, i think ar kit is like a giant acid trip. You see you just put a lake in your room, i dont know with koi fish in it, whatever all right again, its gon na be really really uh.
Trippy. Last episode, i didnt include any lols and i got a few comments on that. So uh here you go, you asked, for it got a bunch of them for you uh me when im coding in front of someone yeah pretty much right, weve all been there. I id say i cant tell my name if im trying to like type in front of someone, i hate people watching me like code hate it and thats, usually uh how it ends up next up: uh airpod man again, this is just mimi chuckle right. I dont know those funny ill go through these pretty quickly. Uh ed sanchez says uh. What do you think of this quick little design? I made engineer weve all been here right, talking designer engineer nice, but what if the user is offline, has accessibility type on isnt landscape is russian, but is in brazil has a broken thumb, holding a martini in one hand while running from wool. You know, of course he gets crazy, but the point is oftentimes. You get a nice perfect design that doesnt handle any of the edge cases and its up to you as the engineer to figure that out so its as funny as this tweet was its also like disheartening, like ah thats a rough part of being an engineer. There is dealing with all that stuff all right. Next up, uh, we have another tweet here with a little bit of wisdom in it right.
The junior says: lets use a for loop. The senior says this is an array of function, pointers where we substitute a compute. Whatever some crazy, convoluted, very clever, uh answer, staff engineer, says: ah lets just use a for loop and then the principle heres, the punchline right. Have you considered eliminating this feature and oftentimes people dont? Consider you know theyre so caught up in how to solve the problem. They dont think big picture enough to be like. Why do we even have this problem? Do we even need this? Like that kind of thought, and down here you know eniko agrees right, im all for removing features, companies and developers should do that. More often – and i agree and its kind of funny right, our job is to write code, but i think weve all been there. One of the most satisfying parts of our job is deleting code, ironically enough, so anyway, something to think about. Next up, we got oh yeah, the old uh, if youve dealt with a lot of you know, rest apis youll see this right where the server returns the status 200, which usually means everythings, okay, and then within that message you get the error. You know, rather than just passing you back the bad status code, uh yeah. I know many of you have felt that before so that one gave me a good, laugh, uh. Next up, okay, yeah, im, sorry, i cant im busy that day and its funny.
How just one call can ruin your day right because you you know, maybe you have lunch before the call and you spend a little bit of time prepping for the call youre like well. I got ta prep for this call, so i cant really get into my engineering work and then you know maybe the call goes from two until 3, 30 and youre like well now its almost four might as well, not start something the days almost over and that One call at like 2 p.m, completely ruins your day, so be careful as an engineer on, like you know, accepting these these meetings, i understand you may have no choice, but you know try to push back and schedule it for a time thats, not right in the Middle of your day, because it basically just ruined your whole day but yeah that one again that one made me sad because its so so true and then finally uh adding more people to a project. The good old, classical mythical man month right whats, the estimate a month. What, if i had one more engineer, itll, be two months confused. Look if we had a pm trust me, you dont want to know, and yet more often than not throwing more people at the problem actually slows it down, rather than uh speeds it up.