490

I use quite a lot third party libraries which have many warnings in it, after the latest Xcode updates. (for example the Facebook SDK pod) Now all these warnings are shown in my Xcode on the place I want to see my own warnings or errors.

Is there any way to ignore these errors? Fixing them won't help, since after every "pod install" the changes are discarded.

4 Answers 4

1102

Add to your Podfile:

platform :ios

# ignore all warnings from all pods
inhibit_all_warnings!

# ignore warnings from a specific pod
pod 'FBSDKCoreKit', :inhibit_warnings => true

Then execute: pod install

13
  • 3
    How do I include that? Currently I use s.dependency 'Facebook-iOS-SDK' s.inhibit_all_warnings! and I get the following error: undefined method `inhibit_all_warnings!' for #<Pod::Specification for MyApp(1.0)>
    – KrauseFx
    Nov 3, 2012 at 21:27
  • 26
    How can I solve the following problem: I want the warnings to be hidden for some pods, but not for all of them.
    – KrauseFx
    Nov 5, 2012 at 10:26
  • 6
    @krausefx Sorry, didn’t see your comment. For posterity sake, you can now disable warnings on a per-pod basis, as shown in the Podfile docs: docs.cocoapods.org/podfile.html#inhibit_all_warnings_bang
    – alloy
    Jul 10, 2013 at 18:06
  • 2
    @JohanKarlsson Remove the directive and run pod install to regenerate the Pods.xcodeproj.
    – alloy
    Mar 17, 2014 at 15:49
  • 1
    Note that this doesn't preclude warnings (issues) from appearing during the Analyze phase. I've offered some suggestions for that in a different answer.
    – Jedidja
    May 15, 2015 at 13:37
40

You can search for "inhibit_all_warnings" in your Xcode build settings of the PodBundle in your project-workspace. Set the value to "YES" and it will hide all your Pod file warnings.

If you do it to your workspace it will hide all your project warnings also.

5
  • 1
    This is a simpler solution, set this on the pods project and it only disables pod related warnings, not your project warnings. No need to re execute the pod install. Oct 24, 2014 at 18:28
  • 36
    Not recommended! With the next pod install this setting is overridden, so better set it in Podfile! Jan 12, 2015 at 12:31
  • 4
    Personally I do like this so that every update I remember to take a quick look that all warnings and make sure they are neglectable. Apr 28, 2015 at 21:24
  • what about for dependencies in a podspec for a local dev pod? Sep 1, 2015 at 23:46
  • 2
    You may also set Swift Compiler - Warnings Policies > Suppress Warnings to Yes... with the inhibit_all_warnings I still had the 'characters' is deprecated: Please use String or Substring directly warning in Pods. This setting removed this warning.
    – Tiois
    Dec 15, 2017 at 15:05
21

Step: 1 Put the below script in your Podfile.

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['GCC_WARN_INHIBIT_ALL_WARNINGS'] = "YES"
        end
    end
end

Step 2. Do pod install.

1
  • 7
    I also had to add the following for Swift Pods: config.build_settings['SWIFT_SUPPRESS_WARNINGS'] = "YES"
    – pstoppani
    Sep 19, 2019 at 23:40
8

Although this other answer will remove warnings during the build phase, it doesn't appear to completely fix the Analyze phase (which caused our CI build to still have issues).

What worked for me (in addition to the accepted answer) was:

  • Click on the Pods project from the Project Navigator

  • Choose the actual Pod- Target and click on Build Settings

  • Filter with the phrase compiler flags

  • Add a new Other C Flags with the value -w -Xanalyzer -analyzer-disable-checker -Xanalyzer core (or whichever analyzers you need disabled) - this answer provides the full list of flags to try -- please upvote it!

    The version of clang in Xcode 6.3.1, though, doesn't seem to include insecureAPI so you can remove it from that list. The "current" full list is -w -Xanalyzer -analyzer-disable-checker -Xanalyzer alpha -Xanalyzer -analyzer-disable-checker -Xanalyzer core -Xanalyzer -analyzer-disable-checker -Xanalyzer cplusplus -Xanalyzer -analyzer-disable-checker -Xanalyzer deadcode -Xanalyzer -analyzer-disable-checker -Xanalyzer debug -Xanalyzer -analyzer-disable-checker -Xanalyzer llvm -Xanalyzer -analyzer-disable-checker -Xanalyzer osx -Xanalyzer -analyzer-disable-checker -Xanalyzer security -Xanalyzer -analyzer-disable-checker -Xanalyzer unix

Note that setting this on the Pods Project or Pods Target will not work. I'm not sure why, but you have to set it for each actual Pod- target.

You can also set the compiler flags (-w -Xanalyzer -analyzer-disable-checker -Xanalyzer core etc.) on a per-file basis.

I also tried a couple other methods (which may or may not be required in addition to the above). They were performed on the Pods Project itself.


[1]

  • Filter with the phrase analyzer
  • Make sure Analyze During 'Build' is set to NO.
  • Change all the settings to NO (including Improper Memory Management)

[2]

  • Filter with the phrase warnings
  • Change inhibit all warnings to YES

For some reason, even disabling the Analyze step in the scheme doesn't seem to work.

Go to the Product > Scheme > Manage Schemes window, click on each Pod-* from the list and click the Edit button. Click Build on the left-hand list, and then uncheck Analyze on the right-hand side for the Pod target.

I am still confused as to why I can't completely disable the Pods from being analyzed, although I expect it might have to do with the "Find implicit dependencies" checked in the scheme's build settings. If that was unchecked, though, it looks like something else would need to happen for the app to link to the pods.

5
  • 1
    Note: Unfortunately, this doesn't help with CI if you exclude Pods and .xcworkspace from your repository - using your .gitignore.
    – RileyE
    May 14, 2015 at 20:51
  • @RileyE interesting - is there a good reason to exclude those from a repo? If so, does the other technique on this page work for you? (I'm still a relative newbie to iOS development so quite curious to learn more)
    – Jedidja
    May 15, 2015 at 12:14
  • There is a large divide on whether to include it or not. I don't like including it as I prefer to make sure my podfile is always accurate and I've found some conflicts between different user's Podfile.lock and .xcworkspaces. It's simply a preference to users with strongly debatable pros and cons.
    – RileyE
    May 15, 2015 at 20:29
  • @RileyE thanks for the information! So if we did exclude Pods/.xcworkspace there is no workaround for the issues problem?
    – Jedidja
    May 16, 2015 at 12:41
  • Unfortunately not. Which is why I've been pushing for additional flags on pod install.
    – RileyE
    May 18, 2015 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.