Add wireframe shouldn't know the presentation style. It should be a list wireframe responsibility to decide what presentation style (modal or push) to use. The better approach is to use segues with module configurator object stored in module view controller scene which initialises module while nib is loading:
http://www.slideshare.net/Rambler-iOS/viper-swift

Not an issue, sorry!

Do you guys use a tool to auto-generate the basic /module files? Feels like it'd be useful.

Why there are strong delegate references ??
I get my class nil when setting weak delegate . But delegate should be weak , isn't it ?

Hi, fantastic demo project. I think it really shows the degree to which VIPER helps isolate single responsibilities.

I do have a question over why Wireframes are as they are though.

Imagine that I want to actually build an iPad version of this app and I want to display a List of TODOS inside of a popover, and we don't offer an option to add items at all — but the iPhone version should remain unchanged.

So intuitively I'd think "Easy! We'll just create a new iPad-only target, and we can pick-up-and-use the List module completely unchanged. We just have to install the List view controller into a popover instead, and we make sure that we don't use the Add module and we are done!". This is such that both the iPhone and iPad app share exactly the same conceptual module: List completely unchanged.

Except — this won't work. ListWireframe is considered a 'part' of the List module (judging purely by looking at the file hierarchy). It currently only knows how to present the List into a UIWindow. What if I wanted to present the List from a ViewController? Or a UIView / CGRect from which the popover pops out? Surely ListWireframe cannot know of all possible cases in which its ViewController can be presented. Even if we do put that case in, ListWireframe now has two responsibilities, violating the SRP.

You end up thinking "Hmmm. I need to make an iPad-specific Wireframe class for List".

Another thing is, it also knows about AddWireframe, which means that if you were to lift the whole file hierarchy of List out into a separate project just to run it against some test table of TODOs, the code won't compile: AddWireframe is an inherent collaborator of a list.

This just isn't right to me. What wireframes do (navigation) is actually application-specific. It doesn't belong in modules. I see wireframes not as classes, but rather, protocols that let Presenters 'request' navigation behaviours from some super-module. Only the super module (in our case, probably a RootWireframe knows about both List and Add such that it can get them to work together. i.e. the super-module 'routes' navigation requests to the relevant module, so that e.g. Add can present itself from the List viewController.

Any thoughts? Have I just completely missed the original intention behind Wireframes?

When I've opened the VIPER-SWIFT in Xcode 6.1 it doesn't built

Will this project support to Swift 3.0?

the project does not compile.

xcode 7.1.1
swift 2.0