It’s no longer news that SwiftUI is part of our iOS developer ecosystem. We have more and more opportunities with this technology and it’s high time to project ourselves with it.
So when we create a new graphical component, we always ask ourselves: do I create it in SwiftUI so that it’s compatible with the future? Or do I do it with my good old UIKit to make sure I’ve got everything right?
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.
Do you know the @escaping statement in Swift? The compiler creates an error asking you to add it but you don’t know why?
Don’t worry, we’ll figure it out together.
The notion of asynchronism # With the latest versions of Swift, it is possible to use the async and await keywords to handle asynchronism in our application. But if you have coded applications with older versions of Swift, you probably use closures/callbacks for your asynchronous methods: