📚 Framework-Driven Development
updated 12 months ago; latest suggestion 12 months ago
This proposal has been withdrawn...
For me and my teammates, as we are working on a big mixed (Objective-C and Swift) project that constantly grows, it gets harder and harder to work with constantly increasing codebase - incremental build times are increasing with each new feature, which makes us simply staring at Xcode/AppCode for longer and longer time. This lead us to rethink the way we are building our app and we've decided to try out separating our app into frameworks, and when possible, even into static libraries. This has opened our eyes on the spaghetti-code problem that we had here and there, showed us how dependant different modules from each other are, even though that they shouldn't be. This has improved our code-health and separation of concerns.
I would like to dedicate this talk to show approaches of decoupling you codebase into different frameworks, difficulties that might arise while separating your codebase between 2 and more frameworks and ways to solve them.
This talk will use default Xcode as well Cocoapods in order to show how Pods can be integrated into frameworks.
Thanks for the question. Absolutely - my talk is going to be about how to separate ANY project into frameworks. It is going to include steps to create a framework, integrate it into the main project, fix imports, set framework's build settings and so forth. These steps can be done in ANY project as they are quite general ones and they don't differ from project to project. They only thing that is project dependant - what developer wants to extract into the framework. Other things are general and the same for any project.
Maybe as someone who designs apps with frameworks from the start, I'm having a hard time seeing this, but it seems like this talk will rely on a tremendous amount of the specialised history of your own application. How much of that is truly general enough to be applicable to the majority of attendees?
Will you be presenting approaches that are reproducible enough that others with different situations and a similar desire to modularise their application might find benefit from them?
I have just updated this proposal, thanks for your input!
What approaches? What tooling? Pros and cons of this approach?