Convert to just using CocoaPods for dependencies

[orta]

First time contributor checklist

• I have read the README and CONTRIBUTING documents
• I have signed the Contributor Licence Agreement ( I did this a few years ago )

Contributor checklist

• I'm following the code, UI and style conventions
• My commits are rebased on the latest master branch
• My commits are in nice logical chunks
• My contribution is fully baked and is ready to be merged as is
• I have tested my contribution on these devices:

• Simulator

---

Description

Removes Carthage as a dependency manager, it looks like it was still around for legacy reasons and was only being used to handle a single dependency that was available on CocoaPods. This simplifies the setup process, removes a build phase script and requires less maintenance.

I also took a quick look over the Podfile and simplified that a bit by using the implicit abstract_target.

Fixes #1471

[michaelkirk-signal]

Thanks for the PR, and thanks for your work on cocoapods, we get a lot of value out of it.

One nice thing about using carthage, especially with large frameworks like zxingobjc, is that we only pay the build tax once - we build the framework for all arches only one time. Whereas with cocoapods, it seems like every time I switch arches, or do a clean build, I'm rebuilding all frameworks, which happens not infrequently, and takes a long time.

We have some Pods which frequently change, and the cocoapods ergonomics have served that pretty well, but the majority of our dependencies rarely change, for which the carthage build-once-and-cache-artifact model (as I understand it) seems faster in aggregate.

So, even though I agree your changes simplify the setup process, I'm hesitant to make this switch, because I think it would hurt people who build Signal-iOS the most frequently (which includes me - and I'm selfish).

Is there something that we could do to ameliorate this with our cocoapods setup?

[orta]

You could use CocoaPods Rome, https://github.com/CocoaPods/Rome to pre-generate the frameworks in the same way and manually link the frameworks (like how it works with WebRTC) - it'd probably require adding a Podfile to a subfolder and compiling etc in there.

I've always wondered why people see these kind of issues but we don't at Artsy, my guess is it's because projects like this do a lot in work in dev pods and I wonder if CocoaPods/CocoaPods#8253 would allow scoping those to their own project meaning the more static pods would live in their own.

[orta]

Interesting, looks like there's this too: https://github.com/leavez/cocoapods-binary

[orta]

Alright, I've updated this PR to use cocoapods-binary which automatically inlines a static version of your library for XZing. I added some docs on it on the CocoaPods guides: https://guides.cocoapods.org/plugins/pre-compiling-dependencies.html

[michaelkirk-signal]

Alright, I've updated this PR to use cocoapods-binary which automatically inlines a static version of your library for XZing. I added some docs on it on the CocoaPods guides: https://guides.cocoapods.org/plugins/pre-compiling-dependencies.html

Just wanted to say thanks for looking into this - I haven't forgotten about it, but wanted to do some more internal testing with it.

Working to have less setup steps is definitely appreciated.

[breznak]

Bump. This looks like a great PR, is it going to be mainlined?

[Imperiopolis-Signal]

Thanks for your contribution @orta! Sorry it has taken us so long to circle back to this, but we have integrated this into our release/3.2.0 branch here 8f45f57