Formatting Relative Dates With RelativeDateTimeFormatter
A few weeks ago we talked about formatting content with NSFormatter, an abstract class from which multiple formatting classes inherit from to allow you to format different kinds of data in a human-readable form. NSFormatter is not only a class you can inherit from yourself, but as iOS evolves, more formatters will be added to its family. This week, we will explore a new member of this family introduced in iOS 13: RelativeDateTimeFormatter.
Soon after I published this article, Christian Tietze wrote a fair criticism of this idea here.
Once you understand how property wrappers work, you can use this article to apply it to user defaults. The main idea is that property wrappers allow you to store your values differently and even externally. That said, you may or may not want to implement this in a real app. I recommend you read this article first, and then go back to Christian’s to see more downsides of this idea other than the ones I mentioned below.
Swift 5.1 introduced a sleuth of wonderful features, and amongst them, there’s one that is essential for SwiftUI: Property Wrappers. Property wrappers are a powerful feature in Swift that allow you to wrap behavior along with properties. This allows us to do some interesting things. If you have seen SwiftUI, you’ve seen the @State “keyword”, and you know that it allows you to modify structs. This is possible thanks to the behavior “wrapped” within properties marked with it.
If you have been programming mobile apps for a while, you must have used a web based API - JSON based or otherwise - and you have had to deal with bugs related to your requests and responses to a web service. You have likely asked yourself why some parsing code is not working as expected, or why a request seems to have an invalid format. Intercepting your own network calls with a proxy can help you find the answer to these questions.
iOS has always provided interesting search APIs, but they have always been limited and doing the most interesting tasks required you to either write your own implementation or use private APIs.
iOS 13 has provided some very nice improvements to the UI search APIs. In this article we will talk about two of them.
UISearchBar finally exposes its text field
I have been using UISearchController and UISearchBar for a very long time, and I have always found it bizarre that Apple didn’t expose its underlying text field property. As of iOS 13, the search bar finally exposes it, in the form of a UISearchTextField object.
This article is a continuation to my Common Cryptographic Operations with CryptoKit article. If you want to learn how to use CryptoKit, read that one instead, and come to this one when you need a feature not offered by it.
As I have been playing with the amazing CryptoKit framework in the past few weeks, I have discovered a few more things that CryptoKit currently doesn’t do. This is not generally a bad thing, and I think these limitations are related to what seem to be the goal of the framework:
Swift is a beautiful language, but it hides some powerful features from developers who come from more “old-style” programming languages such as C++ and Java. One such feature is Pattern Matching, and it allows you to write some cleaner code when dealing with some operations.
For example, consider casting. Casting is a feature in the vast majority of statically-typed languages. Casting is considered to be an ugly operation by some, because when you need to cast, it’s usually because the language has a flaw that prevents it from telling you about the right data type underneath. This is specially true when you add in Object-Oriented Programming and classes are marked to return a super type instead of a specific subtype. With pattern matching, you can more cleanly check for datatypes without having to worry about crashes or weird behavior.
Sometimes when you are writing an app, you need to be notified of events occurring somewhere else in the system - either in your own app, or in the operating system - and react to them accordingly. For example, you may be an app like Snapchat and you want to know when a screenshot has been taken. This is a system notification that you can “listen” to in order to react. If you have an app like a photo gallery, you may need to know when the user adds a new photo so you can update all relevant UI and make other necessary updates.
Whether you have been programming for a while or are new at it, chances are you have had the need to search for results in an array. And while Apple’s SDKs for iOS, macOS, iPadOS, and watchOS all use Foundation and have a set of handy tools to make that task easier, there is one particular API that is very powerful but doesn’t get much use unless you pair with other frameworks such as Core Data: NSPredicate.
Apple has always taken security very seriously, so it’s expected that they would provide developers with the same tools they have to help developers implement the same security measures in their apps. This year, Apple introduced CryptoKit.
Apple providing new cryptography tools is nothing new. They have provided the Security framework for a very long time, and a few years later they introduced CommonCrypto. The problem with these frameworks is that they can be very low level, being written in C, and it can be intimidating for new developers to adopt them in their project. CryptoKit abstracts a lot of the details and it provides easier interfaces for common operations such as hashing, encrypting, and even signing.
