> On Feb 13, 2015, at 8:16 AM, Kevin Lord <[email protected]> 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.) > 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 -- 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/C28CF747-267C-4A7E-96FB-933C25391F51%40couchbase.com. For more options, visit https://groups.google.com/d/optout.
