🎉

@kylef mate come down here i got infoz

👍

Isn't there a comparable change in xcodeproj that we have to make?

I don't think xcodeproj needs to be changed, the CocoaPods use of Xcodeproj needs to be changed. Instead of using static libraries, a framework should be made. There is also a EMBEDDED_CONTENT_CONTAINS_SWIFT compiler flag. I think #2221 should make it work.

Of course, to keep compatibility we need to support both static libraries and frameworks.

https://github.com/CocoaPods/Xcodeproj/blob/master/lib/xcodeproj/constants.rb

we need to find out if frameworks are supported in iOS backwards

@segiddins there do not appear to be any new constants added to the .pbxproj that would be relevant to Xcodeproj after some poking around.

Yeahh man, nice! Can't wait to see this completed! 👍

Okay real talk here we need to think about the architecture going forward.

Swift needs .frameworks. I don't know if that's iOS 7 out the window. I assume it is.

We can do things in two ways:

• if iOS 8 then build every pod as a framework
  • if we do this then we might as well cut down the Podspec and just directly clone a repo as a submodule and integrate the designated .xcodeproj that produces the framework, leaving CP to manage versioning etc.
• if Swift then build that Pod as a framework, leaving ObjC ones around as normal
  • but if the Swift pod depends on an ObjC pod we need to generate bridging headers (complexity++)
  • or we can build that pod as a framework and so on

I'm leaning towards the first approach for simplicity. I had a go at it, Xcodeproj supports creating frameworks (undocumented). We need to make it do that, cut out the aggregate link phase and make the pods resources get bundled in the framework.

HOW DO WE FACTOR THE LAST SENTENCE PROPERLY?
HOW DO WE CHECK IF IOS 8?
IS THIS THE RIGHT APPROACH, TO LEAVE IOS 7 PEOPLE BEHIND?

