Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop the Cocoapods dependency #526

Closed
thefaj opened this issue May 25, 2016 · 7 comments
Closed

Drop the Cocoapods dependency #526

thefaj opened this issue May 25, 2016 · 7 comments

Comments

@thefaj
Copy link

thefaj commented May 25, 2016

Please make Segment distributable as a framework without the Cocoapods dependency. I downloaded the latest from this repo, fixed the project so it would build for x86_64 as well as the arm architectures, and built the framework to include into my app once.

If you distribute a framework from segment.com…I'll more likely keep up to date with your release schedule. The way it currently is, I will not be updating the client libraries that frequently.

Mobile developers don't use Cocoapods in their projects.

@kleemedia
Copy link

I totally agree with this. I also had to fork the repo and add an aggregate target that builds a framework with both simulator and device libraries included.
Support for Carthage would be preferred.

@thefaj
Copy link
Author

thefaj commented May 25, 2016

Carthage is fine, but the real issue is requiring any sort of third party dependency. Cocoapods and Carthage (and whatever package manager comes next) are passing trends. Developers who want Ruby gems on iOS are forcing a square peg into a round hole.

@thefaj
Copy link
Author

thefaj commented May 27, 2016

Could we get some feedback from Segment employees on this issue, please?? I sent a support request, and they referred me to add an issue on Github. This isn't a traditional open source project where the community is going to fix this with a Pull Request—Segment is a VC funded corporation with $44.6 million in investments. Please fix this ASAP.

@sperand-io
Copy link
Contributor

@thefaj thanks for your input!

For context, we found that offering installation via cocoapods drastically increased our iOS activation rate and lowered the number of support tickets and frustrated customers for the install phase of the product (we used to build the framework and include it in the releases, but the 7 step instructions for including the SDK manually confused a lot of our customers). I imagine it's for similar reasons that Salesforce, AWS, and Google Analytics all recommend CocoaPods to install their SDKs.

When we made some fundamental changes to the structure of the SDK to allow partners to add themselves to the platform much more easily, we took a look at the installation methods and decided to only "officially support" cocoapods given the data we had about how people had been successfully installing the SDK. That said, we definitely want the core SDK to be easily installable without cocoapods (either via carthage or manually as a framework for those who don't want to use either), and to that end, your request is noted! We have a variety of initiatives in flight for improvements to both the mobile SDKs, and we'll keep you posted in this issue with any updates around documentation and release eng augmentations that make installing the SDK via a framework more straightforward.

Hope that helps!

@f2prateek
Copy link
Contributor

Closing and tracking both separately in #531 and #530

@thefaj
Copy link
Author

thefaj commented Jun 4, 2016

Hi Chris,

Thanks for your response. I’m sorry it took so long for me to reply back—I had an app release that we added Segment to at the last moment.
Salesforce, AWS, and Google Analytics are not exactly the best iOS citizens to cite as examples for reasons to support Cocoapods. And Carthage is the same idea as Cocoapods with a different name.

Thank you for the link on how to include the SDK without Cocoapods. Where is that listed on segment.com? I don’t even see it on the list of public Wiki pages on Github. Also, the download link is broken.

There’s no reason I should be compiling your code from source. And there’s absolutely no reason I should require developers to install a command line tool just to build my app. Cocoapods comes from Rails backend developers that are not very good iOS developers.

Now that I’ve seen your SDK’s source, it’s disturbing that you’re using NSURLConnection. NSURLSession was introduced as its replacement in iOS 7. This should be a critical issue for your team to fix.

I understand you’re trying to do a job. As an iOS developer I already have distrust towards companies like Segment that spy on my app’s users by collecting, aggregating, and selling their data. I was asked to include your framework by a business owner, so I expect you to make developer integration as easy as possible.

I hope you understand.
-Alex Fajkowski

On May 27, 2016, at 4:12 PM, Chris Sperandio [email protected] wrote:

@thefaj https://github.com/thefaj thanks for your input!

For context, we found that offering installation via cocoapods drastically increased our iOS activation rate and lowered the number of support tickets and frustrated customers for the install phase of the product (we used to build the framework and include it in the releases, but the 7 step instructions https://github.com/segmentio/analytics-ios/wiki/Installing-Manually/f2f1cd818478f8e751b316313db923dceb79b545 for including the SDK manually confused a lot of our customers). I imagine it's for similar reasons that Salesforce https://developer.salesforce.com/blogs/engineering/2015/02/cocoapods-support-comes-mobile-sdk.html, AWS http://docs.aws.amazon.com/mobile/sdkforios/developerguide/install-ios-sdk.html, and Google Analytics https://developers.google.com/analytics/devguides/collection/ios/v3/ all recommend CocoaPods to install their SDKs.

When we made some fundamental changes to the structure of the SDK to allow partners to add themselves to the platform much more easily, we took a look at the installation methods and decided to only "officially support" cocoapods given the data we had about how people had been successfully installing the SDK. That said, we definitely want the core SDK to be easily installable without cocoapods (either via carthage or manually as a framework for those who don't want to use either), and to that end, your request is noted! We have a variety of initiatives in flight for improvements to both the mobile SDKs, and we'll keep you posted in this issue with any updates around documentation and release eng augmentations that make installing the SDK via a framework more straightforward.

Hope that helps!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #526 (comment), or mute the thread https://github.com/notifications/unsubscribe/AADsTVWH2XiMpeYlG0v6cPxIE-5f-nNoks5qF3pegaJpZM4Im1WE.

@sperand-io
Copy link
Contributor

Hey Alex,

Again, really appreciate your thoughtful input.

There’s no reason I should be compiling your code from source. And there’s absolutely no reason I should require developers to install a command line tool just to build my app

Agreed. We removed the documentation for how to install the built framework when we removed the auto-building from our release process. The thinking at the time (albeit admittedly shortsighted/flawed) was that cocoapods was empirically the most successful install path, so it was the only one we would fully support.

NSURLSession was introduced as [NSURLConnection's] replacement in iOS 7.

@tonyxiao marked this as a forthcoming improvement independently; I expect we'll have a plan for releasing support shortly.

Making integration as easy as possible for developers is the #1 goal of our libraries and integrations teams. Going forward, we will be working even harder than ever to do just that.

Thanks again for your feedback. We do appreciate it!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants