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.
Vibration and physical feedback has become an important feature of Apple’s operating systems. Starting with the Apple Watch, Apple replaced the traditional vibration feedback with haptic feedback hardware, which allowed them to have more control over how vibrations and physical feedback work.
First being introduced in the Apple Watch, Haptic Feedback has been a core part of the Apple ecosystem experience since. Just think about it, wouldn’t it be weird if you force-touched the screen to do something, and there was no physical response from the device? Think of the old Peek-and-Pop. If you updated to iOS 13 and got context menus, you may feel they feel great to do in iOS (because they have a haptic engine), but on iPad they feel lacking because the device doesn’t vibrate when triggering them.
Very often, we need to deal with data in a “raw” format that, if displayed directly to the user, it makes little sense to them. This kind of data includes a date timestamp, the number of bytes in a big file, or numbers with no rounding a bunch of decimals. There is a lot of data like this, and we need to be able to format it and show it to the user.
On WWDC2019, Apple decided to fork iOS into two different operating systems: iOS for iPhones, and iPadOS for iPads. This is to recognize the iPad as its own independent entity that has its own set of features compared to iOS. Amongst those features, iPadOS adds Multiwindow support, which allows our apps to run in more than one Window at the same time.
What exactly is Multi-window support, and how does it work?
iOS 9 introduced the Slide Over and Split Screen features for iPad, which allowed us to run two different apps side by side at the same time. Multi-window support on iPadOS allows you to do this with two windows of your own app, and more.
Error handling when expecting a result out of an operation is a very common thing to do. For this reason, various high-level programming languages have introduced a Result type into their libraries, on top of their existing error-handling features. This feature was implemented in Swift 5.
A Result wraps a success or a failure. It is essentially an enum with two possible cases: .success and .failure. The .success case wraps the correct result of an operation, whereas a .failure wraps an Error. Its implementation uses generics, so you always know what you are going to get back.
If you have been programming for Apple platforms for a while, chances are you have seen (or maybe even wrote yourself) a line of code that looks like this:
Whether you wrote it yourself or someone else did it, one thing is clear: This is not a safe way to build URLs. Can you know, for sure, that your URL is actually valid? Intuitively, all of us can see a URL and see if it’s valid, but there is a whole lot of governing in the URL format that at some point we may find funny URLs that look valid and aren’t, or the other way around; they look invalid, but aren’t.
