Using SwiftUI and WidgetKit to make your app content indispensable

By using a combination of SwiftUI and WidgetKit, you can increase the visibility of your app’s content and enhance the user experience by placing one or more “widgets” on the user’s iOS Home screen, macOS Notification Center, and/or iOS Today View. Widgets should display your app’s most relevant content, allowing users to get important information with a glance. When a user taps/clicks a widget, they go straight to your app and should land on a page that gives them more details about what they just glanced at. Take a look at your iPhone’s Today View right now. There are widgets for weather, battery power, maps, stock exchanges — with many more available. For example, you can get an almost-instant read on the current atmospheric conditions by glancing at one of several available weather widgets. This time of year, before I leave the house, I glance at the weather widget to determine if I need a coat and hat before going outside. If I want to get the forecast for later in the day, I just tap on that weather widget to open the respective weather app.

Continue reading “Using SwiftUI and WidgetKit to make your app content indispensable”

Dividing and conquering your Xcode projects with targets

My original article — “Dividing and Conquering Your Xcode Projects with Targets” — was published on appcoda.com.

In this tutorial, I’ll show you how to leverage Xcode targets to control the massive complexity involved in building iOS (and macOS, watchOS, and tvOS) apps. A lot of time can be saved when developers realize that not everything they’re required to do has to be done by writing software language code, like Swift. Integrated development environments (IDEs) like Xcode offer very powerful tools, like targets, that allow developers to decouple nitty-gritty tasks that used to be done in code (or manually) out into project configuration settings. I’ve found that, because of the sheer number of project settings, developers often take one look at say, Xcode’s long, long list of Build Settings, and want to curl up and pass out. When finished reading this tutorial, you’ll see that you can neatly organize code into one project that’s capable of producing binaries for iOS, macOS, watchOS, and tvOS.

Continue reading “Dividing and conquering your Xcode projects with targets”

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”

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”

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.”

Two Behavioral Design Patterns in Swift: Observer and Memento

My original article — “Design Patterns in Swift #2: Observer and Memento” — was published on appcoda.com.

This tutorial is the second installment in a series on design patterns started last week. There are 23 classic software development design patterns probably first identified, collected, and explained all in one place by the “Gang of Four” (“GoF”), Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in their seminal book, “Design Patterns: Elements of Reusable Object-Oriented Software.” Today, we’ll focus on two of these patterns, “observer” and “memento,” which fall into what the GoF calls the “behavioral” category. Follow along with the Xcode projects, both on GitHub, available for observer here and memento here.

Continue reading “Two Behavioral Design Patterns in Swift: Observer and Memento”

Swift 4.2 improvements to Collection and Sequence protocols with method allSatisfy

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

We’re in the middle of Apple’s annual product upgrade cycle and this article is the first in a series of tutorials meant to highlight the most important new features of Swift 4.2. Instead of trying to cover all of the 4.2 features/improvements in one very long article, I’m going go talk about each aspect of the new 4.2 version, one or two features at a time. (If you’re interested in more details as to why I’m focused on 4.2, see section “Swift version methodology” below.) Today, I’ll cover the allSatisfy(_:) instance method (see also here) of the Sequence protocol (see also here), of course intimately related to the Collection protocol (see also here).

Continue reading “Swift 4.2 improvements to Collection and Sequence protocols with method allSatisfy”

Two Creational Design Patterns in Swift 4: Factory Method and Singleton

My original article — “Design Patterns in Swift #1: Factory Method and Singleton” — was published on appcoda.com.

There are 23 classic software development design patterns probably first identified, collected, and explained all in one place by the “Gang of Four” (“GoF”), Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in their seminal book, “Design Patterns: Elements of Reusable Object-Oriented Software.” This tutorial focuses on two of those patterns in terms of what the GoF calls the “creational” category: “factory method” and “singleton.” Follow along with the Xcode projects both on GitHub, available for factory method here and singleton here.

Continue reading “Two Creational Design Patterns in Swift 4: Factory Method and Singleton”

The iOS file system in-depth (and how to be the best using critical thinking)

Have you ever wondered how all those people out there figured out how to manipulate the iOS file system in their apps? For some strange reason, Apple has never provided well-organized documentation on the subject. Here’s how I feel: “Ask and simple question and get an obtuse and overly complex answer.” There are many articles and tutorials out there, including my own, showing you examples of Objective-C or Swift code for manipulating the iOS file system, and most of the code looks basically the same. Nonetheless, this code is deceivingly complex, often underestimated, and rarely well-explained or well-understood.

Where did everybody find this boilerplate code? From simple observation, I’ve found that in many cases, developers use a copy and paste methodology, i.e., look up a few keywords in a web search engine, find the code needed on sites like StackOverflow or some blog, copy it, paste it into an Xcode project, and beat on it until it works. I don’t want you to feel this way after reading my tutorials.

I hope you’ll find it edifying and interesting to read about how I figured out how to understand and navigate the iOS file system using the “most of the code looks basically the same” boilerplates. But I bet you’ll find it even more intriguing to find that I’ve discovered an much better alternative to the boilerplate code.

Continue reading “The iOS file system in-depth (and how to be the best using critical thinking)”

Introduction to MVVM: refactoring an MVC app using the MVVM design pattern

My original article — Introduction to MVVM: refactoring a MVC app using the MVVM design pattern — was published on appcoda.com.

[Download the Xcode 9 project from GitHub so you can follow along with my code explanation and try MVVM yourself!]

Design patterns are very important tools for iOS developers to keep in their software engineering arsenals. These patterns, along with several other best practices I’ll mention below, help developers to create reliable and maintainable apps. In other words, design patterns help in managing software complexity. In this tutorial, I’ll introduce you to the “Model-View-ViewModel” or “MVVM” design pattern. For a historical and pragmatic perspective, I’ll compare the very well-known “Model-View-Controller” or “MVC” design pattern, long favored by many iOS developers, to MVVM, which has steadily been gaining traction among the same group of developers.

In order to help you understand these design patterns, I’ll walk you through the design and coding of my app shown here:

Continue reading “Introduction to MVVM: refactoring an MVC app using the MVVM design pattern”