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.
We’re going to learn about a feature of Swift called “property observers” that help developers manage app state. You can easily add code to monitor changes to Swift native type property values as well as your own custom type property values. Remember that you can gain insight into an application by looking at its state: the data values stored in all properties of the app at a specific point in time. Getting a grip on app state, therefore managing complexity, is one of the biggest challenges in computer science. Property observers are one technology that help you get a grip. In today’s article, I’ll explain this Swift feature, demonstrate its usage with runnable examples of Swift code, show you how I built an app which relies on property observers, and provide you a list of other Swift technologies that help you manage app state and complexity. Here’s my sample app in action:
It is my great honor and privilege to have joined the tutorials team at AppCoda.com as a freelancer. My first tutorial, “Swift 4 Generics: How to Apply Them in Your Code and iOS Apps,” was published yesterday, and was originally published here on my own site at this link. I am looking forward to publishing many more tutorials for you, my most loyal readers, at AppCoda and here on iOSBrain.com. Note: If I cross-post an article on AppCoda and here, the article will appear first on AppCoda. Thank you AppCoda!
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:
I’m going to talk about “delegates” and “delegation.” I’ll lead you through a simple example of implementing the delegation design pattern in Objective-C, with full source code, and then show you a more sophisticated scenario. My intent here is to show you how delegation works without getting bogged down in some crazy complex example. Download the Xcode 9 project with full Objective-C source from GitHub to follow along.
I’ll show you how to build a user interface (UI) component, a status/progress indicator, which you can display on screen for processing-intensive tasks… AND I’ll show you how you can customize the behavior of the indicator by using delegation. For example, when the indicator starts, you could disable your UI; when the indicator stops, you could re-enable your UI; and, when the user taps the indicator, you could cancel processing-intensive tasks. 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):
Let’s talk about creating understandable and maintainable code in Swift 4, code that can be easily read by other programmers, can be readily debugged, can be reused, and can be enhanced and extended in the future. We’re going to limit today’s discussion to: 1) how best to come up with good names for functions and how best to name their arguments, parameters, and argument labels, and 2) how to use meaningful and descriptive variable (
var) names — and constant (
let) and enumeration (
enum) names, etc. The goal is to create code that reads as to close to English as possible.
You may believe that this topic is overly simplistic or pedantic, but sometimes it’s the “little things” in life that really matter — especially when you have applications that are made up of millions of lines of code, made up of “little things” like function definitions and function calls.