For WhirlyGlobe 2.1 we had a Cocoapod spec contributed by a user. I'm considering updating it.
Advantages
People really like Cocoapods. The project has a lot of excitement around it and I believe in supporting open source projects (for obvious reasons).
It seems to be pretty nice for novice users. I make a static distribution for WhirlyGlobe-Maply for the same folks and it gets a lot of use.
Disadvantages
WhirlyGlobe-Maply is no longer a lightweight toolkit. It's a massive beast which rivals its commercial competitors and surpasses its open source siblings. [Yes, I'm feeling arrogant today]
Like most good open source developers I use lots of other toolkits where I can. At present, I count 14 of them. At some point I'm going pull in GDAL too. It's as inevitable as death. But with better features!
What I'm saying here is that the distribution has gotten big. Kinda big.
Opinions
I'm interested in your opinions.
- Would you like the podspec updated?
- How do you feel about all the dependent libraries?
- Have you used anything quite this big with Cocoapods?
- Does anyone do binary distribution for dependent libraries?
Any feedback you have on Cocoapods, good and bad is welcome. Just comment in the comments.
Yeah, I'd very much like to have the podspec updated. The dependent libraries are fine, after all that's the whole point of Cocoapods. As for the size, it ought to be a pretty good test :-P
ReplyDeleteHmmm, that's something to ruminate over. Any thoughts on binary libraries.
DeleteBinary libraries are fine for me as well, but it somewhat depends on the purpose. For example if you know for a fact that you're not going to muck around in the code, binary is fine. Stuff like Localytics, Tapstream, that type of component.
DeleteIf you as the author have the feeling that people won't want to change stuff in WhirlyGlobe-Maply, or can easily achieve adding functions by subclassing, then a binary library is fine.