It's been a long time since I wrote a Friday Q&A, but I'm back, with a brand-new post about a brand-new topic: Swift. Over the last few posts, Mike's gone into some detail about what Swift's internal structures looked like, but he's only touched very lightly on what the linker sees when it looks at Swift-containing binaries: mangled symbol names.

Today's post comes courtesy of Landon Fuller, who you may remember from a previous guest post about mach exception handlers. Landon is a fellow member at Plausible Labs, and today he presents the first in what is intended to be a running series on interesting crashes we encounter in our work.

Friday Q&A is driven by the readers, and that's especially true today. Reader Matthew Elton thought that "Let's Build UITableView" would make a good topic for Friday Q&A, but he decided he'd rather implement it himself and write it up rather than wait for me to do it (good move, Matthew). Without further ado, here is Matthew's article an building UITableView.

This is my first guest Friday Q&A article, dear readers, and I hope it will withstand your scrutiny. Today's topic is on Mach exception handlers, something I've recently spent some time exploring on Mac OS X and iOS for the purpose of crash reporting. While there is surprisingly little documentation available about Mach exception handlers, and they're considered by some to be a mystical source of mystery and power, the fact is that they're actually pretty simple to understand at a high level - something I hope to elucidate here. Unfortunately, they're also partially private API on iOS, despite being used in a number of new crash reporting solutions - something I'll touch on in the conclusion.

This is something of a followup to my last article, dyld: Dynamic Linking On OS X, in which I explored how the dynamic linker dyld does its job. This week, I'm going to recreate the function of both the compiler and the static linker, building a Mach-O binary completely from scratch with only the help of the assembler.

In the course of a recent job interview, I had an opportunity to study some of the internals of dyld, the OS X dynamic linker. I found this particular corner of the system interesting, and I see a lot of people having trouble with linking issues, so I decided to do an article about the basics of dynamic linking. Some of the deeper logic is new to me, so sorry in advance for any inaccuracies.

In the last post in this mini-series, Mike gave an overview of the Fourier Transform and then showed you how to use Apple's implementation of the Fast Fourier Transform (FFT).

It's been a bit since I did an article, but I'm back again, with a somewhat off-the-cuff treatment of a very twisted set of code I use to pretend that C has exceptions. I delve into little-known extensions of C, Linux compatibility, and worst of all, goto, so be warned!

Here I am, yet again! This week, I'm continuing where my last article left off, regarding PLCrashReporter and unwinding stack frames on x86_64. In particular, I go into how I got at and used all the various data I discussed in last week's article, and why some of the existing solutions in the wild weren't suited for our use.

I'm back once again for Friday Q&A. Today I'm going to talk about some work I recently did on PLCrashReporter, adding support for unwinding stack frames on x86_64. PLCrashReporter was originally targeted solely at iOS, where both ARM and x86-32 (the simulator) make crash reporting relatively straight-forward; we can simply walk the stack via the preserved frame pointer. On x86-64, matters are different, leading to the need to implement support for alternative methods for stack unwinding. This work was sponsored by HockeyApp, to support their upcoming release of Mac OS X sandbox-compatible crash reporting. I'll talk about DWARF debugging information, the compact unwind encoding, and stack scanners. I assume at least some knowledge of x86_64 architecture, for simplicity's sake.

I'm back again for Friday Q&A, and this week I'm going to follow up on Mike's 2008 article, Key-Value Observing Done Right, where he debuted a replacement for KVO, MAKVONotificationCenter. It's been a long time since then, and it was high time such a useful piece of code got an update, which I gave it. With the help of Mike and Tony Xiao, it's gotten a full overhaul and is now a modern code library with some fun features. In this article, I'm going to go through the new stuff and how it was done.

Welcome back to Friday, NSBlog readers. Here's the promised followup to my article last week about the Mac Toolbox, where I do a line-by-line analysis of the code from the original article, alongside Mike's Friday Q&A for this week.

Hi again, readers of NSBlog! This is my first guest post of 2012, and also my first one writing the introduction myself. I plan to do posts every two weeks, alternating with Mike's to bring back the once-a-week format. This week, at my own suggestion, I'm doing a historical piece on the original programming environment for Macs: The Mac Toolbox. Time for a trip down memory lane!

Gwynne finishes off her series on analyzing assembly code with a look at ARM assembly, for all of your iOS needs. Gwynne will be contributing the occasional article in the future as well as a guest author, without my introductions. Watch the Author field at the top of the post to see who's writing what. Without further ado, let's take a look at ARM.

Today I have the pleasure to present the followup to last week's guest post. Gwynne Raskind returns to complete her in-depth analysis of the assembly code generated by a small sample program.

As a small change of pace, today's post is written by guest author Gwynne Raskind. My last post touched a bit on disassembling object files, and Gwynne wanted to dive deeply into just how to read the output in detail. Without further ado, I present her wonderful in-depth look at reading x86_64 assembly.