@pcsosinski fyi

Won't this prevent Flutter app developers on current stable from using these plugins? Is there any harm to leaving this dummy directory until the majority of Flutter users have upgraded past #59209?
Add-to-app still hasn't been migrated #61269

I don't see any technical harm other than people might get confused with the no-op iOS folders. What do you think of pushing this change (along with the new flutter create plugin command to the next stable? @csells

@cyanglaz Could you give a little more color on the response to @jmagman's questions? I'm also curious about what the impact will be particularly around the question of users of the current stable. Has anyone tried this specific case? Will there be tool crashes?

the reason for this change is that this release marks the first time we've updated the client-side pub tool to disable the use of the old pubspec.yaml. the new pubspec format requires a pluging to be explicit about what platforms it supports. we can hardly ask them to do that and then require them to leave in an empty ios folder, too, regardless of whether they're targeting ios.

We can't break add2app

@csells That makes sense. My concern is more around the stability/crashiness of the tool around this change. We might not have good test coverage in this area, so some manual testing might be needed for the scenario that @jmagman is worried about. Just want to get confirmation that that scenario has been tried, and the tool does not have any unexpected behavior.

@zanderso

For a pure flutter apps, the current stable (1.17) user will not be able to build the app if it depends on the plugin at all, because the plugin has a min flutter sdk requirement of 1.20.0.

They will see an error when they depend on a plugin created using the 1.20.0 command like:

The current Flutter SDK version is 1.17.5.                              
                                                                        
Because <app_name> depends on <plugin_name> which requires Flutter SDK version >=1.20.0 <2.0.0, version solving failed.

Note that this PR only adds the constraint to the newly created plugins.

For example, an existing web only plugin author wants to remove the no-op ios folder, they can do that by manually removing the folder and set the min sdk version to 1.20.0, which also blocks their plugin to be used by people who are on 1.17

I'm not sure about the Add to app cases that @jmagman mentioned

Add-to-app at least isn't fixed in 1.20. It's parsing the old .flutter-plugins and expects an ios directory:
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/module/ios/library/Flutter.tmpl/podhelper.rb.tmpl#L70
I don't think this would surface as a tool crash since it looks like pod install failing.
Note the empty directory may be confusing to users, but isn't related to requiring the new pubspec format for pub publishing.

lgtm after #61269 lands.

#61269 has landed.

thanks all - @cyanglaz or @jmagman can you clarify a couple things:

• which commit(s) do we need on the 1.20 branch
• can this land on the next beta build or does it need to land right before the 1.20.0 stable release?

@pcsosinski

which commit(s) do we need on the 1.20 branch

The commit needed on the 1.20 branch is #62372. That includes #61269 (with merge conflicts resolved) and this PR, #61561.

can this land on the next beta build or does it need to land right before the 1.20.0 stable release?

I think it needs to be included in the 1.20.0 stable. If a plugin says its minimum is 1.20 (the new default) and is missing the ios directory, an add-to-app iOS module on 1.20 will not be able to use that plugin even though it meets the flutter version requirements.