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
$(SWIFT_MODULE_NAME)-Swift.h
to
MidiDesignerAllTargets-Swift.h
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:
@objc(SliderV2)
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.
Posted on October 16th, 2015
Password Assistant on OSX
Well, this is one terrible way to import from Blogger to Postach.io... definitely not ideal.
Posted on September 15th, 2015
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
Posted on September 14th, 2012