Forgive my ignorance (I'm not a contributor yet nor understand this on your level), but it seems that leaving iOS 7 behind means Swift CP support being half-helpful (if even) pre-iOS 8 and not fully helpful until at least next April/May when most people start dropping iOS 7 support.

Complexity++ sucks, but building a real iOS 8 app using Swift-only dependencies is currently a fantasy, so we probably just have to work toward assumption that there'll be a lot of Swift/ObjC intermixing. This will probably last for awhile seeing as Swift adoption may not be that fast once the initial excitement comes down and people realize Swift is still kind of raw. Dunno.

It's English - nobody knows how to factor sentences properly.

Swift needs .frameworks. I don't know if that's iOS 7 out the window. I assume it is.

Swift is backwards compatible with iOS 7. It will not work with Xcode 5. So the discussion is how to support the new changes in Xcode 6/Swift, and still support Xcode 5 for those who can't upgrade.

I've played around with the new frameworks stuff in 6, and most of what CP does can stay the same. We'll just be creating a .framework instead of libPods.a and linking against it instead of adding a Target Dependency. This can be done without the use of a workspace, but I like being able to see the source of code I'm using while still in my project.

We'll still need a Pods.xcodeproj to generate the .framework, we'll still need to reference it in our targets. The rest of the framework discussion should continue in #2221.

Cool. Let's get this show on the road !! :)

@gamenerds I didn't say Swift-only – I mean embedded frameworks only. And I meant "how to take that sentence and make a sensible OO solution to requirements expressed within".

@mtitolo This still doesn't address the issue – can we have embedded frameworks in iOS 7?

@swizzlr @mtitolo only thing related to this I could find is this: https://devforums.apple.com/message/977606#977606

So it seems, no is the answer.

@neonichu @swizzlr sad 🐼. I hadn't actually tried it, but it does look like embedded frameworks won't work on iOS 7.

So, IMHO, in addition to frameworks, CP should also be able to generate a bridging header for all Pods, so that one can properly write Swift apps which support iOS 7.

Can we make a static lib with Swift that's still importable? Somehow generate the mmap?

But that's a question that's quite complex. For now I think we should have the MVP of adding a "Framework mode" which is enabled when using Swift pods or asked for.

Really eager to see how this turns out, just thought I'd add some useful info for those who don't read compiler docs for fun. The following points only refer to exposing Obj-C modules to Swift / Obj-C code:
To import a module in Objective-C you can use the following syntax since Clang 3.5:

 @import mod.submod

The clang compiler finds these modules via a mod.modulemap file with syntax like this:

module std [system] [extern_c] {
  module complex {
    header "complex.h"
    export *
  }

The clang docs might be a useful basis for discussion for those who haven't read them:
http://clang.llvm.org/docs/Modules.html

This module map functionality was originally intended for exposing Objective-C/C code as modules, to solve some of the horribleness of linking .h files in a backwards compatible way, and it works fine in XCode 5.

As I understand it, a framework can be avoided, as @swizzlr mentioned all you need is a modulemap.

Paths to including this could be (these might be wholly useless suggestions, just being constructive):

Manually creating the module maps

Add a config option like

:module_map_file => 'blah.modulemap'

In this case the module author could specify the location of the module map

or

All module-related config in the Podspec

e.g.

:modules => {
:blah => {:headers => ['blah.h], :export => '*'}
}

To specify all of the available options for the modulemap DSL
This seems much more complex given how much flexibility there is in the modulemaps but it potentially presents a faster route to migrating code as all libs with podspecs can be adapted without any code change in the lib itself). I'm not sure which path is better.

@swizzlr @mtitolo @neonichu I'm actually using a swift module, as a framework, as part of a swift application that is targeting iOS 7.1, and runs just fine on my 5s running 7.1, so i don't think 7.1 vs 8 is a factor, just xcode 5 vs 6.

@rjsamson That's super encouraging to hear! We need some clarification from Apple on this, for sure.

@mfrawley Bloody excellent investigating. Does anybody want to try doing this with a static lib and handcrafted mmap?

@kylef Do you mind if I edit your original post to add a task list?

@swizzlr Go ahead 👍.

Can we do a google hangout session about this, so I can get up to speed about all this stuff and your thoughts? (Anyone that has info, not necessarily existing CP contributors.)

I have a conference at the end of this week, so I can’t guarantee being up-to-speed before than, therefor I propose Monday the 23rd: http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140623&p1=16, during working hours preferred.

What about 4pm Amsterdam time, http://everytimezone.com/#2014-6-16,120,cn3 ?

Sounds good to me!

Cool, re-iteration, this is welcome to anyone whose either done some digging into support or knows about how obc/swift integrate, I'll put a hangout link in here 10ish minutes before.

I’m available from 19:00 to 23:00 GMT.

https://plus.google.com/hangouts/_/gxh2etxcmg7sjazb6ldccct6wma

So will this be merged to add Swift support?

Way too much work left to do.

Hello, what was the result of the Hangout session?

@danthorpe That's all outlined in #2272.

Create bridging headers

Rather, wouldn't we want to identify (+ create if necessary) the bridging header and import a root header for each pod?

There's something worth thinking about that bridging headers need to be user edited.

I see two reasonable ways to handle it:

• The first time CocoaPods can check for a header with the same name as the lib, and if that exists add that to the bridging header but from then on basically doesn't edit it
• Have a /// CocoaPods Generated Headers section that CocoaPods edits below giving the user the chance to make changes without being overwritten on the next pod install.

@orta @segiddins The bridging header should be the frameworks header which should exist most of the time, most frameworks/pods expose a single header to import. If there isn't one, we could generate one importing ever public header as @orta suggested. Example: https://github.com/QueryKit/QueryKit/blob/master/QueryKit/QueryKit.h

@kylef this already needs another rebase

I think this is superseded by @mrackwitz, but I have pushed this change incase it is needed to be cherry-picked elsewhere or merged

@orta @segiddins Bridging headers are not supported in embedded frameworks, so that cuts the problem right away. Why not generate both Targets: Embedded Frameworks dynamically linkable (for usage in iOS8+) and static libs for the rest. Starting iOS 8, one should not rely on static linking as the recommended pattern involves dylibs for shared code between appExtensions and main app. Statically linked, that will produce ugly duplicates!

That should make the development easier, and also can be based on the platform flag of the podfile no?
And yes you can mix swift and ObjC in EF without the bridging header but that's messy all the way. Pods should be cocoa or swift, not mixed don't you think?