If you look at Apple’s “What’s New in iOS” 12 page, you’ll find a section entitled “Interactive Controls in Notifications,” which exclaims:
Notification content app extensions now support user interactivity in custom views. If the content of your app’s notifications needs to prompt user interaction, add controls like buttons and switches.
In this tutorial, I’m going to show you how to give your local and remote (push) notifications a custom user interface (UI). Users can now interact with a notification’s content area. iOS 12 has given us the ability to add a UIViewController subclass to notifications which we can customize. We can add controls like UIButton, UIImageView, and UISwitch to the view controller, wire up custom functionality using IBOutlet and IBAction, and arrange our custom UI using Auto Layout — all within the notification itself. We can provide support for more than a single tap. We can develop pretty much any type of user experience we want, within notification space limitations and timing considerations.
I’ll show you how a user can take action in response to a notification by interacting only with a customized notification interface, and conveniently not having to open up an app. I’ll be showcasing software released to developers just ten days ago (June 19), specifically iOS 12 beta 2 and Xcode 10 beta 2.
By the end of this tutorial, you’ll be able allow to your app users to get a notification, see a custom UI, click on a button, and get a confirmation — all inside a notification, like so:
In this tutorial I’ll show you how to embrace iOS 11’s Files app. First, I’ll walk you through configuration of an app so that any files stored in its iOS file system-based “Documents” folder are made visible in the Files app and exposed to other apps installed on your device. Second, I’ll demonstrate how you can incorporate a Files app-like interface and functionality into your own apps. All of the Swift code I wrote to accomplish these two tasks is included below — and I’ve taken lots of screenshots regarding Files app integration. Sit back, enjoy, and learn about a fundamental paradigm shift in the iOS zeitgeist, moving from a “hide-the-details” (like hiding individual files) mindset to providing users with the ability to look at and manipulate files related to their apps using a macOS Finder-like interface, except on iOS.
To pique your interest, let’s look at a feature I encoded in the final app for this tutorial. We’ll use my app, named “Document-Based App,” to view an image file in the app’s main folder:
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:
In a previous tutorial, I discussed the technology, applications, and benefits of Apple’s Core Bluetooth framework. I showed you how to build an app that wirelessly connected to a Bluetooth® heart rate monitor (HRM) — a small, portable, and “wearable” device. My sample app’s code read heart rate data from the HRM, but it didn’t do anything with the heart rate data except display it in real-time on an iPhone’s screen. While edifying and interesting, there are already a bazillion apps in the App Store that can read heart rate data, and other wearable data, using Core Bluetooth. What about doing something interesting with that data, like analyzing it, deriving value-added and meaningful results from it, and sharing it with researchers? That’s where Apple’s HealthKit framework shines. Please download the Xcode 9 project written is Swift 4 so you can follow along with my discussion.
As iOS developers, we’re very aware that humans love connectivity. Obviously, we love to communicate with each other using wireless devices. More recently, we’ve come expect that we can communicate with what once were considered standalone, ordinary devices. We’ve come to love, even expect, that some of those wireless devices can gather and analyze data about ourselves (usually “wearables”). So many devices have become intrinsic parts of our lives that we’ve coined a now commonly-used phrase, the “Internet of Things” or “IoT.” There are now billions of wireless, communicable devices on the planet. In this tutorial, we’re going to focus on just one segment of the IoT: Bluetooth®.
I’ll explain the essential concepts behind Bluetooth® technology, show you how getting proficient in Bluetooth® software development presents you with a tremendous career opportunity, remind you that you can’t distribute an app that uses Bluetooth® without determining if you need to go through “qualification,” provide you with an overview of Apple’s Core Bluetooth framework (see also here), and finally, walk you through the development of an iOS app in Swift 4 that monitors a person’s heart rate via Core Bluetooth via a Bluetooth® device.
How many of you have written iOS apps that work with files? I’m talking about developing apps that read, write, create, copy, move, and delete files in the app’s sandboxed file system. I’m not talking about reading an image from your app bundle so you can display it on screen, like so:
Image file from bundle
I’m talking about apps like Adobe Photoshop Express which is only useful if it can edit image files; Apple’s Pages and Numbers apps which are only useful if they can edit word processor and spreadsheet/chart files, respectively; and, Microsoft Word which is only useful if it can edit word processor documents. Yes, you can solely work from/in the cloud with all these apps, but you can also opt to store files locally on your devices. What if you open an email attachment or download a file from Safari? I guarantee you that many apps with associations to certain file extensions store those attachments or downloads locally first for editing and display, and only later sync files with iCloud or Dropbox.
We’re going to talk in-depth about protocol-oriented programming (POP) using Swift 4 in this article. This post is the second and final article in a two part series. If you haven’t read the first, introductory article, please do so before continuing onwards. Today, we’ll: discuss why Swift is considered a “protocol-oriented” language, compare POP and object-oriented programming (OOP), compare value semantics and reference semantics, consider local reasoning, implement delegation with protocols, use protocols as types, use protocol polymorphism, review my real-world POP Swift code, and finally, discuss why I’ve not bought 100% into POP. Download the source code from the article so you can follow along: There are 2 playgrounds and one project on GitHub, both in Xcode 9 format and written in Swift 4.
(The second and final installment of this series is now available.)
The greatest enemy of software developers is complexity, so when I hear about new technologies promising to help me manage chaos, I listen. One of the “hot” methodologies generating much attention recently (at least since 2015) is “protocol-oriented programming” (POP) in Swift. We’ll use Swift 4 herein. While writing my own code, I’ve found POP to be promising. What’s very intriguing is Apple’s assertion that “at its heart, Swift is protocol-oriented.” I’d like to share my experiences with POP in a formal presentation, a clear and concise tutorial on this up-and-coming technology. I’ll explain the key concepts, provide plenty of code samples, make the inevitable comparison between POP and object-oriented programming (OOP), and pour cold water on the fad-oriented programming (FOP?) crowds’ claim that POP is a magic bullet solution to everything.
Today, I’ll show you how to use Swift 4 and the Grand Central Dispatch (GCD) application programming interface (API) to implement the execution of (multiple) tasks in the background, i.e., parallel/concurrent execution of tasks on a multicore CPU. I’ve built a sample app that gives you two options: 1) synchronous execution of tasks in the background and 2) asynchronous execution of tasks in the background. All my Swift 4 code from this article, part of an Xcode 9 project which builds a fully-functional working sample app, is available for download here. Join me in: reviewing concurrent programming concepts; reviewing my concurrent Swift 4 code; and, examining videos of my app in action, videos of console output from my app, and the console output text itself. I’ll even show you how to graphically visualize my app’s CPU and thread usage with Xcode’s Debug Navigator.
This is a look at the app — a snapshot — after all images have finished downloading asynchronously in the background:
Here’s a video of the app downloading images asynchronously in the background:
Press the play button if you missed the first showing
I’m going to introduce you to iOS concurrency with simple Swift 4 code that uses an API based on the Operation abstract class. In more complex scenarios, you would subclass and customize Operation, but iOS provides the built-in BlockOperation subclass of Operation which we’ll use here. I’ll review the tenets of concurrency, emphasize why it is necessary in almost all apps, explain the basic infrastructure of Operation, compare it to Grand Central Dispatch (GCD), and then walk you through the Swift 4 code I wrote to implement concurrency in a real-live app based on BlockOperation. I’ll even show you how to graphically visualize your app’s CPU and thread usage with Xcode’s Debug Navigator. Here’s the app that we’ll build together:
Press the play button if you missed the first showing
We now live in the day and age of writing apps that can run on devices with CPUs that have multiple cores. We can go way beyond the notion of “multitasking” as a bunch of processes vying for a “timeslice” of the CPU. We can literally run processes simultaneously on different cores. As iOS developers, it is vitally important that we understand the concept of concurrency. Why?