This article was originally written creating examples using Xcode 13 beta 1. The article, code samples, and provided sample project have been updated for Xcode 13 beta 3.
Understanding async/await is a pre-requisite to read this article. If you aren’t familiar with that concept, feel free to read the first part of this article series: Understanding async/await in Swift.
This article was originally written creating examples using Xcode 13 beta 1. The article, code samples, and provided sample project have been updated for Xcode 13 beta 3.
To better benefit from this article, you should be familiar with async/await. If you aren’t, feel free to read the first part of this article series: Understanding async/await in Swift.
This article was originally written creating examples using Xcode 13 beta 1. The article, code samples, and provided sample project have been updated for Xcode 13 beta 3.
Before you try to dive in with concurrency in Swift, you need to understand async/await. There’s no way around it. While async/await are not the only concurrency options, Apple’s SDKs are starting to make heavy use of them. There is no doubt that third-party library providers will start offering these as well.
This article series was originally written creating examples using Xcode 13 beta 1. The articles in the series, code samples, and provided sample projects have been updated for Xcode 13 beta 3.
This is a tutorial series focused on the new async/await APIs Apple introduced in WWDC2021. I do not know how many articles it is going to have yet, but they will be posted in the upcoming weeks.
This may sound surprising to you, but even though we have app autoupdate on iOS now (and we have had it for a very long time), many people don’t have it on, or the system simply doesn’t prioritize app updates because users don’t prioritize it enough. In fact, in my day job, in which I maintain a user-facing banking app, the vast majority of users are not even in the latest version. The most used version is the one we released in April, and we average one release per week for bug fixes alone, and about monthly for major new features.
As SwiftUI is still relatively new, and it is not clear yet for many people how to use MVVM on iOS, I decided to write this short article in which I explain how one would integrate Face ID/Touch ID with SwiftUI.
Let’s remember that SwiftUI uses the MVVM design pattern over the traditional MVC, and this can be confusing for people who are migrating to the new pattern for the first time. That said, the main takeaway from this article is to understand that views get destroyed and rebuilt very often in SwiftUI, and therefore the right place to write this kind of logic is in the ViewModel
Software development can be an easy thing, as it can be a very complex thing. And one of those complex things is keeping in mind all the different languages, locations, and standards users may use in their daily lives. This makes working with certain information. From different date formats to entirely different measuring system, software is challenging, especially when working with anything that requires localization. The situation is just so bad that a lot of software just make assumptions about their users environment and don’t let you change any settings.
SwiftUI forces us to change our way of thinking when building iOS apps. It makes us change from writing our apps in MVC to MVVM.
In this article, we will explore how SwiftUI can be used with certain frameworks that aren’t “SwiftUI ready”. While this article uses CoreLocation as an example, keep in mind that you can use what you learn from this to integrate almost any other framework with SwiftUI, whether it is provided by Apple or not.
Every iOS developer has used the simulator. Alongside Xcode, it’s probably one of the most used tool by us all. We use the simulator to test our iOS, iPadOS, and watchOS apps without having to run them in an iOS device.
But other than helping us test our apps, the simulator actually has many nice features that can help make our job a little bit easier. With the use of these features we can avoid using physical devices until it’s time to do an actual test run or one.
We have reached the point in which computers are really fast. Especially Apple’s, as they have control of both the hardware and software, so, oftentimes, some tasks that could be sped up with multithreading, are not necessary anymore. But, for those cases when you do need multithreading, we have many options available.
On Apple’s platforms there is a surprising amount of concurrency tools. You are likely familiar with the most used one, the Grand Central Dispatch, DispatchQueue, which is pretty good and it covers the vast majority of use cases. But there are some tasks that can be done easier with other tools.
