My original article — How to Integrate Your App with Files App in iOS 11 — was published on appcoda.com.
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:
Continue reading “iOS 11 Files app integration and the UIDocumentBrowserViewController”
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)”
[Download Xcode 8.2.1 project with full Swift 3 source from GitHub.]
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.
Continue reading “Simple data persistence in iOS using Swift 3 (think user preferences)”