Cocoapods: Should pods be binary or source?

[dodikk]

Created a new thread since it has been considered as off topic in #2729

[dodikk]

Unfortunately, cocoapods are used as an automated drag&drop tool these days. Instead, it should be more similar to NuGet or Maven.

@alloy , It would be really nice to see more developers distributing binary pods (*.lib / *.framework)
and the cocoapods team encouraging the maintainers doing so.

[segiddins]

Me:

I don't think we want to encourage people to distribute binaries over code.

@alloy:

I agree. You should be able to easily inspect the source that you are pulling into your project, as such I only see downsides to this and very little upside (some speed).

[segiddins]

Instead, it should be more similar to NuGet or Maven.

@dodikk, please explain (1) what is different about how those dependency managers work (2) what benefits such an approach would have over the way CocoaPods currently works.

[dodikk]

Actually, I suggest using both approaches and let the users choose between speed and "viewing sources". For example,
http://cocoapods.org/?q=ESLocal

[dodikk]

what is different about how those dependency managers work

The mentioned managers work with compiled languages such as Java and .NET. And they serve the pre-built binaries - not the source code.

Swift and Objective-C are compiled languages as well. However,

1. Most pods are distributed in a source form as of now.
2. Most maintainers do not even know it's possible to ship binary pods.
   ( from my experience)

[segiddins]

OK, but you still haven't answered the second (and more important) part of my question: why would _encouraging_ people to ship binary pods be a good thing? As far as I can foresee, there are only downsides to it.

[dodikk]

why would encouraging people to ship binary pods be a good thing?

1. The users will have a huge compile time speed up
2. Pods will have higher quality and be maintained with more care
3. Better encapsulation. The user will be able to access only the classes provided in public headers of the library/framework (without "practical runtime hackery").
4. The libraries will be used as designed by their vendors.
5. It will be easier to combine pods with manual dependency management approach via "no integrate" flag. ( Pods are good for stable projects. Manual approach is better for components under active development)

As far as I can foresee, there are only downsides to it.

So what are the downsides? Could you please list them explicitly (in turn)?

[dodikk]

You should be able to easily inspect the source that you are pulling into your project

Why do you find it that much critical? From my experience, the third-party libraries are changed very seldom. The developer is focused on his own features.
If some bugs arise on some iOS update (or whatever other reason) the plural approach allows switching to the sources easily and debug the issue.

[segiddins]

I see so evidence for (2), (3) is already accomplishable with podspec attributes for public + private headers, (4) has the same problem as (2).

Downsides?

1. User is unable to control compile-time settings
2. The user has to trust the binary the download, as opposed to being able to inspect code themselves
3. Symbol conflicts will occur (or be much harder to avoid) when two pods have a common dependency
4. It becomes much harder for users to contribute back to the pods they use
5. When changes to the toolchain occur, they are more likely to break binaries than source -- see the introduction of ARM64

[dodikk]

1. User is unable to control compile-time settings

The library has been designed the wrong way. See (2)

The user has to trust the binary the download, as opposed to being able to inspect code themselves

From my experience, most people do not bother looking inside the library code before "pod install".

Symbol conflicts will occur (or be much harder to avoid) when two pods have a common dependency

The library has been designed the wrong way. Never link static libraries into other static libraries.
The dependencies should be resolved by the engine.

It becomes much harder for users to contribute back to the pods they use

Please explain. Since the sources are available at github, it's the same effort. You'll have to create your own fork anyway.

When changes to the toolchain occur, they are more likely to break binaries than source -- see the introduction of ARM64

This is a problem indeed. However, when such changes occur the code will have to be fixed anyway. Otherwise there are high chances of crashing at runtime. Otherwise the library is abandoned and... Are you still really going to use it ??? (and again : 2 - pods quality)
Plus, you always have your source version as "plan B".

[orta]

This doesn't persuade me, I trust CocoaPods to set up and maintain projects way more than I'd trust the average developer.

I think advantages like being able to see the full source code for stack traces, having lowering the barrier to making changes both for yourself and to the population back in general mean that I would be against making this a default. It sounds like something that could be build as an optional plugin for people that want this kind of functionality.

Though regardless of the state of this issue, the eventual addition of xcodeproject based pods would mean if people wanted to build their own libraries in this fashion they could.

[dodikk]

There is no need for the plug-in. The feature is available and works fine.
However, it is not adopted by the community. It is used mostly for just wrapping testflight and google analytics https://github.com/CocoaPods/CocoaPods/issues/98

And it can be used for something more than that if more maintainers cared. I believe your users would appreciate the possibility to choose between detailed stack traces and fast compiling. This is something that should be done by the community. However, you should be able to drive it to that direction.

