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.
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.
What’s more important when troubleshooting software, 1) what you intended in design or 2) what was materialized by running your code in a production environment? Take Auto Layout for example. Interface Builder may be happy with your constraints, displaying no warnings or errors, but when you run your app, you see problems. I find it much more helpful to see my all my Auto Layout live, while my app is running. I’ve found that using Xcode’s Debug View Hierarchy button is an often over-looked but extremely powerful tool for solving app layout problems, especially when iOS developers have to write app user interfaces that run on differently-sized devices in multiple orientations. The Debug View Hierarchy feature helps you understand how Auto Layout works. You can see all of your app’s:
As an iOS developer — or any type of software developer — you’re eventually going to run into linker errors. Sometimes they’re easy to fix (i.e., you’re missing an #include for a header file). Sometimes they’re crazy complex, subtle, and very difficult to solve. Today we’ll talk about some tools (file, otool) and techniques (setting library target hardware architectures) you can use for solving difficult Xcode linker errors.