Let’s talk about using Swift 3’s object-oriented programming (OOP) features to make you a better developer. First, we’ll get a quick overview of the sample project for this post. Second, we’ll discuss the advantages of OOP in Swift. Third, we’ll talk about OOP in depth. Fourth, let’s think about how all the OOP theory applies to my code. Fifth, we’ll specify the Swift 3 syntax required for defining classes and creating instances (objects) of those classes. Finally, we’ll go through my Swift source code to implement a useful OOP class hierarchy (which you are free to include in your own projects subject to my terms of usage). Hey! Check out my latest post on polymorphism, a natural continuation of this article.
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:
Segues don’t exist in a vacuum. I’ve introduced a UINavigationController into the mix. Of course, you’ll see a few UIViewControllers. I’ve also used a UITableView and managed its complexity by breaking it into logical pieces by using Swift “extensions.” As you proceed, you’ll have to grasp concepts like Auto Layout and managing a table view’s data source.
I’m going to show you how you can create IBOutlets, find your existing ones, and delete them. There will be times when you need to delete outlets, for example, if you connected the wrong component, have to change your design, misspelled an outlet, etc. You can’t do iOS without doing IBOutlets. An outlet is a connection you must create to allow your user interface (UI) to communicate with your code. For example, if you have a UIView on a storyboard scene, like a UIViewController, you may want to change that view’s background color during app execution. You may also need the bounds or frame of the view. If you have a UIButton, you may want to dynamically enable or disable it depending on some runtime condition. Say you have two UITextFields, “username” and “password,” and a UIButton containing the text “Login.” With IBOutlets, you could write your code so that the login button’s isEnabled property becomes true only when the username and password fields are filled with data. You would also want the text contained in the username and password fields once the user taps “Login.” IBOutlets form a connection between UI components like UILabel, UITextField, and UIView and their backing view controller that manages their behavior and presentation.
Today, we’ll finish our discussion of the benefits of using Objective-C blocks and Swift closures by writing code to define and use a closure in Swift 3. For the full background on this topic, please read my last post entitled “Make blocks (closures) your friend (Objective-C and Swift 3).” Let’s plunge into Swift 3:
Let’s learn about, formally define, review some code for, and write some code for blocks in Objective-C, and write some code for closures in Swift. Blocks are one of the most important programming language constructs you’ll ever learn about. I depend on them to get notified when concurrent tasks complete (i.e., as callbacks), whether I submitted those tasks synchronously or asynchronously. I’ll bet that even if you have never heard of blocks or closures, you’ve already used them. Guess what? If you’ve been reading this blog, you’ve already used blocks!
Let’s talk about source/version control, why it’s so important, and how you can easily put all your iOS code under source/version control management (SCM). I’m going to show you the manual steps involved in putting your code into a Git SCM “repository” (repo) so you fully understand how source/version control works. Jump straight to the tutorial if you’re already familiar with the concept of source control. I can’t explain everything about SCM in one blog post, but I’ll get you started and provide many online resources for you to reference. Why am I using Git? Like it or not, Git has become the de facto standard in SCM systems, mainly because it “is a free and open source [and] distributed version control system.” I don’t buy into the “Git is easy to learn” argument. I find Git to be overly complicated, cryptic, and generally requiring more steps to accomplish source control tasks than say centralized SCM systems like TFS or Subversion/SVN. Git does have some advantages over other SCM products, and it even becomes quite efficacious once you pay your dues learning how to use it properly.
NOTE: This article was first published on Jan 18, 2017. Since that time, I realized I missed one aspect of the project renaming process. Re-read the article or jump straight to the new content.
Sometimes you need to rename your Xcode projects. Not too long ago, this would’ve been problematic. Apple has built a project renaming feature into Xcode, but it’s not good enough for my needs. I’ll show you how I have to go above and beyond the standard functionality to get what I really want. Let’s walk through a concrete example, renaming an Xcode project we’ve been talking about in the post entitled “The UICollectionView is much more than a grid or matrix”.
My latest iOS app, AirStitch, was accepted into Apple’s App Store today. I developed the app in Objective-C, targeting the iOS 9 SDK, using Xcode, following the requirements provided by BriTon Leap, Inc. The company is the world’s leading developer of custom embroidery design software. Download the app for free and enjoy. The app is a marvel of engineering.
App Transport Security (ATS) is enabled by default for apps linked against the iOS 9.0 or OS X v10.11 SDKs or later, as indicated by the default Boolean value of NO for the NSAllowsArbitraryLoads key. This key is at the root level of the NSAppTransportSecurity dictionary.
With ATS enabled, HTTP connections must use HTTPS (RFC 2818). Attempts to connect using insecure HTTP fail. ATS employs the Transport Layer Security (TLS) protocol version 1.2 (RFC 5246). For background on secure Internet connections, read HTTPS Server Trust Evaluation.
With the advent of iOS 9, Apple decided that developers should avoid accessing insecure, unencrypted clear text HTTP (http://) resources on the Internet. Today I’ll show you how to access HTTP sites/services in your apps. I’ll explain the special hoops that Apple wants you to jump through just to use HTTP — and help you keep your app from being rejected.
For Apple to assume that anything HTTP is dangerous is a bit overboard as there are legitimate reasons to access a resource via clear text, like downloading an image (clear binary). Grabbing an image won’t reveal information about users’ private lives. A web/REST service that consumes someone’s name and Social Security number is a different story — that info must be encrypted.
Fortunately, Apple has made some accommodations in allowing continued use of HTTP as long as you provide “justification” when submitting your apps.