How many of you use freeform drawing in Xcode playgrounds? How many of you understand how drawing in playgrounds work? Xcode playgrounds can serve as great tools for prototyping your in-development apps, whether it be experimenting with algorithms or toying with ideas for app user interfaces. Granted that drawing in playgrounds is not that well documented. So the subject of this tutorial is how drawing in Xcode playgrounds works and a good number of pointers to help you start drawing in playgrounds. Here’s an example of what I’m talking about:
While creating a new Xcode playground on my MacBook Pro today, I got the most bizarre error message: “No such module ‘UIKit'”. I was using Xcode Version 9.2 (9C40b). Yes, I know there are more recent versions, but I haven’t had the need to upgrade my MacBook Pro. Parenthetically, I do have Xcode 9.4.1 (9F2000) and Xcode 10 beta 6 (10L232m) loaded on my main development machine. I’ll share the solution to this problem with you in the hopes that you, like me, will learn something new about Xcode today.
We’re in the middle of Apple’s annual product upgrade cycle and this article is the second in a series of tutorials, started last week, meant to highlight the most important new features of Swift 4.2. Today, we’ll look at two two new Swift 4.2 features, the
#error compiler directives.
In this tutorial, I’ll show you how to track down memory leaks within Xcode via the Memory Graph Debugger, new since Xcode 8. This is a powerful visual tool and doesn’t require you to step out of Xcode and start the Leaks Instrument. Once we identify some memory leaks, I’ll show you how to plug those leaks by using the Swift language’s
unowned qualifiers, and talk about the differences between the two qualifiers.
I recently discussed iOS memory management and memory leaks that occur when using reference semantics and reference types (classes) in my tutorials on “Swift 4 memory management via ARC for reference types (classes)” and “Fixing memory leaks — strong reference cycles — in Swift 4.” After reading these articles, you should understand how easy it is to inadvertently encode and introduce a strong reference cycle into your Swift 4 code and thus end up with a memory leak. You should also understand how generally straightforward it is to fix such a memory leak. My sample code in both tutorials was didactic. What about real-world projects with hundreds of thousands or millions of lines of code? Suppose that you’ve heard reports of diminished app performance, low memory warnings, or just plain app crashes. Finding memory leaks in your code is quite cumbersome when trying to debug via rote inspection, setting breakpoints, adding logging statements, etc.
Have you ever wondered how all those people out there figured out how to manipulate the iOS file system in their apps? For some strange reason, Apple has never provided well-organized documentation on the subject. Here’s how I feel: “Ask and simple question and get an obtuse and overly complex answer.” There are many articles and tutorials out there, including my own, showing you examples of Objective-C or Swift code for manipulating the iOS file system, and most of the code looks basically the same. Nonetheless, this code is deceivingly complex, often underestimated, and rarely well-explained or well-understood.
Where did everybody find this boilerplate code? From simple observation, I’ve found that in many cases, developers use a copy and paste methodology, i.e., look up a few keywords in a web search engine, find the code needed on sites like StackOverflow or some blog, copy it, paste it into an Xcode project, and beat on it until it works. I don’t want you to feel this way after reading my tutorials.
I hope you’ll find it edifying and interesting to read about how I figured out how to understand and navigate the iOS file system using the “most of the code looks basically the same” boilerplates. But I bet you’ll find it even more intriguing to find that I’ve discovered an much better alternative to the boilerplate code.
Today, I’ll show you how to use Swift 4 and the Grand Central Dispatch (GCD) application programming interface (API) to implement the execution of (multiple) tasks in the background, i.e., parallel/concurrent execution of tasks on a multicore CPU. I’ve built a sample app that gives you two options: 1) synchronous execution of tasks in the background and 2) asynchronous execution of tasks in the background. All my Swift 4 code from this article, part of an Xcode 9 project which builds a fully-functional working sample app, is available for download here. Join me in: reviewing concurrent programming concepts; reviewing my concurrent Swift 4 code; and, examining videos of my app in action, videos of console output from my app, and the console output text itself. I’ll even show you how to graphically visualize my app’s CPU and thread usage with Xcode’s Debug Navigator.
This is a look at the app — a snapshot — after all images have finished downloading asynchronously in the background:
Here’s a video of the app downloading images asynchronously in the background:
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: