Protocols with associated types in Swift 4.2 - swift-protocols

I have a question about protocols with associated types, that occurred after updating to Xcode 10 and Swift 4.2.
Before I had a protocol:
protocol ViewModelBased: class {
associatedtype ViewModel
var viewModel: ViewModel { get set }
and a VC implementing it.
class MyViewController: UIViewController, ViewModelBased {
var viewModel: EntitiesViewModel!
After update to Xcode 10 I get and error saying MyViewController doesn't conform to the protocol and I have to declare the property as:
var viewModel: ViewModel! { get set }
Anyone has any idea why there is difference as I don't get it?

Basically your code was always dubious and now you’ve been caught:
protocol ViewModelBased: class {
associatedtype ViewModel
var viewModel: ViewModel { get set }
class MyViewController: UIViewController, ViewModelBased {
var viewModel: EntitiesViewModel!
In the protocol adopter MyViewController, what type do you claim corresponds to ViewModel? It seems you think it should be EntitiesViewModel. And the compiler permitted this to slide, allowing the implicitly unwrapped Optional wrapping a type to be substituted for the type itself.
But now there is no implicitly unwrapped Optional type; the type EntitiesViewModel! is effectively the same as the type EntitiesViewModel?, an Optional wrapping EntitiesViewModel. So if you want EntitiesViewModel to be ViewModel, and if you want this property’s type to be an Optional wrapping EntitiesViewModel, the protocol must declare this property’s type as an Optional wrapping ViewModel.


Swift 2.1: Property cannot be marked dynamic?

How do I fix this compilation error?
dynamic var users = [User]()
Property cannot be marked dynamic because its type cannot be represented in Objective-C
I need dynamic so that certain view controllers can observe (via KVO) users and update their views when users changes.
Just as the error mentions
error, not #objc : NSObject:
class A{
func something(){
dynamic var a = [A]()
should be changed to:
#objc class A:NSObject{
func something(){
dynamic var a = [A]() //works, all good

Property 'sharedInstance' not found on object of type ClassA

I am creating a swift framework. In that one class is like this as shown below.
import Foundation
#objc public class classA: NSObject {
public override init (){
Singleton intance is returned.
public class var sharedInstance: classA {
struct Static {
static let instance = popeye();
return Static.instance
Now when i add this framework into a Objective c project and try to access "sharedInstance" i get this error.
Property 'sharedInstance' not found on object of type ClassA.
Fix it Replace 'sharedInstance' with 'sharedInstance'
But even if i try use Fix it, this issue isnt solved.
NOTE: This issue doesn't happen when i integrate this framework with a swift project!!!
I tried to reproduce your problem. At first the syntax highlighter in Xcode flagged the same error in Objective-C that you mentioned, but the code actually was built and ran fine.
However, there is a cleaner way of doing this. In your code you are using a computed type property, which is evaluated every time you access it! You work around this by introducing the struct Static, where you essentially do what could be done in classA itself, like this:
Singleton intance is returned.
public static var sharedInstance: classA = popeye()
Here we used a stored type property, which is a recommended way to implement singletons, see here:
And here is some documentation on different kinds of properties:
Finally i was able to fix this with a minor change !! :)
Swift framework code
#objc class SingletonTest: NSObject {
// swiftSharedInstance is not accessible from ObjC
class var swiftSharedInstance: SingletonTest {
struct Singleton {
static let instance = SingletonTest()
return Singleton.instance
// the sharedInstance class method can be reached from ObjC
class func sharedInstance() -> SingletonTest {
return SingletonTest.swiftSharedInstance
// Some testing
func testTheSingleton() -> String {
return "Hello World"
Objective C parent project code
SingletonTest *aTest = [SingletonTest sharedInstance];
NSLog(#"Singleton says: %#", [aTest testTheSingleton]);

Extending a Swift class with Objective C category

Im in a situation where I need to use Objective C category to extend a Swift class. I've done something as follows:
In "SomeClass.swift":
class SomeClass: NSObject {
In "SomeClass+Extension.h":
#import "Project-Swift.h"
#interface SomeClass (Extension)
This has worked well. And if I try to use the SomeClass extension in my Objective C code, it is fine.
The problem is, if I want to use someMethod() in a another Swift class, I will need to put the SomeClass+Extension.h file into my ObjC-BridgingHeader.h file.
But doing this will cause a circuclar dependency, because SomeClass+Extension.h also imports Project-Swift.h.
Does anyone have a good way to get around this?
Please note that simply forward declaring the class in the category header will not work, as categories cannot use forward declarations for it's own implementation as so:
#class SomeClass without importing Project-Swift.h will give a compile error.
The Bad
i too have been fighting this issue a bunch. unfortunately the documentation pretty explicitly states that this pattern is not allowed:
To avoid cyclical references, don’t import Swift code into an
Objective-C header (.h) file. Instead, you can forward declare a Swift
class or protocol to reference it in an Objective-C interface.
Forward declarations of Swift classes and protocols can only be used
as types for method and property declarations.
also throughout the the linked page you will notice it keeps mentioning to import the generated header specifically into the .m file:
To import Swift code into Objective-C from the same target
Import the Swift code from that target into any Objective-C .m file
within that target
The Good
one solution that may work for you is to create a swift extension that redefines each method you need in the category. it is fragile and ugly, but arguably the cleanest solution.
Add category methods from objc here (since circular references prohibit the ObjC extension file)
extension SomeClass {
#nonobjc func someMethod() {
adding the #noobjc to the front allows the
same method signature to be used w/o overriding the ObjC implementation
now the import "SomeClass+Extension.h" from the bridging
header can be removed
if support for more than two input params is needed, or tighter type coupling is desired i would recommend using the runtime to call the underlying function. a great description is here.
As one simple solution, you can move the extension to your Swift code. Then you won't have any dependency problems.
From the Interoperability guide, we cannot directly access the subclassed / categorized / extensioned Objc-objects for the .swift [SomeClass] class.
But as a turn-around, we can do this:
For Variables , we can do this:
extension Class {
private struct AssociatedKeys {
static var DescriptiveName = "sh_DescriptiveName"
var descriptiveName: String? {
get {
return objc_getAssociatedObject(self, &AssociatedKeys.DescriptiveName) as? String
set {
if let newValue = newValue {
newValue as NSString?,
For Methods, we can use method_swizzling which is not recommended.

Swift does not generates forward declaration for protocol

I have a swift class defined in a framework that is being used from an obj-c app.
The generated -Swift.h header contains the swift classes marked with #objc but there's one property that makes the compilation fail.
This property is defined like this in swift code :
public var storageClass : StorageProtocol.Type = UserDefaultStorage.self
and so the generated obj-c property looks like this
#property (nonatomic) Class <StorageProtocol> __nonnull storageClass;
But Xcode does not accepts the "StorageProtocol" symbol here, because the forward declaration "#protocol StorageProtocol;" is missing.
If I add a new var defined like this :
public var storage : StorageProtocol? = nil
The forward declaration is added on top of class that define these properties and the -Swift.h compilation succeed.
So it looks like a bug in the -Swift.h generation, but is there another way to force that forward declaration without using a dummy var ?
I did not find any other way than using a dummy var...

Alternative to load method in Swift

I am working on developing an application in Swift. I wanted to design a system for the application that allowed for loose coupling between objects, and one strategy (which I have used successfully in other languages) was to create something I call an instance factory. It is pretty simple and here is the basic implementation I came up with in Swift:
import Foundation
private var typeGenerators = Dictionary<String, InstanceFactory.GeneratorCallback>()
public class InstanceFactory: NSObject {
public typealias GeneratorCallback = () -> AnyObject!
public class func registerGeneratorFor(typeName: String, callback: GeneratorCallback) {
typeGenerators[typeName] = callback
public class func instanceOf(typeName: String) -> AnyObject! {
return typeGenerators[typeName]?()
The idea is that when an object instance needs access to another object instance, rather than creating that instance outright which would more tightly couple the two objects, the first object would defer to the factory to provide the needed instance by calling the instanceOf method. The factory would know how to provide various instance types because those types would register with the factory and provide a closure that could generate the instance.
The trick is how to get the classes to register with the factory. I had previously made a similar factory in Objective-C and the way I got registration to work was to override the +load method for each class that needed to register with the factory. This worked great for Objective-C, and I figured it could work for Swift as well since I would be restricting the factory to only provide objects that are derived from NSObject. It appeared I got this to work and I spent a significant about of effort designing classes to make use of the factory.
However, after upgrading to Xcode 6.3, I discovered Apple has disallowed the usage of the load class method in Swift. Without this, I am unaware of a mechanism to allow classes to automatically register themselves with the factory.
I am wondering if there some other way to get the registration to work.
What alternatives are available that could allow classes to register with the factory, or what other techniques could be use to accomplish the same kind of loose coupling the factory provides?
I've found a possible solution to your problem after I wanted to register all ViewControllers that would be implementing a certain Protocol in my application and I ran into both this question and a possible answer.
The original was posted here: How to list all classes conforming to protocol in Swift?
I adapted it to Swift 3 and made it a bit more Swift-y and generic:
import UIKit
class ContextRoute: NSObject {
#objc protocol ContextRoutable {
static var route: ContextRoute { get }
class ContextRouter: NSObject {
private static var storedRoutes: [ContextRoute]?
static var routes: [ContextRoute] {
get {
if let storedRoutes = storedRoutes {
return storedRoutes
let routables: [ContextRoutable.Type] = classes(implementing: ContextRoutable.self)
let newRoutes = { routable in routable.route }
storedRoutes = newRoutes
return newRoutes
private class func classes<T>(implementing objcProtocol: Protocol) -> [T] {
let classes = classList().flatMap { objcClass in objcClass as? T }
return classes
private class func classList() -> [AnyObject] {
let expectedClassCount = objc_getClassList(nil, 0)
let allClasses = UnsafeMutablePointer<AnyClass?>.allocate(capacity: Int(expectedClassCount))
let autoreleasingAllClasses = AutoreleasingUnsafeMutablePointer<AnyClass?>(allClasses)
let actualClassCount:Int32 = objc_getClassList(autoreleasingAllClasses, expectedClassCount)
var classes = [AnyObject]()
for i in 0 ..< actualClassCount {
if let currentClass: AnyClass = allClasses[Int(i)],
class_conformsToProtocol(currentClass, ContextRoutable.self) {
allClasses.deallocate(capacity: Int(expectedClassCount))
return classes
I tried it in my application and it works. I clocked it in the simulator and it takes 0.05s for an application that has about 12000 classes.
Consider taking the Swift approach using a protocol instead. I think the solution is actually simpler than the Objective-C approach. There are variations of this with Self constraints which are even better if you have more control over the classes.
// define a protocol to create an instance of a class
protocol FactoryInstantiable {
static func makeFactoryInstance() -> AnyObject
// Factory for generating new instances
public class InstanceFactory: NSObject {
public class func instanceOf(typeName: String) -> AnyObject! {
if let ProductType = NSClassFromString(typeName) as? FactoryInstantiable.Type {
return ProductType.makeFactoryInstance()
} else {
return nil
// your class which generally could be defined somewhere else
class MyClass {
var counter : Int
init(counter: Int) {
self.counter = 0
// extension of your class to conform to the FactoryInstantiable protocol
extension MyClass : FactoryInstantiable {
static func makeFactoryInstance() -> AnyObject {
return MyClass(counter: 0)