Big +1 from me: Being able to debug in to the IOS internals has saved me more than once. Usually a change in the internals isn't necessary, but often elucidates why my approach is failing, more than an error message (or a silently failing error) does.
My only potential concern is build time. My machine builds (from scratch) a Cordova project pretty quickly (a few tens of seconds at the longest). Any longer than that and places where you have to clean the project and rebuild might be frustrating. (Even so, I prefer being able to debug rather than having a fast clean build). Sent from my phone. ___________________________________ Kerri Shotts photoKandy Studios, LLC On the Web: http://www.photokandy.com/ Social Media: Twitter: @photokandy, http://twitter.com/photokandy Tumblr: http://photokandy.tumblr.com/ Github: https://github.com/kerrishotts https://github.com/organizations/photokandyStudios CoderWall: https://coderwall.com/kerrishotts Apps on the Apple Store: https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 Books: http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book http://www.packtpub.com/phonegap-social-app-development/book On Jun 17, 2013, at 14:48, Andrew Grieve <agri...@chromium.org> wrote: I'd like to propose that instead of having the create script compile a version of Cordova into a .jar, that instead it copies over the source files instead. My main motivation is that doing so will make debugging native code much easier since the source code will show up in Eclipse / Android Studio by default instead of needing to reconfigure your project to get this to work. We did the same change on iOS a while ago (moving from a precompiled framework library to just copying over source files), and I think the results were quite positive. It helps users file better bug reports, and I think also encourages them to submit bug fixes. It will also make it easier for Plugin developers to figure out our APIs since they'll be able to see & tweak the code. Agree / object?
