This article demonstrates how to create a Swift class instance based solely on the class name and possibly an argument for its initializer method. It relies on Objective-C interop to perform the actual object creation, which is hidden behind a generic Swift convenience class called ObjectFactory.

Background

Over the years I’ve written several components in Objective-C that I use in almost all of my iOS projects. A few of them critically depend on the ability to instantiate a class based on a string that contains the class’s name. Those strings might come from a configuration file or be the result of concatenating strings based on a class naming convention.

In Objective-C that is easy as pie, just call NSClassFromString(aClassName) and then alloc/init the Class it returns. However, now that Swift is destined to become the lingua franca of iOS I decided to investigate how one might implement these reusable components in Swift. Instantiating classes by name turned out to be a stumbling block, as it appears that Swift does not yet support this.

Disclaimer: I’ve only been studying Swift since it was publicly debuted two days ago. This entire blog post might be obviated by some utility function I haven’t been able to find or will soon be added to the API in the first official Swift release.

Introducing ObjectFactory

My class named ObjectFactory creates Swift class instances based on the class name. It supports creating objects with either a parameterless initializer or an initializer that takes exactly one parameter. The class could easily be modified to support initializers with more parameters, if necessary.

There is a restriction that ObjectFactory imposes on the classes it can instantiate: they must derive (directly or indirectly) from NSObject. By default Swift classes do not derive from NSObject. There is no harm in making a Swift class derive from NSObject, though it might not always be possible based on a project’s specific class inheritance needs. The reason why this restriction exists will become apparent later in this article when I explain how ObjectFactory works.

Using ObjectFactory

Suppose your application has the following three classes: Person, Friend, and Stranger. The latter two are Person subclasses, and Person is an NSObject.

If you need to create instances of Stranger and Friend based on the name of their classes you could use one of ObjectFactory’s createInstance methods. The simpler version of the method just requires you to pass it a class name that is prefixed by its enclosing namespace, such as “MyApp.SomeClassName”. The other version of the createInstance method allows you to specify which single-parameter initializer method to use and what value its argument should be.

Here is the output of this program:

Created a Stranger
Friend name = Steve

How it works

As I mentioned before, there does not appear to be a way to instantiate a class by name in the Swift API. I was able to get an object that represents a class (named AnyClass), but there was no way to get from there to a live instance of that class. So instead, I hopped into the parallel universe of Objective-C to create an object, which then gets returned back to Swift. This is why ObjectFactory can only work with NSObject subclasses; I’m relying on Objective-C to alloc/init a new object, and those methods are defined by NSObject.

Here is the ObjectFactory class, which is just a Swift convenience API over the Objective-C code that does the real work.

ObjectFactory relies on OBJCObjectFactory to create and initialize new objects. Once you’ve added that Objective-C class’s header and implementation files to your project, Xcode will create a “bridging header” file for you, which allows you to expose Objective-C classes to your Swift code. Be sure to add this to your project’s bridging header file:

This class’s header file is shown below.

The implementation of OBJCObjectFactory is short and straightforward, if you know Objective-C that is! Note that the single-parameter initializer selector is invoked through a pointer to a function, instead of the standard performSelector:withObject: method, because it eliminates a compiler warning and establishes a pattern that can be extended to include an arbitrary number of initializer arguments.

Feel free to use ObjectFactory in your apps, if you need it. Please let me know if you find a pure Swift way to do this!

Share this:

Like this:

LikeLoading...

Related

About Josh Smith

Josh Smith is a musician at heart, and a software developer by obsession. He lives in Arizona, plays classical music on the piano, jazz on the guitar, and enjoys brutally long rides on his bicycle. He has a wonderful wife and thinks that, in general, life is good.

But see my discussion here: http://stackoverflow.com/a/24196632/341994 Basically the problem is merely that you don’t _know_ Swift’s “name” for your class – unless you dictate that name using the `@objc(UseThisName)` syntax. Once you do that, it’s just a matter of making sure that Swift is satisfied that the initializer you’re using is one that this class can respond to. So yes, I’m certainly using `NSClassFromString()`, and yes, this must be an Objective-C class (descend from NSObject), but there is no need to “hop into the parallel universe”: Cocoa and NSClassFromString will always exist, and the code itself is pure Swift.

Matt, I read your post at stackoverflow and tried to do exactly what you described in a playground. I wasn’t able to get it to work — does your example work in playground mode? (btw, I would have asked this at stackoverflow, but I don’t have enough credit)

Playgrounds don’t work at all for me, so I didn’t even try it. This is in my Swift rewrite of an app which, like Josh’s, relies heavily on deciding by their string name what classes to instantiate. It’s working in Swift. (Now, however, I intend to remove that behavior; in Swift there’s usually a Swiftier way.)

Is the lookup via class name really required? Why don’t you just have a dictionary mapping from the class names you want to use to the class objects? Or you could even create a enum which has a method to return the class for the particular values.

If that only helps so far you may also need convenience class constructors too on Person.

I haven’t written any Swift – but it seems like to me relying on a string to be converted to a class may be going away on purpose. Your class name strings have no compiler checking. Doing something as simple as passing Friend.self instead may be better.

That is what I meant when I said “Now, however, I intend to remove that behavior; in Swift there’s usually a Swiftier way.” I agree with both of you (Josh and Patrick). On the one hand, at first, I just wanted to rewrite my existing code in Swift, using all NSObject-compatible classes and doing exactly what the Objective-C code had done; thus, I explored how to call NSStringFromClass and NSClassFromString. On the other hand, when that’s all done, I will do a second pass where I completely rearchitect, adopting Swift enums, structs, and non-NSObject classes, and using Swift idioms and techniques. It will certainly turn out that I can do without NSStringFromClass and NSClassFromString now that we have Swift, but it is also true that at the time I used them, in the language I was using, for the purpose I was using them for, they were the neatest and cleanest way.

I’ve been working on a model de/serializing library and I’ve gotten a few tests to work with some basic instantiating and reflecting of runtime object. I have an Obj-C version of this I’ve been using on projects for a few years and so, I decide to see how it would work in Swift. Not completely, what you’re talking about, but some of it relates.