I'll carry this PR forward asap.

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

CLA signed.

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of all the commit author(s), set the cla label to yes (if enabled on your project), and then merge this pull request when appropriate.

FYI @matthew-carroll

Added support for materializing Flutter module projects on iOS. Currently, the materialized host app is in Objective-C only and uses CocoaPods, even if there are no plugins. Plan:

• expand the module_test_ios device lab test to prove that we can add to an existing iOS host app
• support materializing Swift and Kotlin host apps
• decide whether we want to avoid the use of CocoaPods in the materialized iOS host app, and if so, how to help the user add Flutter plugins to that app later on (I'll need the Flutter team's input here)

CC @dnfield Can you start with this thread when you begin with the iOS module project work?

PS @dnfield, to clarify one of @mravn's questions above, we definitely need to avoid CocoaPods in the initial project structure before plugins are added.

@dnfield @matthew-carroll This PR avoids the use of CocoaPods in the ephemeral host app. Not sure if that is what you meant by "initial project structure"?

Avoiding CocoaPods also when materializing an iOS host app comes with a usability cost: If you happen to materialize your iOS host app before adding Flutter plugins (and CocoaPods to support them), then we are not in a good position to automatically fix it later, if/when you realize that your app does need plugins.

The materialized host app is controlled by the app author and could be (almost) arbitrarily modified beyond the control and aid of Flutter tooling. So adding the plugin+CocoaPods setup later would in general be a manual step.

Options, as I see them:

• Accept that a materialized host app always involves CocoaPods, then work to push the threshold at which materialization is needed for simple, all-Flutter apps (e.g. by supporting more iOS-specific configuration in the pubspec.yaml file).
• Don't accept that a materialized host app without plugins involves CocoaPods, then work towards making the manual steps needed to add plugins and CocoaPods later as simple as possible (e.g. by making the project setups identical, as far as possible, but for the need to invoke pod install).

@mravn You're right, I totally spoke too soon. I was thinking of the ephemeral project.

@dnfield when we make a host app editable (AKA materialize), we actually want to automatically add CocoaPods because we won't get another opportunity to do so.

@mravn it looks like this code is checking for whether it should be using .ios or ios, which is good.

Am I missing something here where the .ios folder would actually get created, or is that still to be done?

@dnfield The ios/ and .ios/ folders are created as part of template instantiation, see https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/module/README.md

Oops. I need to update that README with the template for the materialized host app.

@dnfield I intend to finalize this PR this week, by adding an add2app test section to the module_test_ios devicelab test. If you prefer, we can postpone that to a subsequent PR and land this one as is (after a review). The support of materializing host apps in Swift and Kotlin can also be done in subsequent PRs.

Let me know if landing this PR interferes with your plans in any way. If it does, feel free to extract anything useful from it and then close it.

That sounds good, I have a couple other areas around this I'm working through as well. If it's not looking good to you for this week please let me know so I can reprioritize - and thanks!

@mravn we're going to rename "materialize" to "make-host-app-editable" - should we wait until after this PR lands to do that? Would that save us some conflicts? Or should I take care of that ASAP?

I don't think it matters that much to my PR. I'll just rebase and sort it out. But don't rush the change for my sake.

@mravn is this ready for review?

We'd like to get the functionality for this landed ASAP to unblock another effort on the ios/android materialization workflow.

@dnfield Sorry, I've been busy. The PR is close to ready. I'm having trouble getting code signing/provisioning to work on the ios_host_app used by the module_test_ios devicelab test I've added. I may need some help with that. Otherwise we can remove that part of module_test_ios for now.

I cannot edit the title of this PR to remove the WIP prefix, nor can I remove the cla:no label.

The PR was created by my Google alter ego.

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

Overriding CLA status because it's due to confusion over a closed/unlinked account.

@mravn can you go ahead and just disable the offending test for now, we can land this, and someone can pick up the test where you left off with it? That should unblock @matthew-carroll

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of all the commit author(s), set the cla label to yes (if enabled on your project), and then merge this pull request when appropriate.

Done. The cla:no label came back though.

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

This LGTM, but can you confirm this is ready (modulo the desire for eventually fixing that test)?

I'll test the functionality to be covered by the missing test tonight, manually. I'll keep you posted.

With Flutter module project, ephemeral/non-editable iOS host app:

• flutter run works for Simulator
• flutter run works for device
• flutter run works for Simulator, with plugin
• flutter run works for device, with plugin

With Flutter module project, editable iOS host app:

• flutter run works for Simulator
• flutter run works for device
• flutter run works for Simulator, with plugin
• flutter run works for device, with plugin

Whoa! Wasn't done checking the add2app case, and found a problem. See #22277.