Beyond the sandbox: using app groups to communicate between iOS or macOS apps

Apple’s “app group” technology allows a collection of sandboxed macOS or iOS apps from the same development team to all communicate with each other, coordinate functionality, share resources, and/or minimize redundancies. Notice that I said that I can get sandboxed apps to communicate with each other. But isn’t sandboxing a security mechanism meant to keep apps isolated from each other? Yes and no. Apple realized at some point that it would allow apps developed by the same team, with the same Team ID — built by the same people and thus hopefully less risky — to intercommunicate. I’m glad they did as the usefulness of app groups outweighs the dangers.

As long as all developers involved in creating apps meant to be part of an app group can securely share a Team ID from an Apple Developer portal account, they can write apps that can transcend sandboxing. A company may carefully decide to share its Team ID with a trusted partner company, not just with different teams within its own organizational structure.

Member apps of an app group share access to a special group container, a shared folder structure, whose root folder has the same name as the app group ID. In the macOS sample app that accompanies this tutorial, several apps share a preference stored in a .plist file that lives in the special group container. The preference is the background color to be used by app group apps’ UIView instances. If one app sets (writes) this shared background color preference to, say, the color green, other app group members read this preference and can change their view layer backgroundColor property to NSColor.green.cgColor. By starting an app group, I’ve created the beginnings of a group of related apps sharing — centralizing — settings like view color scheme, even if all the apps are sandboxed.

Continue reading “Beyond the sandbox: using app groups to communicate between iOS or macOS apps”

async/await – A core construct of Swift 5.5’s new concurrency model

I first published this article on appcoda.com

The goal: readable asynchronous/parallel code

In designing the async/await construct, Apple is hoping to increase the readability, and thus maintainability, of implementing concurrency/parallelism in Swift. What I see in it are attempts:

to make asynchronous/parallel code almost look like synchronous/sequential code; and,
to make asynchronous/parallel code much more semantically clear (more readable, less verbose, compact, doing what it says).

These are laudable and ambitious goals, but I’d say Apple’s heading in the right direction. I’m glad because I write a lot of asynchronous code to keep my apps responsive — to create the best possible user experience for my customers. I have a feeling that most of you write a lot of concurrent code, too.

We’ll walk through how to use async/await in detail, but I will limit my discussion to it. You need to understand async/await before trying to use Swift’s other new concurrency features, like actors, continuations, the AsyncSequence protocol, the TaskGroup generic structure, task cancellation, and a few other concepts.

Continue reading “async/await – A core construct of Swift 5.5’s new concurrency model”

Using the Swift 4.2 Timer class in Xcode 10

Developers often need to do something many times and at regular intervals. One common application of such a use case is checking some process’s or device’s status, a technique called “polling.” In this tutorial, I’ll show you how to use the Swift 4.2 Timer class in Xcode 10 to repeatedly perform a simple task, every second, for 1 minute (60 seconds) — and update the user interface (UI) on each “tick.” You’ll learn how to start a timer ticking, pause it, resume it, stop it, and do something on each tick. Here’s what we’ll create during this tutorial — and the source code is available for download from GitHub:

To emphasize that the UI remains responsive when a timer is used judiciously, I added a UISlider to my storyboard and tested my code. Here’s the result:

Continue reading “Using the Swift 4.2 Timer class in Xcode 10”

Swift 4.2: How the weirdest error message led to reimagining implicitly unwrapped optionals

In this tutorial, I’ll show you how researching and learning about the current programming language you’re using (i.e., Swift) can lead you to new discoveries, a better understanding of the language, and becoming a better problem solver. Recently, I ran into a Swift error that at first had me scratching my head. The error had to do with implicitly unwrapped optionals. My debugging and contemporaneous research led me to the little-known fact that, in Swift 4.2, a proposal “to remove the ImplicitlyUnwrappedOptional type from the Swift type system and replace it with an IUO attribute on declarations” was accepted and implemented. Despite the fact that I followed and covered language changes leading to Swift 4.2, I missed this seemingly innocuous but nonetheless prescient modification.

Continue reading “Swift 4.2: How the weirdest error message led to reimagining implicitly unwrapped optionals”

Building a generic doubly linked list using protocol-oriented Swift 4

My original article — “Protocol-oriented Data Structures in Swift 4: A Generic Doubly Linked List” — was published on appcoda.com.

Follow along with this tutorial! Download the Swift 4 code from GitHub.

