Expand Podspec DSL to include whether the Pod uses private APIs #1871

Closed
jeremytregunna opened this Issue Mar 9, 2014 · 16 comments

Projects

None yet

8 participants

@jeremytregunna

There are a lot of really good tools out there that can be used for testing and development which make use of private APIs. It would be very nice to be able to specify in a pod spec that the library makes use of such APIs, and as such should not be included in libPods.a for release builds.

@fabiopelosin
Member

This will be supported by #1668

@mtitolo
Member
mtitolo commented Mar 10, 2014

@irrationalfab this is different than the build configuration stuff, but would compliment it. This is a flag saying whether or not a private API is used in the library, so the creator/maintainer can be explicit about whether or not something would pass appstore review.

@fabiopelosin
Member

Oh, nice!

@fabiopelosin fabiopelosin reopened this Mar 11, 2014
@orta
Member
orta commented Mar 11, 2014

updated title to reflect this

@neonichu
Member

What would the semantics of such a flag be? There are Pods which will give problems with App Review even without explicit use of private API, like JagCesar/iOS-blur#25. On the other hand, it is easy to obfuscate the use of it, like https://github.com/neonichu/BBUDeviceColors does.

IMHO, it would make more sense to have a flag for Pods which are explicitly tailored for development use only and should never be part of a release build, like Reveal.

@CocoaPodsBot

Issue has been confirmed by @neonichu

@orta
Member
orta commented Mar 29, 2014

IMHO, it would make more sense to have a flag for Pods which are explicitly tailored for development use only and should never be part of a release build, like Reveal.

^ good call.

@kylef
Contributor
kylef commented Mar 30, 2014

Reminds me of BugshotKit.

To help prevent accidentally shipping your app with BugshotKit, I've included a helpful private API call that should cause immediate validation failure upon submitting. If you somehow ship it anyway, it will attempt to detect App Store builds at runtime and disable itself.

@fabiopelosin fabiopelosin self-assigned this Mar 31, 2014
@segiddins
Member

something like spec.development_ony = true?

@fabiopelosin
Member

@segiddins 👍

@segiddins
Member

@irrationalfab I started on that here, but I'm not sure exactly what needs to be done

@fabiopelosin
Member
  1. Configure the attribute like this: deprecated
  2. Specs
  3. I think that once we refactor the Podfile DSL we could add a warning if the Pod is installed in release based build configurations. The attributed could also be displayed in the upcoming CocoaPods search.
@segiddins
Member

Now that I think about it, I think such a flag would just be adding clutter to the Podspec.

@fabiopelosin
Member

I'm on the fence about this one.

@orta
Member
orta commented Sep 16, 2014

I'm on the no camp. Think config based pods cover this well enough.

@fabiopelosin
Member

Closing because it appears that the team doesn't favour this kind of solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment