KeyPath. It sounds like a very fancy word. And it is a feature you have likely used it, either knowingly or unknowingly. KeyPaths are one of my favorite features in Swift, but they can be a bit tricky to understand. In this article we will explore what KeyPaths are, and when you may want to use them.
Understanding KeyPaths
In simple words, a KeyPath is a reference to an actual property instead of a value.
There are times in which you may want to host small JSON (or other small types of files) somewhere because your app needs them. Maybe you want to configure feature flags, or maybe you want to host IAP identifiers somewhere so as to not hardcode them in your app. This last case is something I did recently.
The immediate thought will be get a cheap server somewhere - after all, using something like Vultr you can get cheap hosting for as low as $2.50 per month. But did you know Github allows you to publish static websites, and you can piggyback that on that to store remote “config” about your apps?
If you have been writing Swift in the past couple of years, you have probably been using Codable (which is really just the composition of Decodable and Encodable in the same protocol).
If you have been writing iOS apps for longer, you likely know about JSONSerialization as well, which is the backbone of Codable and it allows you to do more manual work when parsing JSON, seemingly giving you more control.
If you know JSONSerialization, you have probably found times in which Codable seemingly doesn’t give you the flexibility you need, and you may have been tempted to drop Codable in favor of JSONSerialization when parsing very specific or even corrupted JSON.
I had announced that I wouldn’t be able to write an article this week due to it being Elections Day in my country. that said I just can’t leave you guys without article, so this is a short one.
We will write another NSFormatter subclass. It will allow us to compose E-mails easily. This should also help show that formatters can format string into anything else really.
In short, we will be able to “compose” emails using raw strings, like this:
NSFormatter is an abstract class. All formatter classes inherit from it. In Swift, everything we need about it is open, so we can create our own NSFormatters with ease.
Sometimes we may be interested on how well our app is performing out there in the world. After all, our apps may be running in different environments that are hard to test or that Instruments may not catch.
For this purpose, Apple introduced MetricKit back in WWDC2019. MetricKit allows us to aggregate and analyze this benchmark data on a per-device basis, and not only does it include information on performance and battery usage, but also on exceptions and crash reports.
A year ago, we talked about using NSFormatter for formatting data in a human readable format. WWDC2020 brings some updates and changes to the NSFormatter APIs that we need to be aware of. This article will complement the NSFormatter article from last year with best practices and things to look out for.
Improvements for Combinations of Languages and Regions.
NSFormatter always does its best to format the data according to the user’s language and region where relevant. Apple is improving the combinations for this because it’s highly common for people to set their phones in a language that is not commonly used in a given region. This is pretty exciting for me, because I live in Bolivia where people speak Spanish, but I have used my devices in English for as long as I can remember.
Translating our apps in different languages helps us reach wider audiences of different cultures. This reach can increase our app usage considerably and offer more monetization properties.
In this short article we will mention the features Apples gives us to translate our apps to different languages, namely NSLocalizedString and and stringsdict files. You will also understand when you will want to use each, as they have different use cases and an app that takes localization seriously will use both.
While CryptoKit still doesn’t offer many algorithms and functionality, it’s still growing, and this year CryptoKit and do more.
HKDF
Key derivation functions have been available from day one, but it wasn’t possible to derive keys independently. It was only possible to do so if you were using elliptic curve key agreement protocols.
To do this, there is a new HKDF object with static methods. One such method is deriveKey with multiple overloads:
In this article we will talk about actually logging messages, how the framework is “smart enough” to strip out sensitive user info by default, and how we can control what gets stripped.
Logging Messages
The framework supports interpolated strings right out of the box when you are using the new system in Swift.