Suppress Xcode warnings originating from Flutter plugins as pods in Flutter apps

[jmagman]

Use case

Flutter plugins often contain code that causes Xcode warnings. These warnings show up in Flutter apps, but are not fixable by Flutter app developers. The sheer number of these warnings can hide actually fixable warnings.

Proposal

• Suppress warnings from Flutter plugins and Flutter engine in apps when installed from CoocaPods
• Do not suppress warnings in plugin example apps so plugin developers can see and fix their own warnings

Note

Modules already have this behavior as of https://github.com/flutter/flutter/commit/bd47a31e32d7c65ef35524f3bf18655e513e3a5b#diff-b528f954e369c153bb31a631a8033be3R37 so host apps do not see Flutter pod warnings.

See https://github.com/flutter/flutter/issues/30110 for example of an issue where plugin warnings completely drown any actual errors.

[juliocbcotta]

Fixing the warnings is not an option? Hidding the problems can be even more troublesome, as it will not show actual hints of what can be wrong.

[jmagman]

The plugin authors are the only ones who can fix warnings originating in plugins.

On the one hand, every plugin consumer getting the warnings might mean increased visibility so plugin authors get pull requests or at least badgered to fix them. And clang and Xcode like adding new warning defaults, so the users may see new warnings before plugin authors.

On the other hand, it's a rough deal as an app developer to drown in warnings you can't suppress. It's too easy to not notice 100 warnings go to 101 when that 1 was actually a real issue fixable by the app developer because it was in their code.

Personally, I'm on the side of a zero-warning environment to make new fixable warnings obvious and detectable.

Also, my proposal would change the flutter create template, not the flutter create -t plugin template, so fastidious Flutter plugin authors would still see the plugin warnings in their own example app. And app developers who don't like this behavior like it can edit their Podfile and it shouldn't get overwritten.

@collinjackson What do you think?

[juliocbcotta]

I took a look at the issue. How about to ignore the warnings only in the offending plugin? It looks like Firebase Firestore is the one that could make the warnings silent. This would not affect other possible valid warnings.

[jmagman]

1. At the point plugin authors know they have warnings, they should fix them, not mark themselves as "I have warnings". I wouldn't want to enable a feature like that.
2. First-party plugins should not produce warnings. A lot of it has been cleaned up, but not all of it.
3. A pre-submit CI test would prevent new warnings at the time the first-party plugin code is written, but would not prevent warnings from new clang/Swift versions, etc.
4. It would be awesome if warnings impacted package pub scores. That would surface warnings to plugin authors without relying on users noticing and creating issues.
5. We could document how to edit the Podfile to :inhibit_warnings => true for all or some filtered set of plugins, but leave it off by default. https://github.com/flutter/flutter/blob/626ca086d0245143d35ecebb2bc544ec7db45748/packages/flutter_tools/templates/cocoapods/Podfile-ios-objc#L59

[jmagman]

I don't think the plugins team wants this. Closing.

[ollyde]

@jmagman would have been a nice flag though. like flutter build ios --no-warnings cause right now I'm trying to debug a build server crash and the Flutter warnings are a nightmare.

[jmagman]

@ollydixon I agree with you 😄

Personally, I'm on the side of a zero-warning environment to make new fixable warnings obvious and detectable.

I'm going to re-open this, it's still a legit feature request.

[rayyan808]

Would also love to see this. It's very chaotic right now

[jamesncl]

I also would like this. I use several plugins, and if a build for ios fails, the terminal is filled with hundreds and hundreds of lines of warnings about issues that I have no control over. Also with no colouring, it is extremely hard to read. At the moment I actually copy all the text into a text editor so that I can search it for the one error that has actually caused the build to fail, which is very annoying!

[exaby73]

@jmagman Hello! I was just wondering if this request is this relevant today?

[ristiisa]

@exaby73 why would it not be?

[exaby73]

@ristiisa This is part of the triage process to verify issues, so that we can label them better and track their progress. Yes, to me and you, this issue is relevant but it's only fair to ask OP of the same. Hope that clears the misunderstanding :)

[jmagman]

It's still a valid request.

[jeanmatthieud]

I'm regularly hitting CI log size limits with all the XCode warnings (from plugins that I don't manage), and I'm missing the build error...