[Linter] Disallow the use of the vendored_frameworks for iOS specs

[fabiopelosin]

originally reported by @alloy in #44

Disallow the use of the vendored_frameworks for iOS specs. These are not frameworks, but instead are static libraries disguised as frameworks and this makes it harder to use these specs outside of the context of Xcode. E.g. with clang from the command-line. Ideally this would also check the xcconfig attribute to ensure it’s not adding any FRAMEWORKS_SEARCH_PATHS.

[neonichu]

When you use https://github.com/jverkoey/iOS-Framework, that will work pretty much like "real" frameworks.

cc @alloy

[fabiopelosin]

Marked as discussion.

[fabiopelosin]

I'm of the opinion that this is not a decision that CocoaPods should be taking on behalf of the users.

For context @orta's and my #44 (comment) reactions.

[alloy]

As I see it, it’s not a matter of opinion. They are not frameworks and only Xcode.app (the UI) accepts this. If you try to use the framework related options with clang it will laugh at you ;) So, we should disallow them, instead they should use vendored_library.

(At least this used to be the case, it’s worthwhile to verify it’s still the case.)

[alloy]

An alternative is that we handle vendored_frameworks on iOS as vendored_libraries, although this would only permeate the ‘problem’ of people thinking that fake frameworks are ‘just as good’.

[neonichu]

@alloy Did not know that, I will verify if that is still the case and report back.

If it is, then this should indeed be changed.

[alloy]

@neonichu That would be awesome, thanks. This problem comes up, for instance, with RubyMotion where we use normal clang linker options to build an app. Very frustrating :)

[neonichu]

@alloy This seems to work fine:

clang -ObjC -arch armv7 -include Test-Prefix.pch -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -framework Foundation -framework UIKit -F. -framework ContentfulDeliveryAPI -o Test XXAppDelegate.o main.o

using https://github.com/contentful/contentful.objc/tree/master/Examples/UFO/Distribution/ContentfulDeliveryAPI.framework

Which was build using the approach linked above. I think this is different from the "fake framework" approach you are talking about.

[alloy]

@neonichu Interesting! I will lookup a specific case with RubyMotion and verify if that’s still the case or not.

[neonichu]

@alloy You should take a look at https://github.com/jverkoey/iOS-Framework, he is describing different approaches for generating iOS frameworks there.

[neonichu]

Just for reference, using the framework from https://github.com/CocoaPods/Specs/blob/master/Parse-iOS-SDK/1.2.18/Parse-iOS-SDK.podspec for example will lead to lots of build errors, so I guess depending on the approach one uses to build the framework, the results will differ wildly.

[alloy]

@neonichu I was definitely able to build with the Google Maps SDK, which used to cause problems.

Can you paste the errors you are seeing with Parse? (I know it’s a bit problematic in that it requires the Facebook SDK when you use the -ObjC flag.)

[neonichu]

@alloy Yeah, that was actually the problem. It builds just fine when the FB SDK is available or when I take out -ObjC.

[fabiopelosin]

So should we close this issue?

[alloy]

@neonichu Gotcha. Thanks for the feedback!

@irrationalfab Aye, let’s let user keep on making fake frameworks :)

[fabiopelosin]

lol