I’m happy to share that today is my 2-year anniversary at Okta! This would make more sense if I’d originally announced on this blog that I’d changed jobs and started working at Okta, so I’ll take a moment to recap what’s happened in the past two years, and some of the milestones and accomplishments I’m most proud of. Before joining Okta, I worked at Salesforce for 10 years, and had many opportunities to move around within the mobile organization to kick start new products and teams, solve complex challenges, and grow personally and professionally along the way.

Someone on Twitter recently asked how to implement a TableView header that will stretch and resize as the content is scrolled, so I thought I’d spend a few minutes to provide a good example. Since I thought it’s a neat trick that’s often overlooked, I felt it was worthy of wrapping a post around it to explain how it works, maybe giving others the ability to replicate this pattern for themselves.

One of the “delightful” features of iOS is the almost imperceptible UI effects they add to give the illusion of depth. One of the most under-appreciated features is UIMotionEffect, which ties the device’s gyroscope to your views to make them adapt to how the user moves their phone.

This can be seen throughout iOS, from your lock screen to your app icons in Springboard (the iOS app launcher). Done right, the user won’t consciously notice these views moving, but it helps set certain views apart from the rest of the app’s UI, helping them “pop” and be more noticeably separate from the rest of the app.

In this post I’ll go over what UIMotionEffects are, how they work, and will share my approach for simplifying how to add motion effects throughout your application.

UIAppearance is analogous to CSS for UIKit, while being compatible with both Interface Builder and traditional styling in code, without sacrificing performance. It’s a way of declaratively assigning UI style values to your views, without needing to manually tweak settings throughout your codebase. This makes it easy to define your app’s visual style centrally, which makes maintenance simpler when changes are necessary.

In this post, I’ll talk about how you can define your own custom UIAppearance properties in your views, allowing you to declaratively style your app giving you more flexibility and reusability.

When working with iOS apps (or really anything within Apple’s ecosystem) I’ve sometimes found the need to deeply introspect the libraries and executables built in my project to answer questions like “Is bitcode enabled for all architectures?” or “Which architectures was this binary compiled for”, and so forth.

These aren’t easy questions to answer unless you know your way around the command-line, and which commands to invoke. So I thought I’d go over how to analyze compiled binaries, and share some helpful scripts I wrote to simplify the process.

Everyone has a love/hate relationship with bug reports. For the user, they’re a nuisance to file. For the engineer receiving a bug report, it means extra work and the sad realization that your product isn’t perfect.

I’ve been frustrated with Apple’s handling of bug reports just as much as everyone, but haven’t really thought much about it recently. But with some recent talk on the topic, I felt like playing the devil’s advocate and wanted to share a few thoughts in defence of Apple’s engineers.

I recently wrote about Cocoa / Cocoa Touch frameworks, and in writing about it I was sorely tempted to dive into Modules, since they are pretty important to modern frameworks. But it was such a huge topic, I decided to break it out into a separate post.

In a nutshell, LLVM Module Maps were invented as a way to improve how source code imports other frameworks.

If you’ve ever worked on traditional C/C++ software projects (Makefile, CMake, gcc…any of these ring a bell?) you’ll know that the more code you add, the longer it takes to build, and the more likely you are to have conflicting types or macro definitions.

If you don’t know the nuts and bolts of how your code is compiled, linked, and executed on target devices, you aren’t alone. And lets be honest, this is perfectly fine! That’s the great thing about abstraction: not everyone need be an expert at everything in order to be effective.

There are times though where a little bit of knowledge can go a long way to help troubleshoot particularly onerous problems. So I thought I’d explain a bit about how apps work in Cocoa (and by extension, Cocoa Touch), particularly how frameworks work.

I feel that every few years I write a post like this. It’s filled with statements like “Life got busy”, or “I had a problem with my server and didn’t notice”, or some other reason that seems insignificant in the grand scheme of things.

This time around though I have a very good reason for a 5-year break in my blogging activities. It started out as being just generally busy with travel, and ended up with the birth of my beautiful daughter who, at the time of this writing, is about to have her 3rd birthday. It’s been a very fulfilling experience that regardless has eaten up any spare time I have for such frivolities as blogging.

So let me take this moment to recap the past few years to kickstart my blog again!

You know how many times, as an iOS developer, you want to ensure some method or delegate call occurs on the main thread?  We do this dance countless times, and while it’s straight-forward enough, it can be a burden sometimes.

Here’s an easy way to keep your thread access safe, without having to write a lot of code in the process.