With this article, I’m starting a series about all the goodies — useful tools — that can be found in Xcode. Some of these tidbits are tools everyone knows about while others are barely documented to undocumented. For example, how many of you know that you can view, inspect, and debug all your Auto Layout constraints live during app execution using the “Debug View Hierarchy” Xcode feature? I discussed that feature in detail in this article, “Troubleshooting Auto Layout using Xcode’s Debug View Hierarchy.” Today, we’ll discover two editors that ship with Xcode, the “Open As > Hex” and “Open As > Source Code” editors, both only available by right-clicking on files in the “Project Navigator” to reveal a contextual menu.
We’re going to talk about “protocols” in the Swift 4 language today. I’ll explain them conceptually, and then we’ll start coding protocols with a simple example. We’ll then create our own versions of the Apple built-in
Comparable protocols, and apply them to two real-world classes, one for tracking financial securities and one for representing geometric lines/vectors. Finally, we’ll test our geometric “Line” class in a type of Swift playground that supports rendering user interface components (like
UIView) live in the simulator. But first, please ponder the layman’s definition of the word “protocol” before moving on:
… The official procedure or system of rules governing affairs of state or diplomatic occasions. …
The accepted or established code of procedure or behaviour in any group, organization, or situation. …
A procedure for carrying out a scientific experiment…
Apple’s “The Swift Programming Language (Swift 4.0.3)” documentation states:
- [Download Xcode 9 framework project with full Swift 4 source from GitHub.]
- [Download Xcode 9 framework CONSUMER project with full Swift 4 source from GitHub.]
Let’s talk about Swift 4 frameworks, one method for packaging, reusing, and sharing code. We’ll build our own framework and then include it in our own app. We could’ve talked about static libraries, but frameworks offer more advanced features — and will let us expand on code maintainability options in future discussions. (If you want to have that static versus dynamic library discussion, read this excellent article, but we won’t be debating the topic herein.) From Apple (my emphasis added):
Suppose your supervisor or customer gives you a new project to work on: “I want you to start helping out on my iOS project, ‘Blocks-in-Objective-C.’ Please get a copy of the code, make these changes, test, and then check your new code into the repo. By the way, we’re using Git for source control.” Have you used Git before? Do you know it well? (Does anyone truly understand Git?) Today, I’ll show you how to accomplish that task just assigned by your supervisor or customer.
Since this is an iOS blog, I’m assuming you’ve installed Xcode and therefore Git is installed on your Mac. (If you need to install Git, click here.)
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.
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”.
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.
How many times have you been looking at Swift or Objective-C code in Xcode and can’t remember what a framework method, argument, constant, etc. means? Did you know that help — full documentation — is just a keystroke away? Did you also know that you can add the same type of pop-up, context-sensitive help to your own code? Here’s how. Let’s say you’re looking at the following NSString class method and can’t remember exactly what the call does, what parameters it takes, and what is its return value:
NSString *result = [NSString stringWithContentsOfURL:url encoding:NSUTF8StringEncoding error:&error];
Highlight the method name, parameter, even the enum, and then press the following key combination on your keyboard:
[command] + [control] + [shift] + [?]
or, using key symbols:
⌘ ⌃ ⇧ ?
Here’s what you’ll see: a context-sensitive help/documentation popup. Note that I added the red lines to highlight content. The red highlighting is not what Xcode provides (click to enlarge):
So you immediately get information about the method, parameter, enum, even constant’s:
- Declaration (formal language signature);
- Description (textual explanation of the entity’s purpose);
- Parameters (a full list of names and definitions);
- Returns (the value returned by a method/function, if applicable);
- Availability (what version of iOS that the entity became available in — and sometimes in what version it was deprecated);
- Declared In (the framework which contains the entity); and,
- More (generally, the formal definition of the entity with explanations and other links).
Check out what I get if I click on the “More Type Method Reference” link as shown in Figure 1 (click to enlarge):