Should you use targets for code you don't own? - xcode

I am using this third-party view control in my project https://github.com/nicklockwood/SwipeView That project does not support CocoaPods or Carthage.
Note: my entire project is Swift and this other code is Objective-C.
To integrate this into my project I just dragged in the .h and .m files into my project.
Is this the proper approach? Instead should I have created a new target and put those files in there? Are there any considerations for me to make this choice?

I've used this technique (separate targets building static libraries) for third party code - even when that library does support CocoaPods or Carthage.
One benefit for me was when there were breaking changes, particularly with newer versions of the tool chain, before the third party code was updated. It was straightforward to disable e.g. certain newer compiler warnings in that target alone while keeping the rest of the project as clean / safe as possible.
It's also reasonably tidy when mixing Obj-C and Swift.
I haven't found a downside, as long as you're happy to manage the project integration yourself (that might otherwise be handled by CocoaPods). I only tend to have one or two third-party libraries in my macOS projects.

Related

How to manage vcpkg across many projects?

I would love to use vcpkg to manage our dependencies with third party libraries, but I'm not sure how this is would work in our environment. We have hundreds of projects in our solution, and release new versions of our software over time. This is a very common situation for software development, but I don't understand how vcpkg can work effectively.
Global installation will not work. We need to tie our releases to specific versions of packages. So we're left with using manifests. In a manifest, you specify a "builtin-baseline" which is a great way to pin the build of a project to a point in time, with some guarantees that the dependencies between the different packages are correct.
This is all great for a project. How does one manage hundreds of projects?
We would like to use the same baseline across all projects. Is there a way to specify the builtin-baseline in one place?
Some packages are common to all projects. Is there a way to specify this in one place?
We use project files for building. By default, vcpkg uses a project-local install directory. We don't need 100s of copies of boost. There is a vcpkg project setting for "Installed Directory" which allows a global location. But again, this setting is per-project. I don't see any integration with .props files. Is there a way to manage this?
Is there a way to get a solution-wide listing of all packages?
Would using CMake make this all easier?

Importing KMM library in multiple iOS modules via Cocoapods results in "... implemented in both ..."

I have been maintaining a shared library built with Kotlin Multiplatform for our Android and iOS native apps for quite some time now. Was working great until I decided to split the iOS app into multiple modules (frameworks). For starters I have one iOS app project and two dynamic frameworks, which are used by the app project. All 3 projects are using Cocoapods for 3rd party dependency management. Own modules are imported via framework embedding. No Cocoapods for the own modules needed, because we don't plan to make them available to other projects.
So the issue I am facing now is that whenever I import the KMM framework into more than one of the modules via Cocoapods, the build succeeds, but I receive errors at runtime like
Class MyClassInKMMProject is implemented in both
/Users/{user}/Library/Developer/Xcode/DerivedData/MyApp-hcbcxlfmsfiiqaccahedgcclxmiq/Build/Products/Debug-iphonesimulator/Common.framework/Common
(0x1189318d0) and
/Users/{user}/Library/Developer/Xcode/DerivedData/MyApp-hcbcxlfmsfiiqaccahedgcclxmiq/Build/Products/Debug-iphonesimulator/Core.framework/Core
(0x112a77ea8). One of the two will be used. Which one is undefined.
Since I need the shared KMM library basically in every module, I am stuck right now with this issue.
In some community I remember that someone mentioned static libraries can be imported only once when using multiple modules. But as far as I understand KMM generated frameworks and not static libraries.
I also tried using XCFrameworks instead of Frameworks, but it didn't change anything.
Anyone here knows how I can fix this?
Tried to find a solution for several days, but just found it after writing this question.
Adding isStatic=false to Gradle was the solution, which I got from this post: https://stackoverflow.com/a/65420364/390542

Adding a project as a dependency in Xcode

I've been trying to add an Xcode project (a static library) as a dependency to another project (a framework). I've read about this issue, but I can't find what I'm looking for. Specifically, what I find is a way to add the static library binary as a dependency (in target dependencies), but this is not what I want. Instead, I have two projects configured in the same workspace. Similar to this:
(Image credits)
What I want is for the MyLib project to build when MyApp builds, if needed. I'm not just interested in adding the static library for linking. Is this possible?
Edit: I'm currently exploring the possibility of doing this using a Run Script. If possible I'd like a better alternative, though

How to create custom library with gradle `compile` support in AndroidStudio?

I'd like to create my own gradle library, that can be compiled into other projects using gradle compile statement.
Example from Picasso's README:
Download the latest JAR or grab via Gradle:
compile 'com.squareup.picasso:picasso:2.5.2'
I'm developing few applications that share common source: fragments, views, some logic... Sometimes I extend these sources while I'm developing app A, sometimes while I'm developing app B,... And I feel that copy-paste of packages/classes in Android Library Module is not an proper solution.
So I would like to setup my own library, that:
it could be easily deployed to as gradle library that could be used by compile.
I can easily develop/extend it together with currently developed application
Disclaimer: I had been googling it a lot, but without luck.
If you want to reuse a library across completely separate projects then you'll want to publish your library to repository. Assuming this is open source and you don't mind sharing, you could use JCenter, which is already added as a repository to Android projects by default.
https://www.virag.si/2015/01/publishing-gradle-android-library-to-jcenter/

Target dependencies vs. Link binary with libraries

I don't understand the difference between these Xcode features.
I'm building and app - but the functionality of the app is being abstracted into libraries (so they can be distributed separately as an "SDK").
So I have a workspace of library projects and the app project. I can add library projects to the app project by doing "link binary with libraries". This gives me a list of .a library projects in the current workspace which I can link to.
I can also add frameworks here.
In the "target dependencies" bit all I can add is other targets in the current project.
What I really want to do is both - I want my app project to build all the other library projects when I build it. I also want to make it verbose what libraries the app (and other libraries) depend on.
So can somebody please explain the difference, and whether what I am doing is the right way to go about it?
Many thanks!
It says here...
Drag your framework product (located in the Products folder) to the existing Link Binary With Libraries build phase of your application
target. This causes the application to link against your framework.
And...
In the General tab of the inspector window, add your framework as a dependency for the application. Adding this dependency causes Xcode to
build the framework target before building the application target.
The build dependency you establish in the application target causes
the framework to be built before the application. This is important
because it guarantees that a built version of your framework will be
available to link against and to embed in the application. Because of
this dependency, you can set the active target of your Xcode project
to your application and leave it there.
So it seems that you're supposed to use both. Seems redundant though, because if you're linking to a framework then its a dependency. I suppose you might want to only link to a library and not build it first. Although Xcode seems to build linked libraries even without them being added to the dependency section. Perhaps that's a result of the "Find Implicit Dependencies" option in a scheme's build settings.
I do something similar and was explicitly setting the 'header search path' and 'library search path' in the final executable target. However this all depended on where the objects were being generated. Initially I had set this to be within the source tree (actually a sibling directory called build), however after changing the location of the Xcode DerivedData directory and telling it to build into that directory, the projects no longer built.
The final solution was simply to remove the explicit setting of the 'header/library search path' and set the target dependencies correctly. This resulted in the project building for debugging and archiving without issue.

Resources