Thanks Sidney, I'll take you up on that. Yeah I know the pain of the static framework -- we had cordova-ios as that once (pre 3.x I think), using that workflow you mentioned, it was indeed tedious.
As for dynamic frameworks -- I managed to track down an iOS 7 iPhone, and without any changes to my PoC (aside from fixing a crash because I used an iOS 8 only API), using it as is with dynamic frameworks, it all works -- so I'm not sure what the deal is, perhaps it's because I weak linked them, dunno. I think this proposed all-encompassing change is risky, and I don't want to delay cordova-ios 4.x especially since there is still lots to do, so I'm proposing two stages: Stage 1: 1. Remove CordovaLib subproject from app template 2. Add workspace with two projects: CordovaLib, and the app template 3. Make the workspace build in Xcode 4. Make the workspace build in the command line 5. Test with cordova-CLI Stage 2: 0. Whatever tasks needed to get plugins as frameworks, a gajillion steps, see README If there's time, do Stage 2, if not, punt to cordova-ios 5.x On Tue, Mar 31, 2015 at 6:28 PM, Sidney Bofah <sidney.bo...@googlemail.com> wrote: > Hi Shaz, > > i take my hat off your efforts and initial analysis - after initial “if it > isn’t broken…”-based doubts, i now also think migrating > the iOS Cordova template structure to XCode workspaces is the best longterm > approach. > > Addendum to your analysis: > iOS “.frameworks" are not restricted to iOS 8+ per se, only _dynamic_ > frameworks (dylibs) are. That is, _static_ frameworks can > be bundled since i-don’t-know-when. From a workflow perspective it used to be > tedious though, as one needs to build for ARM > and simulator, then merge the resulting Mach-O executables via the lipo CLI, > etc. - but in XCode 6, Apple made this easier by > providing a template for this (and there were third party framework templates > as well). > > Based on these experiences, I created a workflow for myself to get from a > popular iOS cocoa control to a Cordova plugin in less > than a day (for a simple framework with a few methods to expose via > CDVPlugin). As we all know, Plugman has been supporting > custom frameworks for a while, and can then copy to the platform folders and > reference those files, which works flawlessly. > Attached my repo links [1], i’d be glad to assist with any questions if > that’s useful for the .xcworkspace migration process. > > Best regards, > Sidney > > [1] > https://github.com/SidneyS/GCDWebServer-static-framework > https://github.com/SidneyS/MRProgress-static-framework > > >> On 01 Apr 2015, at 02:41, Shazron <shaz...@gmail.com> wrote: >> >> ISSUE: >> https://issues.apache.org/jira/browse/CB-5921 >> >> PROOF OF CONCEPT: >> https://github.com/shazron/CB-5921 >> >> I took it onto myself to create a proof of concept on how this could >> work. Check out the README for the conversion details: >> https://github.com/shazron/CB-5921/blob/master/README.md >> >> TLDR; The essence of it is: >> >> 1. There is a workspace that contains: CordovaLib, the user's project, >> and N plugin framework projects >> 2. CordovaLib is no longer a subproject of the user's project >> 3. CordovaLib contains a target that will create a Cordova.framework >> 4. Plugins are iOS Framework projects (adding a plugin requires adding >> an xml line in xcworkspace, and framework refs in the user's project ) >> 5. Plugin JS is still installed by the CLI unless we find an alternative >> method >> 6. The CLI needs to be changed to do (4) >> >> Implementation details are in the README referenced above. >> >> BENEFITS >> >> This makes it all modular especially the plugins. Plugins are >> frameworks instead of static libraries because some plugins contain >> resource bundles that need to be included, and frameworks provide this >> functionality. Workspaces have been there since Xcode 4, and are used >> by a bunch of other package managers (Cococapods), it will be good to >> work well with other packaging systems if we can. Also, plugin >> installation is simplified. >> >> Cordova is a framework so there will be no duplicate symbol problem >> when linking a plugin into the user's project. >> >> POTENTIAL PROBLEMS: >> >> 1. I haven't tested this on iOS 7 devices yet though (since iOS >> frameworks are iOS 8 only -- but they should still work if weak >> linked), I'll have to find a device and report back. >> 2. cordova-cli platform version issues: if cordova-ios 4.x supports >> workspaces, and you are on a cordova-cli that doesn't know about the >> new template format (but you installed the new platform anyway), it >> won't work >> >> Send me your comments, ideas, etc... >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
