very intersting article; thanks for that and your provided solution.
In our company, we faced similar problems, as we have a very modular environment in which every 'module' is an own *.framework.
We were also unhappy with the dependency management with cocoapods, third-party libraries, recursive dependencies, dependency conflicts and so on.
For this reason, we migrated all our projects to kind of a manual dependency management.
But we didnt build it our own: We used gradle!
That was a very good choice.
How does it work from the console (sketch):
we run ./gradlew build to build a framework, or the app itself
Our gradle-build-task depends on the download and extraction of the gradle/maven dependencies of all used frameworks
in xcode, we define the framework dependencies to local *.framework files
if we build framework, the final framework is published to our gradle/maven repository, including in the maven description the transitive dependencies to other modules
How does it work from XCode (sketch):
We have a prebuild-task to run as external tool: `./gradlew dependencyUpdate' which downloads all dependencies
reason: if you checkout a module, you can directly build it from xcode, without the need to open the console
How do we handle external libraries:
We upload all external libraries also to our gradle/maven repository
If an own module depends on such an external library, it can define its dependcy also in gradle
There are two downsides:
You need to manage new versions of external libraries by yourself and re-upload the new version to the maven repository (cannot automatically find new versions)
For closed-source PODs it can be tricky to tranform their artifacts to reusable frameworks or static libraries
All in all, the positive aspects outweigh the downsides:
You use a well-known dependency management system, dependency conflicts are shown during build time. The use of gradle not only allows dependency management, but we also added build-tasks to easily and automatically increase version, publish modules to maven and tag our git repository.
Dear @DmitryBespalov,
very intersting article; thanks for that and your provided solution.
In our company, we faced similar problems, as we have a very modular environment in which every 'module' is an own *.framework.
We were also unhappy with the dependency management with cocoapods, third-party libraries, recursive dependencies, dependency conflicts and so on.
For this reason, we migrated all our projects to kind of a manual dependency management.
But we didnt build it our own: We used gradle! That was a very good choice.
How does it work from the console (sketch):
./gradlew build
to build a framework, or the app itselfHow does it work from XCode (sketch):
How do we handle external libraries:
All in all, the positive aspects outweigh the downsides: You use a well-known dependency management system, dependency conflicts are shown during build time. The use of gradle not only allows dependency management, but we also added build-tasks to easily and automatically increase version, publish modules to maven and tag our git repository.