Earlier this week I was scrolling through my Twitter feed as usual and I found this tweet that made me realize I may have been handling errors incorrectly in Swift all my life. This prompted me to research a bit more about error handling in Swift, and it turns out there’s many specialized Error protocols you can conform to, and you should probably be using them over the default Error provided by the language. All these specializations conform to Error themselves. In this article, we will explore a few specializations we can use when dealing with errors in Swift.
June 18, 2020 at 10:24 PM EST: I have made contact with a human at Apple after they reached to me via Resolution Center. We are working on solving the issues, and while I have not been told “yes, your account will not be terminated”, I believe in good faith we will work something out. Yes, the issue was my fault after all, but they are being very understanding and are letting me redeem myself by uploading a new binary. A proper update on this issue will come at a later date.
It is amazing what we can do with smartphones these days. Document scanning and text recognition are nothing new. But being able to have such a functionality in our pockets is pretty neat. These days we can create apps that have such features very quickly thanks to the push Apple has been doing to promote Machine Learning and Artificial Intelligence on their devices.
Starting on iOS 11, we can natively scan documents with a system framework called VisionKit, and we can perform operations on images using a framework called Vision. It wasn’t until iOS 13 that we finally had the ability to recognize text on images ourselves using the Vision framework, without leveraging third party libraries. In this article we will explore how we can use the VisionKit framework to scan documents and the Vision framework to detect text as two separate tasks, so you can see how easy these two tasks are and you can learn to put them together.
If you have been using the keychain on your iOS apps you may want to start using Face ID/Touch ID to let your user access your app and their data. This is a common use case but it’s very easy to do incorrectly.
Apple introduced Touch ID all the way back in 2013, and ever since then, every iOS device has come with some sort of biometric authentication method, be it Touch ID or Face ID. This has allowed developers to implement convenient unlocking into their apps to access sensitive data without having to ask for the passcode. If your app “locks” access in any way your users are probably expecting to “unlock” with their finger or Face ID, so it is your responsibility to implement in a way that is secure and can’t be vulnered.
This article is an entirely rewritten version of an old tutorial I wrote years ago titled “Using the iOS Keychain”. Originally written in Objective-C, the old version has been archived but it is accessible here.
The Keychain is the place where you would store sensitive data. As secure as iOS currently is, the keychain is the right place to store passwords, authentication tokens, and other sensitive data. You should not store this kind of data in UserDefaults, even if iOS has made it harder to access that data for normal users in the latest versions.
I wasn’t sure if I should include this article as part of this series. But for the sake of completion, I decided to include it. This article is very short, but it tells us how to actually install our own tool in a system so we can start using it without writing its full path.
To recap, and before I end my series in Swift’s ArgumentParser, let’s give a quick overview of everything we have learned so far:
In the past four weeks we have explored many of the features available to us via ArgumentParser and how to use them. Here’s a recap of everything we learned so far:
In this article, we will not explore a feature exposed to us via ArgumentParser. Instead, we will learn how to do something very essential: Creating tools that require asynchronous APIs.
Writing Command Line Tools in Swift Using ArgumentParser, Part 4: Customizing Help
In the past few weeks, we have explored how to use ArgumentParser and many of its features. It’s great that ArgumentParser provides a lot of functionality for free, but it wouldn’t make sense to build great tools that users can’t figure out how to use. This week is all about that.
We saw how ArgumentParser can build a lot of documentation for free, but we can actually do more. This week, we will explore how we can improve the documentation generated for our command line tools.
Last week we explored how we can build a simple command line tool. We learned how to use @Argument, @Option, and @Flag as the building blocks for ArgumentParser command line tools. We we saw last week was enough to build many simple tools, but there’s still a lot to explore, and cool things to learn.
This week we will learn about input validation and errors, so we can build better tools that take more constrained parameters when relevant.
