Dan Rosenstark, author of MIDI Designer, on Tech & Music

Dan Rosenstark

Dan Rosenstark, Author & CEO of MIDI Designer, muses about all things tech. Particularly: Notes on software development in Swift, Objective-C, and many non-Apple languages. Also: lots of random technology notes on OS X and iOS.

Importing Swift to Objective-C, Multiple Modules

This goes by Module (i.e., target), not by project (ignore the confusion on the Internet).

So in my MIDI Designer project, which includes several targets, we change the generated name for all the modules, stored in the Objective-C Generated Interface Header Name property, from




Then in each Objective-C class, you can import directly in the .m like this:

#import "MidiDesignerAllTargets-Swift.h"

Make sure to keep the name of your global import handy!

Dynamic Instantiation of Swift Classes and Interface Builder

Most of the time, it's enough for a Swift class to inherit NSObject to be able to be used from Objective-C.

For dynamic instantiation and, more importantly, use in Interface Builder, you need to specify the class' name explicitly using @objc. For example:

class SliderV2: Slider {

Additional Notes
You can't see the header at all? It's not being generated? This answer has your back. Basically you need to:
  • Define a Product Module Name (no spaces) for the Project
  • Set Defines Module must be set to Yes in Build Settings, under Packaging

In Xcode 8, the Objective-C Generated Interface Header Name will be under Swift Compiler, General. Same same.

Password Assistant on OSX

Well, this is one terrible way to import from Blogger to Postach.io... definitely not ideal.

Scheme for Pragma Mark Organization in Objective-C

Here's an article that I wrote in 2012 for myself...

If you want to be like all the smart people you read about on the Internet, you'll keep your files really well-organized. If you have such long files that you need to use pragma marks (which some people, including Jeff Atwood, I recall, think means that your files are too long) you have a basic organizational problem. Now the solution to this is, of course, "bust the file up into sections and stick to those." But what would those sections be? So I'm usually going by functionality, but then I inevitably lose it and end up with no organization at all, or (worse) using it in half the file.

The reason that I failed is that I cannot use a scheme that requires you to know what each method does. That's very time-consuming and, in a sense, redundant with the messages you see passed in the code.

So here's my new scheme, which is very easy to use because it doesn't require you to think. I've been trying this for a while and it's great.

#pragma mark - class methods
#pragma mark - initializers, dealloc, and lifecycle methods
// like didMoveToSuperview
#pragma mark - property accessors
#pragma mark - public overrides
#pragma mark - public property accessor overrides
#pragma mark - public methods
#pragma mark - protocol A methods
#pragma mark - protocol B methods
#pragma mark - dependent-object lifecycle
// like viewDidLoad, viewDidAppear, etc., NOT like hideView
#pragma mark - Methods not in public interface
#pragma mark - Not Implemented