I have a cold, a CFP accepted and a newsletter mention.

Jeroen Leenarts: Hi, welcome to the 69th episode of my podcast. My name is Leenarts. And I've been developing software for over 20 years and I'm developing iOS app for over 10 years and I'm running the Dutch Cocottes. For over nine years. If an iOS app developer, you should listen to my podcast because it will keep you updated some interesting articles, conferences and events you might not have heard about. In this episode, I'm going to talk about working with Xcode configuration files, native network monitoring in Swift. A few examples of async await is swift. dynamic linking is bad for apps. And static linking is also bad for apps. And the final article will be where Mac catalyst falls short. Maybe you can hear it I don't know yet, because haven't done the processing on this audio yet. But I am dealing with a mess of gold. So I was hoping it would be a little bit better today. I'm actually recording on Tuesday. But yeah, it's not, it's not much better yet. So we'll just make do with what's possible. And try and make sure that everything sounds as good as possible. A lot of things are going on, as always. So I'm still looking into whether or not I'm going to do a Twitter space on Wednesday, because my partner in crime is out of operation for a little bit. So I'm hoping he's doing well and getting back on his feet quickly. Again, also, the work continues on creating new content is, is also progressing. And I have a nice announcement soon. I will be presenting at another conference in May. But I'm not at liberty yet. To share which specific conference this will be. What I can share is that it will be about my book being a lead software developer. So really looking forward to this one, because it's it's a topic that I spend a lot of time on thinking and writing about. So once I am at liberty to share when and where this conference will be, I will make sure to mention to my podcast. So let's just dive in into the first article working with Xcode configuration files, it's by Natasha for Deva, it's a nice overview on how you can use configuration files within your Xcode projects. Of course, there's a little bit of setup that you need to do. But as Natasha indicates, it's very easy to tweak some settings within your app once you've detected initial setup. So definitely worth checking out. And if you're not using xe config files in your Xcode project yet, then after reading this article, you might think otherwise and start doing it. The next article is by REM Sharda at Digital banker dot deaf. And what's an interesting read because what he does is suggest that you don't use reachability API's within iOS but that you actually use network path monitoring. And network path monitoring is a new API that became available in iOS 12. So relatively new, of course, but it's a great replacement after reachability API's that are much lower level and also the reliability of the leachability API's has always been up for grasp, because Apple indicates themselves if you want to check network conditions, just try to request because that's the best way to figure out whether or not your resource is reachable or not. The NW path monitor API is a sort of an observer that you can instantiate, and that you can configure to give you signals at specific network condition changes. And in his article does a nice overview of how you integrate this API within your app and how you can use it to have reliable network monitoring set up in your code. The next article is by Thomas Fatar. A few examples of async await in Swift. And yeah, it's just a nice neat overview of how you can use async await in your code. It's just a nice reminder, again, of the things that you can do with async await. Yeah, so also, if you want to do an exponential delay, that's a nice sample in there that you could use in your code. So yeah, it's just a nice reminder. And that's, that's why I'm including this article. And in general, I really liked the articles that I was writing, because they're well written. And yeah, it's just good to see that. It never hurts to repeat specific contents that has been written about before, at least, if you put in your own take on things. The fourth article is by Jordan Rose. It's has a long title. dynamic linking is bad for apps. And static linking is also bad for apps. It's an article that he wrote based on a recent question on the Swift forums. And basically, what he talks about is that there's basically four kinds of libraries that your app can use the libraries that come with the operating system. So that's from your operating system, vendor libraries that come from someone else and can installed in a shared location, so many apps can share them. colors that you ship alongside your app that are only used by the app, and libraries that are loaded dynamically by the appetit. These are called plugins. So he's going to focus on the third category. So that's libraries that ship alongside your app sets that are only used by your app. And yeah, basically goes down by static linking and dynamic linking is good or bad in the case of library included the pitcher app. It's a nice, thought provoking piece. Yeah, I'm really curious to see What people think, once they've read this article, and then the fifth and final article of this week, that's by Steve Troughton Smith. It's called where Mac catalyst fell short. And Steve is, of course very known for the work that he does on iOS code basis and bringing grim data to the Mac. And he has some thoughts on what are the good and bad things of Mac catalyst. So if you don't know, Mac catalyst is basically an integration layer that you can use to bring your UI Kit based enemy applications into the Mac ecosystem. So it's, it's sort of easy in routes of porting your iOS app to the Mac. Of course, there's massive differences between the Mac and iOS platforms. And this leads to some sort of conflicting situations that make that catalyst is probably not always the best fit for your situation. But quite often, you can just work around things by using some smart thinking and using the available API's within Mac UI kits in a in a creative way. Still, there are things that are typical for Mac catalyst apps, and in his article, as Steve goes over all the things and the gripes that he has with porting UI Kit app to the Mac with Catalyst. But overall, his agreement is that Mac catalyst is in a great place, it has improved substantially over the years since its introduction. And for most developers, it's by far the best way to build a great Mac like universal app that runs across iPhone, iPad, and Mac. It's hybrid nature allows the developer to pick and choose which elements of UI Kits fit UI and app kits, you need to achieve the experience that you're looking for, for end users. So you could really go into one direction, or try and combine the best of all these three worlds. It's, it clearly has a lot of traction within the apple's product teams. And yeah, I think it's Steve thinks that it's an enabling technology. For example, messages, maps, podcast, find my apps and playgrounds, books, voice, memo, stocks, home and news. So actually, it's a framework that is having a lot of traction within apple. And yeah, it's, it's something to consider if you have an iOS app, and you're looking into porting it to to the Mac or having your product to fail on the Mac, to just have a look at catalyst because it could very well be very easy in route to the Mac platform, to at least do your initial explorations and even have full fledged Mac citizen app based on catalyst. And if catalyst does not work out for your situation. If it gains traction, at that point, you can of course do a full on App kit based app. A big shout out to budget newsletter swift UI weekly, because my previous episode on my podcast feed got mentioned in this newsletter. So we did thanks a lot for that. And to our listeners, definitely check out his newsletter because it's on my weekly list of things to read. I will put a link to his newsletter in the show notes. That's it for this week. Keeping it short because my my voice and my my cold is really hurting me right now when recording. So talk to you again next week. And yeah, stay on the lookout for the next interview that I will be publishing on Thursday. Thanks for your time, and if you have any feedback, just let me know. Send me a message on Twitter DM and I'm always happy to respond to any questions or suggestions that you might have