Let’s talk about creating a list on steroids, i.e., a generic doubly linked list in Swift. For our purposes here, a list is a software receptacle that contains related data that we’re interested in inspecting, organizing, manipulating, etc. A doubly linked list stores a list of “nodes.” Each node contains data, knows about the preceding node in the list, and knows about the following node in the list. We’ll talk about adding nodes to the list, removing nodes from the list, displaying information stored in nodes in the list, and traversing the list. I’ve used the term generic because you’ll see that I can store store pretty much every built-in or custom Swift type in my linked list, like Double, UINavigationController, Int, CGFloat, UIView, CGAffineTransform… You can even store a collection of instances of a custom class or struct in my list (see section “Storing custom types” below). Most importantly, I’ll show you how to move towards generic programming, also known as generics, parametric polymorphism, templates, or parameterized types, where, when possible, we can write code that applies to many types, and thus reduces code redundancy.

Continue reading “Building a generic doubly linked list using protocol-oriented Swift 4”

Self versus self in Swift 4 – capital “S” and lowercase “s”

RELATED: Find out how to make a copy of a class instance (object) using a C++-like copy constructor — a copy initializer in Swift.

Those of you who’ve used Objective-C and Swift for any meaningful length of time must be familiar with the self property of structs and classes. I’m not sure how many are aware of the Self “type” (sometimes called a “requirement”). I would be very interested in knowing how many understand the difference between self and Self. I’m talking about self with lower-case “s,” which I’ll call “small self” herein. It’s pretty well documented. Similarly, Self with an upper-case “S,” is what I’ll call “tall self” herein. It’s not very well documented.

Continue reading “Self versus self in Swift 4 – capital “S” and lowercase “s””

Class copy constructors in Swift 4 for defensive copying

Swift tutorials by iosbrain.com Notice that Swift almost seems to frown on making a copy of a reference type, i.e., a copy of an instance of a class, or, as some would rather put it, getting a copy of an object. I’m not talking about getting another reference to a class, I’m talking about getting an entire, separate copy of a class instance. This frowning on class copying is not an accident. Swift’s language architects want the syntax and semantics of the language to be crystal clear. They want developers to be confident that reference types and value types will both have 1) distinct and obvious meanings and that both types will 2) behave consistently. But still, why not be able to safely make a copy of a class instance? I’ll show you how in this tutorial by borrowing the copy constructor concept from C++. In Swift, we’d call this a “copy initializer.” (NOTE: Yeah, yeah, yeah, I know about NSCopying in Cocoa and Objective-C.)

Continue reading “Class copy constructors in Swift 4 for defensive copying”

Two Structural Design Patterns in Swift: Facade and Adapter

Swift tutorials by iosbrain.com My original article — “Design Patterns in Swift #3: Facade and Adapter” — was published on appcoda.com.

This tutorial is the third installment in my series on design patterns. I started with a tutorial examining two examples of patterns in the “creational” category: factory method and singleton. I then discussed two examples of patterns in the “behavioral” category: observer and memento. In this tutorial, I’ll explain two examples of patterns in the “structural” category: facade and adapter. I urge you to review my first two posts mentioned above so you can familiarize yourself with the concept of software design patterns. Beyond a brief reminder today of what constitutes a design pattern, I’m not going to regurgitate all the definitions again. All the information you need to get up to speed is in my first to tutorials, here and here.

Continue reading “Two Structural Design Patterns in Swift: Facade and Adapter”

How drawing works in an Xcode playground

How many of you use freeform drawing in Xcode playgrounds? How many of you understand how drawing in playgrounds work? Xcode playgrounds can serve as great tools for prototyping your in-development apps, whether it be experimenting with algorithms or toying with ideas for app user interfaces. Granted that drawing in playgrounds is not that well documented. So the subject of this tutorial is how drawing in Xcode playgrounds works and a good number of pointers to help you start drawing in playgrounds. Here’s an example of what I’m talking about:

Continue reading “How drawing works in an Xcode playground”

Swift 4.2 improvements? Member/dot syntax for subscripts. Trying it out in a protocol-oriented, generic linked list.

The code shown herein will only compile and link in Xcode 10 beta and run on iOS 12 beta and/or OS X 10.14 beta.

While working on a Swift protocol-oriented and generic linked list, I got to thinking about Apple’s “improvements” to version 4.2 of their flagship language. Since a linked list is a list, I thought, “Why not add a subscript to my linked list to facilitate finding specific nodes in my list?” I did that in Swift 4.1 and got what most developers would’ve expected, e.g., used linkedList["node4"] to get the node in the list associated with the keyword “node4.” With Swift 4.2, I can use the controversial new @dynamicMemberLookup language attribute and implement dot/member notation, like linkedList.node4 to get that same node in the list associated with “node4.” Big improvement, huh? Well, maybe. We’ll talk about how this new and improved subscript is more than just about syntactic sugar, but that the “driving motivation for this feature is to improve interoperability with inherently dynamic languages like Python, Javascript, Ruby and others.” Note that all code shown in this tutorial was written in two Xcode 10 beta playgrounds.

Continue reading “Swift 4.2 improvements? Member/dot syntax for subscripts. Trying it out in a protocol-oriented, generic linked list.”