Let the Podfile be dynamically created

Extracted from #9763

Let the Podfile be managed by the flutter tool at build time rather than as an artifact of flutter create. This lets us version Podfiles created by old invocations of flutter create as well as handle upgrades of hybrid Podfiles that users have altered to include their own pod dependencies. Probably by tagging the file with markers such as

User stuff
User stuff
####################
# Auto-generated v0.2
# Do not edit within the marked lines. They may be replaced or removed automatically
our own generated pod script
# You can edit below this marked line
####################

This way, users also can't run pod install in the iOS folder before using plugins or editing his own Podfile and get a strange error.

With this, we can also pod deintegrate the project if no plugins are left and there are no entries outside our marked generated lines.

I'm not sure if i'm interpreting this correctly but I would think that it is a bad situation to not have control of the podfile as a developer. I can see cases (mentioned as hybrid apps in #9763) where we might absolutely want to build something native that is not a plugin and requires a pod. I don't think it should be tied to plugin development, unless you're implying that hybrid applications may not be possible? You can use platform messaging in the application to communicate from the native code without using a "formal" plugin. Does that count?

While we're on the subject, I think that updating or installing pods should be a manual step. I wouldn't expect the run command to do that for me every time. I'd prefer to have control over that part of the build process.

Hybrid apps are definitely possible now and in the future. This issue is just a small optimization on the Podfile management. Let me elaborate:

Today

Podfiles with our plugin management scripts are created during flutter create with no other CocoaPods artifacts. Podfile goes into source control at this point.
Running pod install manually on a fresh project is possible (after setting some environment variables). Though it creates a whole bunch of hookups in the iOS project that don't do anything
Once user starts using plugins in pubspec, flutter build/run will automatically run pod install
Without using plugins, users can insert custom pod instructions in the existing Podfile between the target 'Runner' do lines, then manually invoke pod install. flutter build/run won't invoke pod install since there are no plugins.
Users can have manual entries in the Podfile and also use plugins in pubspec. flutter build/run runs pod install. pod install can also be run manually.

My proposal

Don't create any Podfiles during flutter create
Manual pod install on a fresh project not possible (since there's nothing to install)
When user uses plugins for the first time without a user custom Podfile, flutter tools will create a Podfile with today's plugin scripts in a versioned, annotated section of the Podfile. Podfile goes into source control at this point. Running flutter build/run automatically runs pod install
Users can create a Podfile and run pod install without using plugins. Without plugins, flutter tools would be entirely agnostic about CocoaPods
If the user adds manual entries in the Podfile outside the generated, annotated section after using plugins or starts using plugins, after having inserted custom entries in the Podfile, flutter tools will manage the annotated section only. In this hybrid case, flutter tools knows if there are user entries and lets the user run pod install manually only.

Implications

If we update the plugin script in the future, we can still update it in user projects' hybrid Podfiles and do in-place swaps automatically since the generated portion is annotated.
If the user starts or stops using plugins, we can cleanly add or remove the plugins script around the user's custom pod instructions
flutter tools can know if it's operating in [no cocoapods mode, user custom pod mode, flutter plugins mode, or hybrid mode] and have different behaviours (such as whether to run pod install automatically or not. Today, we only know about [flutter plugins mode, no flutter plugins mode].
Start projects clean with no CocoaPods anywhere. Though as Eric pointed out, this is probably not important.

I think your desired behaviours are already achievable today if I understand correctly. This is just for setting us up to cleanly handle some edge cases that might arise in the future with projects that are flutter created today.

@xster

@xster I'm seeing the issue from #9763 with a team member . The solution for was for him to send me his Pod directory, which I copied into my iOS folder.

Is there a better way for us to handle this with future team members?

I assume you guys aren't actually using custom CocoaPods or plugins currently in your project right?

If so,

Future flutter created projects won't have this problem
For you current projects, you can just remove all CocoaPods related things in the ios folder except Podfile (until this issues is resolved). That is, the Podfile.lock, the Pods folder, everything that mentions 'pod' in Runner.xcodeproj/project.pbxproj. When you start using plugins again, everything will safely regenerate.

Let me know if that's what you were facing. Feel free to assign issues directly to me in GitHub if you encounter any other issues.

I believe that's all we'll need, thanks for getting back to me! This current solution is manageable.

@szakarias

@szakarias @jakobr-google would this solution resolve the issue you were mentioning?

Hopefully, if done right. The problem we're having right now is that manually running pod install doesn't work, because the project has custom configuration that doesn't include the .xcconfig files generated by CocoaPods. We specifically only include those if the project uses plugins.

Removing the pods .xcconfigs when there are no plugins is what's biting us when removing the last plugin from a project -- the project is still CocoaPods enabled, but we're now not including the pods .xcconfig, so it won't build.

If the proposed solution here takes care of wiring up the pods .xcconfig correctly when necessary (ie. either when using plugins or other pods, or just always if they exist!), we should be good.

Concretely to see the issue:

flutter create my_app

Edit Podfile by adding a pod, for instance

  # Pods for Runner
  pod 'MaterialControls'

Run pod install by running

FLUTTER_FRAMEWORK_DIR=<path to flutter>/bin/cache/artifacts/engine/ios pod install

Now flutter run fails with this message

    diff: /Podfile.lock: No such file or directory
    diff: /Manifest.lock: No such file or directory
    error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.
    
Could not build the application for the simulator.

#9827 (comment) is indeed an issue.

I think if we were generating and managing the contents of the Podfile (such that we can compare the actual contents vs our template), we'd edit https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/ios/mac.dart#L162
such that _runPodInstall still gates on hasFlutterPlugin but updateXcodeGeneratedProperties(hasPlugins would be renamed attachPodXcconfig and would gate on _isFlutterPluginUnmodifiedPodfile(podfile) instead of hasFlutterPlugin.

To summarise, we should have the following use cases:

A. Flutter app contains no pods or plugins
B. Flutter app contains one or more plugins, but no pods
C. Flutter app contains no plugins, but one or more pods (e.g., a hybrid app using an iOS widget distributed on cocoapods)
D. Flutter app has one or more plugins as well as one or more pods

In case A the developer should not need Cocoapads installed, and no pod file should be present. I believe this has already been completed.

In case B, Cocoapods is required, but the developer should not need to edit the Podfile. We call pod install as part of build. I believe this has already been completed.

In case C, Cocoapods is required, and the developer owns creating and maintaining the Podfile, but we should call pod install as part of build. This is not working currently.

In case D, Cocoapods is required, and the developer still owns creating and maintaining the Podfile; practically likely by copying our Podfile template, and adding their own content under # Pods for Runner? We call pod install as part of build.

@xster

@xster I have lost track a bit, can you comment on where are are wrt. supporting use cases A, B, C, and D that I listed in #9827 (comment) ?

Since this doesn't seem like a new user blocker, moving to next milestone.

@xster

@xster I don't think we can move away from letting users edit their Podfile. I'd like to close this in favor of #45197.

Let me know if you think there's more to track here.

@jmagman

@jmagman I think the only thing left from this meta bug is pod deintegrateing after removing the last plugin

I don't think we can do that, people add their own Pods, we don't really own that file (seen a lot of bug related to OneSignal, for example)... It would be great if we had the flutter migrate feature to sha the files and know if they have been edited from the template.

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Let the Podfile be dynamically created #9827

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Let the Podfile be dynamically created #9827

Description

Activity

lukef commented on May 6, 2017

xster commented on May 7, 2017

KevinTheGray commented on May 8, 2017

xster commented on May 8, 2017

KevinTheGray commented on May 8, 2017

mit-mit commented on May 24, 2017

jakobr-google commented on May 24, 2017

szakarias commented on May 24, 2017

xster commented on May 24, 2017

mit-mit commented on May 29, 2017

10 remaining items

mit-mit commented on Sep 13, 2017

Hixie commented on Dec 18, 2017

jmagman commented on Jan 17, 2020

xster commented on Mar 10, 2020

jmagman commented on Mar 10, 2020

lock commented on Apr 5, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions