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:
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.
Today, we’ll cover the topic of storing a user’s “default settings” inside your app — not forcing the user to go to a Settings bundle. The key to doing this is to save the user’s preferences to a persistent store whenever the user changes those preferences (or at least when the app goes into the background, but definitely before the app is terminated). But saving/writing those preferences is not enough. You must also read those preferences from the persistent store every time the app opens so that the user will always see their default settings. User settings/preferences must be synchronized with the persistent store.
I’m talking about saving simple pieces of data, like a user’s preferences for the background color of views, preferred language (i.e., English, Hindi, Portuguese, Spanish), preferred measuring units (metric or English), etc. Apple’s Human Interface Guidelines don’t explicitly forbid in-app settings. In fact, they explicitly permit them:
Note: Apps are not required to use a Settings bundle to manage all preferences. For preferences that the user is likely to change frequently, the app can display its own custom interface for managing those preferences.
Today’s tutorial covers transitions — segues — from one source storyboard scene to another destination scene, and unwind segues leading back from destination to source… I created a project to help you follow along with this tutorial, written in Swift 3, against the iOS 10 SDK, and using the Xcode 8.2.1 IDE. Please download the project. The app produced by the project is shown in action in the following video. Please watch before continuing on:
Today, I’m going to show you how to leverage the Swift “extension” language feature to manage software complexity, improve code readability, and increase extensibility. We’ll also talk about delegates, data sources, and protocols as they are concepts essential to this tutorial. According to Apple’s “The Swift Programming Language (Swift 3.0.1):”