Swift and Objective-C use the same runtime. They use the same ARC memory management. They certainly interoperate far more than most languages except perhaps ones targeting the CLR. You might be forgiven for thinking that writing new classes in Swift would be easy, but there are several gotchas you might encounter:

Enumerated Sadness

You can't define enums in Swift that are visible to Objective-C. Not even simple enums that inherit from NSInteger and don't have any fancy features. This will either make your Swift code ugly by eschewing the power of Swift enums, or make your Objective-C code ugly as you call various workaround methods. For now, I just use the NS_ENUM macro to define them in Objective-C, then make them visible to Swift. If I need anything fancier, I'll dupe the enum in Swift code and make sure I provide the Swift enum methods to take and return the Objective-C enum.

Not elegant, but hopefully a future version of the language will offer something better. In theory, it should be possible to come up with an object-esque interface to fancy enums that exposes the associated values as an NSArray and methods as instance or class methods, letting you seamlessly bridge enums to Objective-C. If Swift had more complete reflection support I'd have written this one already.

Protocol Cycles

In Swift, you only have one bridge file from Objective-C. That means any class anywhere must be added to that one bridging header.

What happens when you need to reference a protocol defined in swift from a header listed in that very same bridging header? Nothing good, I can assure you of that. Unfortunately there's no @protocol equivalent of @class, so there's not really a good way to publicly declare support for a protocol in this situation. You can move the protocol to Objective-C code, or you can declare it in the .m file's private interface.

Generics? Structs? Why I never!

This shouldn't be a surprise to anyone at this point, but since Objective-C is completely unaware of generics there are a whole host of methods and class designs that are simply not expressible (and thus not visible) to Objective-C. This can become a very limiting constraint that makes you write strange and obtuse Swift code for no apparent reason.

The same thing applies to structs; Swift is far more capable, but that means structs don't make themselves visible to Objective-C.

Good News Everyone

The good news is that the basic stuff works and fairly well at that. After writing Swift code it feels like jumping backwards in time to write Objective-C.

Next up: I discuss some strange initialization quirks