MacOS

With Swift 5.5 and the SE-0296 it is now possible to use async / await as in many languages such as C#, Typescript, Javascript or even Rust. Until now we handled asynchronism in three different ways: the delegated as Apple does a lot, closures (also called completionHandler) as many do or with RxSwift or other libraries like Promise. But with the arrival of async / await it is no longer necessary to go through all that.

Have you ever crashed your application on purpose? Who would want to do that? What if I told you that there are tools for that and that it can be very useful, do you believe me? Let’s take a look at it together! assert #If you come from languages like C or C++, assert will be the keyword you are most familiar with. And for good reason, it does exactly the same thing as an assert in C.

The keyword defer in Swift is not often encountered. Especially when you start developing. Nevertheless it has a certain usefulness and can be very useful. Definition #defer is a Swift keyword used to define code to execute before leaving the current scope: func changeTitle(_ title: String) { defer { print("After") } print("Before") myTitleLabel.text = title } At first sight and if we only consider the order in which the instructions are written, we could believe that we will have the following output:

Recently I was confronted with a code where I saw for the first time the keyword class func. And I must admit, I had no idea what it was about. But as usual I remedied the situation and I wanted to share my discovery with you. static func #You should already be familiar with static func. If like me you started with languages like C# or Java you already had the opportunity to meet it.

I’m sure that like me, you have already had strange errors with XCode. What do I mean by “strange”? Well, the error is not clear and does not seem possible. Let me explain. Error #I was developing a new SwiftUI application when I got the following error when launching the application on an emulator: Error: Executable Not found How can the compilation be successful while not finding the executable? Very strange I think.

In a previous article I told you about the keyword @escaping which is very useful in case of a scope change. If you want to know more about it, I invite you to read the article I previously wrote here :Swift: @escaping. But the change of scope leads to other consequences for the values “shared” potentially by the two scopes. Before talking about weak and unowned it is important to go back to some important notions.

It’s all in the title: have you ever had this problem? It’s still very strange. And it looks like this: XCode: Build failed but no errors What’s going on? #After several searches it turns out that if you want to have more information on the errors in question, you have to go to the “Report navigator” which is the last icon in the left sidebar of your screen. XCode: Report navigator As you can see there is much more information here than before.

Last weekend had started as always: I wanted to learn something new. And that day I wanted to discover console applications in Swift. I’ve read a lot of interesting articles on the subject and I’ll be sure to tell you about it in my own articles very soon. If you have already done iOS or macOS development you already know that the entry point is the AppDelegate or the SceneDelegate.

What is a file attribute? #I will probably push an open door, but a file system has attributes on the files. In particular, the read, write and execute of each file and this for the different groups: -rw-rw-r-- 1 kelvas users 5120 Jul 09 04:30 sample.txt But these attributes were not enough for many cases. So an extension was added to the inodes to allow more functionality on the files: the extended attributes or xattr.

As you’ve probably gathered from the previous articles, I mostly do iOS and Android mobile. But from time to time, I go outside this mobile bubble to do other things. The interesting thing about doing Xamarin for mobile is that it’s easy to port our application to desktop environments. But when I left my iOS and Android cocoon, I quickly realized that the tools for desktop development were not necessarily as advanced as their smartphone brother.