We’re going to talk about installing a version of your Mac’s operating system (OS), known as “macOS” or “OS X,” on your Mac, older than the one you’re currently running, on a partition of your primary hard drive or on an external hard drive. You may find that your current instance of OS X is too unstable for normal day-to-day usage or more heavy-duty tasks like development. Remember all the problems people had when they upgraded to OS X 10.13, also known as “High Sierra?” Oy, vey. You might have been like “Get me the heck outta Dodge!” You wanted or needed to get back to a stable OS, like Sierra (OS X 10.12) or El Capitan (OS X 10.11). For developers, you may have to install an older version of Xcode not supported by your latest OS. For Cocoa/macOS developers, you may need to make absolutely sure that your desktop apps are backward compatible, and the only way to do that for sure is to install and run your apps on older versions of macOS. I will show you, step by step, how to get a valid copy of an older version of macOS, make a bootable installer disk, and install the old OS.
Here’s an Xcode setting, but what does it do for developers?
There’s a checkbox named “Debug executable” on the “Info” pane for Xcode’s “Debugging Options in the Scheme Editor.” Why is there such a dearth of information on this checkbox, a “simple” Xcode scheme option? Apple has little to say about the feature. Information about it is scarce on the web. I’ve heard all sorts of different opinions about what the checkbox does or doesn’t do. (Some of this may be exacerbated by Apple releasing buggy versions of Xcode.)
I’ll discover and explain, using the scientific method, how the “Debug executable” checkbox works. You may be thinking this is much ado about one checkbox, but my purpose is to get you to think about and learn a lot about debugging with Xcode. The absolute best developers are the ones with great and instinctive debugging, nay, TROUBLESHOOTING, skills.
Today, we’ll talk about manually symbolicating iOS and OS X application “crash reports.” Why? When you hear about a crash in one of your apps from a customer, the first thing you should do is try to get a copy of the crash report. But there are times when you get crash reports that aren’t automatically symbolicated, or that you can’t symbolicate by dragging into Xcode, or are partially symbolicated. When not symbolicated, you’re reading numeric addresses when you want to be reading code, like your function/class names. There are workarounds and we’ll discuss one today. Download the sample Xcode 9 project written in Objective-C to follow along. What’s a crash report, anyway? According to Apple:
The original article – Understanding Delegates and Delegation in Swift 4 was published on appcoda.com.
I’m going to talk about “delegates” and “delegation.” I’ll lead you through a simple example of implementing the delegation design pattern in Swift 4, with full source code. My intent here is to show you how delegation works without getting bogged down in some crazy complex example. To help you become the best of the best, I’m going to introduce you to one of the greatest design tools to aid in object-oriented software development, UML. I’ll show you a UML diagram that I drew up to design and document the implementation of the delegation design pattern used in the sample app we’ll build together. Download the Xcode 9 project with full Swift 4 source from GitHub to follow along.
I’ll show you how to build a user interface (UI) helper, a class that downloads a file at a specified URL. Most importantly, I’ll show you how, through delegation, a
UIViewController subclass can be notified by the helper that an image file has finished downloading, and then the view controller can display the image on screen. For the sake of simplicity and clarity, we’ll pretend that Swift has minimal support for downloading a file from a URL. We’ll manually wire up the notification that the file has finished downloading using the delegation design pattern. Here’s the app we’ll build:
You’ve been working on your billion dollar app happily for days or weeks. It’s Monday morning, you open up Xcode 9 to get back to work and — dang, bummer — all your
IBAction connections look like they’ve been disconnected (see image below):
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.
- [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.)
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.