On Friday, February 13, 2015 at 12:52:51 PM UTC-4, Jens Alfke wrote: > > > On Feb 13, 2015, at 8:16 AM, Kevin Lord <[email protected] <javascript:>> > wrote: > > The main problem appears to be twofold: > - Apple dropped support for using a bridging header within a framework > target > - You cannot import a non-modular header into the umbrella header for the > framework > > > Could you explain this in more detail? (I haven’t used Swift much, yet.) >
So the idea is that in a normal application target you can make any Obj-C code in the target accessible from Swift by adding the relevant headers to the bridging header for the target, which is a fairly standard header that's simply specified as a bridging header in the build config. Unfortunately, for whatever reason, in one of the later Xcode 6 betas Apple dropped this idea for the new iOS dynamic framework targets. Instead, there is an umbrella header for the framework that is used to export all public API, but is also used as a bridging header for the framework. However, unlike the standard bridging header, you can only import headers that are marked public and part of a Clang module. At least that's how I understand it. Here's another case of someone running into an issue with a similar library / setup (FMDB w/sqlite): http://programmingthomas.com/blog/2014/7/23/sqlite-in-swift-frameworks Also, here's a little more background from Cocoapods on all of this: http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/ > Are there any plans to add proper CocoaPods support instead of the > vendored framework method currently used? > > > I don’t think so. We prefer to build Couchbase Lite ourselves and test the > actual bits we build, then release exactly those bits. That way we know > what people are getting. The CBL/iOS project and repo structure are fairly > complex and I really don’t want to be in a world where I have to deal with > every developer having to (indirectly) check out and build it themselves. > > It seems the solution is to add an additional iOS framework target that > defines a module, however I'm still trying to wrap my head around all of > this. > > > The root of the problem is that for some reason Xcode has really > half-assed support for distributing iOS libraries in binary form. Unlike OS > X there’s no official support for frameworks, although you can assemble > your own pseudo-framework by putting a static library inside a “.framework” > directory, which is what we do. > > Worse, Apple never addressed the problem of creating libraries that can be > used for both device and simulator builds. First, you can’t create both > libraries in one build action: you have to build, then manually switch the > scheme’s destination between device and simulator, then build again. > Second, you end up with two copies of the library (one for each platform) > that both have to be added to the developer’s app target, and then (IIRC) > one or the other of them will trigger link warnings on any build because > they’re for the other architecture. There is a half-assed solution for this > involving a very nasty build script that recursively invokes xcodebuild to > build the ‘other’ architecture, then uses lipo to mush both builds into a > single fat .a file. > > Things look like they’ll be better in the future because iOS 8 has finally > added support for dynamic library loading, so (I think) we’ll be able to > build as a real dylib-based framework. (I say ‘I think’ because I haven’t > tried this yet.) But before we can do that we have to wait until our app > developers don’t need iOS 7 support any more, which is probably a few years > away. > > —Jens > Yeah, it is kind of a mess. I definitely understand your points, however I have a feeling that there will need to be some kind of solution much sooner than when iOS 7 support can be dropped. Apple has really been pushing developers to start moving shared code into these dynamic frameworks, especially with the advent of extensions. We're already only supporting iOS 8+ on any new apps being developed, partly for this reason. One of the most obvious first things to put into a framework is your model level code so it can be easily shared between app and extension, but this is currently exceedingly difficult with the existing build targets in CBL. It seems to me that one potential solution is to simply create an additional dynamic framework build target with a deployment target of iOS 8+ with 'Defines Module' set to YES, that those developers can use, while other users can use the existing targets. Might this be an option? I'd really like to avoid having to fork for our internal use, especially as I imagine other developers may soon face the same dilemma. :/ -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/f7a9efda-f3eb-446b-9ff5-121f9e107970%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
