You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: