As part of working on ray tracing recently, I spent some time brushing up on how to calculate intersections between rays and different types of 3D objects. In preparation for blogging about actually creating a ray tracer, I thought it would be nice to spend some time covering some of the math.

When developing a Swift app, you will occasionally find yourself wanting to include a piece of code only if you’re running in the simulator. Perhaps you want to run some alternative code paths (like not calling Metal APIs, which aren’t available in the simulator), or avoid attempting to register for push notifications. There are a few ways in which to do this, and the techniques are different depending on whether you’re writing Swift or Objective-C.

This difference often catches people out who have come from Objective-C and are used to using all of the familiar C macros. Let’s cover the right approach for each language.

A few years back, the idea of Objective-C modules was introduced to LLVM. They were developed as a solution to the problems associated with the traditional #include and #import mechanisms.

Swift has a number of great features for improving the way it imports Objective-C code. With NS_SWIFT_NAME you can customize the name of functions imported into Swift, and nullability annotations let you work closer with Swift’s optional system. These features are very useful and pretty well known, but one feature I don’t see talked about as often is NS_STRING_ENUM.

This is a fantastic guide on the ins and outs of building an interpreter. It’s still in its early stages, but what’s already there is great.