watchOS 2 framework failing

Would love to know, too, if watchOS 2 supports dynamic frameworks. We completely refactored our code into a framework in order to support Apple Watch. It would be a nightmare if we had to reverse all this just because watchOS 2 doesn't support frameworks.

I'm seeing the same thing, but the more I struggle, the more I think this is expected. If you notice, when you add a new target, there's a new Watch Framework target. If I add a new Watch framework, I have no problem doing an @import of it. Think about the current frameworks. The framework code lives on your phone. The reason shared frameworks worked before was because the Watch extension and iPhone app both were on your phone. Now, the code for the Watch extension and the iPhone app are on separate devices. While the code might be the same, the code is hosted on physically separate devices. An official comment from Apple would be good, but after messing with search paths for a while and then thinking about the situation, I think it's accurate to say that your shared code is going to need to be duplicated. In my case, this is several constants and networking code.

It would be great if Xcode could do this duplication for us, in some sort of omni-framework that automatically gets installed on both devices. After confirming this is as expected, a radar will be filed.

Remember, there are two ways to share code between targets - frameworks, and just including the .m or .swift file in multiple targets using Xcode's inspector. I've not started using Xcode 7 yet, but in one app I have a framework that is shared between the iOS app, the iOS today widget and the watchOS 1 extension.

From what you've described, that framework isn't going to work with a watchOS 2 extension because that extension runs on a completely different device. Which makes perfect sense! However, instead of creating a new Watch Framework target, including the same files in that target as in my existing framework and linking the watchOS 2 extension with that framework, an alternative might be to simply add those files to the watchOS 2 extension, cutting out the need for a framework entirely. There's not more than one target running on the Watch to share code between, so a framework doesn't really save you any space (which it does on iOS when used by multiple targets).

In my case, not all of the code in my current framework will be applicable because some of it was for sharing data between the app, today extension and watchOS 1 extension using App Groups. That won't work for a watchOS 2 extension, so there's going to need to be code changes anyway.

It didn't even occur to me to have the same source files for multiple targets. It looks like this was implied on this thread. In my case, you are right that because there's only one watch app using code in my framework, I won't save space (I'll potentially use more space). However, because I've already isolated much code into a framework, it should be a simple migration step to add a Watch framework and add all the source files to this new target. I could add these files directly to the watch extension target and avoid app groups on the watch, but I think I'll stick with the framework for now. You never know when you'll have a second watch app.

I'm trying to migrate an existing app with a framework shared between an iOS app and watchOS 1 extension and have realised that there's a very good reason why you might want to create a new watch framework target with the same files instead of just including the files directly into the watchOS2 extension target: resources. If the framework contains resources (e.g. Localizable.strings) then you want to ensure that the watchOS2 extension gets them in addition to its own resources.