Unlike me. You're right : I am nobody. But it's not just me who prefers such approach
https://github.com/CocoaPods/CocoaPods/issues/1696

And I guess there are some people who are too shy or lazy for writing issues like this )))

P.S. It would be nice if you initiated a poll on this topic to definitely know that "nobody needs this feature".

[AlexDenisov]

I'm not the politest guy, so take my apologies in advance.

I'm totally agree with @dodikk.

Pods distribution in a binary form:

• incredibly reduces compilation time
• should reduce pod install time, because we don't have to clone each repo with all the 'trash' like foo.xcodeproj, sampleFoo.xcodeproj, etc., but just a binary/framework with the foo.DSYM, for debugging
• might increase quality of libraries
• it's a more natural way of distribution packages in the world of compiled languages: that's why we don't have to compile libc, libffi or clang every day.

Conuter-counter-arguments:

User is unable to control compile-time settings

Can't even imagine situation when you really need this

The user has to trust the binary the download, as opposed to being able to inspect code themselves

You can't inspect source code of proprietary library (e.g. Crashlytics, GoogleAnalytics), but you still can inspect the source code of the open-source library, and, probably, make binary on your own, if you really don't trust the developer

Symbol conflicts will occur (or be much harder to avoid) when two pods have a common dependency

It's maintainer's responsibility. As I remember CocoaPods had the same problem in the beginning.

It becomes much harder for users to contribute back to the pods they use

Why? Based on my experience people usually make changes and push them into their project. It's so easy to do, but almost impossible to merge with updated version of the library.

IMHO, choice between 'right way' and 'easy way' is obvious.

When changes to the toolchain occur, they are more likely to break binaries than source -- see the introduction of ARM64

It's also maintainer's responsibility. Otherwise, how could you rely on an unsupported library?

As already mentioned, sometimes even source code should be changed to work properly with a new toolchain/CPU/whatever.

Just to ensure that we're on the same page:

I'm not saying that _you_, guys, personally _should_ implement this feature.

I'm not saying that this behaviour should be used as a default one.

I'm just saying that would be nice to have it, but there is no support from Core Team, only weird counter-arguments, which sounds like marketing.

[alloy]

Just to ensure that we're on the same page:

I'm not saying that _you_, guys, personally _should_ implement this feature.

I'm not saying that this behaviour should be used as a default one.

I'm just saying that would be nice to have it, but there is no support from Core Team, only weird counter-arguments, which sounds like marketing.

@AlexDenisov @dodikk I think we were definitely not on the same page. I’m not sure what type of marketing you mean, the main issue is simply that how we describe it is how _we_ personally prefer to use code.

Having said that, I think that more people would like this, so if you want to take this on then, by all means, please do!

Once there is a working concept we can discuss considerations and details much better. As such, I think it would be a good idea to somehow make this a plugin for now.

[k0nserv]

It's already possible to distribute binary libraries instead of source code. Would anything need to be implemented at all for this to be supported? To me it seems like the discussion is rather about what should be encouraged and encouraging source distribution is definitely a better idea imo, simply because it encourages open source.

Further on the speed side of things since CocoaPods compiles all dependencies into one static library the speed improvements would be marginal since they only really apply when doing a clean build(please correct me if I am missing something here)

[AlexDenisov]

Once there is a working concept we can discuss considerations and details much better. As such, I think it would be a good idea to somehow make this a plugin for now.

I'll talk details with @dodikk first, and then we'll reach you with a summary, it would be more productive and efficient, imho.

Would anything need to be implemented at all for this to be supported?

The biggest problem is - maintainers. Nobody wants to do this, 'cause it requires some extra efforts to do in a right way.

and encouraging source distribution is definitely a better idea imo, simply because it encourages open source

Don't think so. The best way to encourage FOSS - provide high quality FOSS, with a few ways of distribution.

improvements would be marginal since they only really apply when doing a clean build

Yes, you're right. And it may have advantages on a CI server: on one of my projects a have three test targets and compilation time takes too much time, which is just redundant and, imho, a wasting of time.
But, even for a first build time I don't really want to wait. I didn't add changes to the dependencies - why I have to re-compile them?

[orta]

Alright, I'm closing this, since this was discussed other platforms have come that fit the mental model you're talking about for cocoa dependencies. Also, someone could build this as a cocoapods plugin so it works for everyone with a few days worth of side-project time.

[koxon]

Being new to IOS builds, I have to say I was very surprise of the compilation time.

Changing compilers parameters sounds irrelevant as the hardware is tightly controlled.
On the other hand, speeding up CI systems, auto builds and local tests is certainly a big plus.

Like other dependency systems, shipping binaries should be the default behavior.