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 weak and 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.
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:
Press the play button if you missed the first showing
I’m going to introduce you to iOS concurrency with simple Swift 4 code that uses an API based on the Operation abstract class. In more complex scenarios, you would subclass and customize Operation, but iOS provides the built-in BlockOperation subclass of Operation which we’ll use here. I’ll review the tenets of concurrency, emphasize why it is necessary in almost all apps, explain the basic infrastructure of Operation, compare it to Grand Central Dispatch (GCD), and then walk you through the Swift 4 code I wrote to implement concurrency in a real-live app based on BlockOperation. I’ll even show you how to graphically visualize your app’s CPU and thread usage with Xcode’s Debug Navigator. Here’s the app that we’ll build together:
Press the play button if you missed the first showing
We now live in the day and age of writing apps that can run on devices with CPUs that have multiple cores. We can go way beyond the notion of “multitasking” as a bunch of processes vying for a “timeslice” of the CPU. We can literally run processes simultaneously on different cores. As iOS developers, it is vitally important that we understand the concept of concurrency. Why?
Today, we’ll finish our discussion of the benefits of using Objective-C blocks and Swift closures by writing code to define and use a closure in Swift 3. For the full background on this topic, please read my last post entitled “Make blocks (closures) your friend (Objective-C and Swift 3).” Let’s plunge into Swift 3:
Today, I’m going answer all the questions I posed in this series of posts entitled “Basic animation, Auto Layout, and view geometry – Part X” (see parts 1, 2, 3, and 4). I’ll help you understand how how I created the following iPhone animation using Swift 3.0 — and/or how to get started with your first iOS app:
Today, I’m going to push you to understand how how I created the following iPhone animation using Swift 3.0:
I’ll give you everything you need to figure out what I did — but I won’t explain it for you. Explanation will come later (in the next post, I tie all posts in this series, 1, 2, 3, and 4 together). I want you to learn about my design and code, not just copy and paste it. There is a method to my seeming madness. Hang in there with me through this series of posts.
After providing you with diagrams, source code, references, definitions, inline commentary, etc., I want you to be able to answer some questions about building iOS animations, even if it requires you to do some research, before I put all the pieces together in the final chapter (post) in this series. Remember that I started this blog with the intention of helping new/aspiring iOS app developers get started in an exciting, creative, and potentially financially rewarding profession. I don’t want to just provide code for you to copy and paste into your own app projects, I want you to become the best of the best iOS designers and developers. So let me:
NOTE: The iOS skill level required herein is “beginner” to “intermediate.” One of the purposes of this blog is to help aspiring new iOS developers get started on the right foot. For all you seasoned (or “advanced”) developers out there, I encourage you to stick with this blog as we’ll be covering very complex iOS scenarios too. Everyone can benefit from these articles, including myself, by getting your feedback.
Let’s start with some iOS “block animation,” the simplest and easiest (yet very powerful) means of animating UIView objects. The UIKit framework provides a clean infrastructure for animations. According to Apple: