Allow plugins to not support iOS

#10288 added a formal way to allow plugins to indicate which platforms they support, but any plugin that doesn't support iOS (as in, has no ios/ folder) will cause CocoaPods failures. This is because the Podspec uses .flutter-plugins, which isn't platform-specific and thus isn't subject to platform filtering.

When I added initial macOS plugin support I addressed this in a somewhat hacky way. While we could do the same on iOS, we should probably solve this by changing the use of .flutter-plugins instead (and update the macOS Podspec template to match). See also #39657

@jonahwilliams

I like @jonahwilliams's proposal in #39657 (comment)

The longer term solution would be separate .flutter-plugins files for each platform.

@stuartmorgan @jonahwilliams @jmagman for the shorter term, are we okay with landing something similar to the macos hack for iOS as well? I guess if we're not going to fully parse the pubspec similarly to the current workaround we will need to assume a plugin supports ios if it has no *platforms: lines or if it has *ios:, note that FPs are possible, though I think they are unlikely in real world scenarios.

Alternatively we could make it more robust by adding a flutter tool command that actually parses the full pubspec and outputs the supported platforms, though if that isn't something we want to support for the longer term we should probably avoid it.

If we know we want to go to .flutter-plugins-ios, it's not clear to me that we save much effort in the short term by doing the hack. Adding the creation of .flutter-plugins-ios seems like it should be pretty simple.

If we do the hack then later do .flutter-plugins-ios then we have two legacy formats to document or write migration for instead of one, so I suspect it's actually more work.

Just for CocoaPod-consuming platforms, another option (pending plugin migration) would be to create a podspec at the top level of the plugin, to be shared by all platforms:

Example:
https://github.com/flutter/plugins/blob/master/packages/path_provider/ios/path_provider.podspec
and
https://github.com/flutter/plugins/pull/1716/files#diff-92c55de68260e2180bcbca84b620a0e8
would be combined into one podspec at packages/path_provider/path_provider.podspec

Pod::Spec.new do |s|
  s.name             = 'path_provider'
  s.version          = '0.0.1'
  s.summary          = 'A Flutter plugin for getting commonly used locations on the filesystem.'
  s.description      = <<-DESC
A Flutter plugin for getting commonly used locations on the filesystem.
                       DESC
  s.homepage         = 'https://github.com/flutter/plugins/tree/master/packages/path_provider'
  s.license          = { :file => '../LICENSE' }
  s.author           = { 'Flutter Team' => '[email protected]' }

  s.ios.source_files = 'ios/Classes/**/*'
  s.ios.public_header_files = 'ios/Classes/**/*.h'
  s.ios.dependency 'Flutter'
  s.ios.deployment_target = '8.0'

  s.osx.source_files = 'macos/Classes/**/*'
  s.osx.public_header_files = 'macos/Classes/**/*.h'
  s.osx.dependency 'FlutterMacOS'
  s.osx.deployment_target  = '10.12'
end

Then the tool can look for the .flutter-plugins podspec and let it describe the location of the source files.

There's also something to combining the platform Flutter.podspec and FlutterMacOS.podspec for the same reason.

That doesn't seem compatible with plugin federation, where macOS and iOS may not be in the same repo.

(I think it's also mostly orthogonal to this issue, because a plugin without macOS or iOS support shouldn't need a podspec, so we still can't unconditionally look for this combo podspec.)

I was suggesting the hack wouldn't have to exist and no platform paths would have to be hard-coded if the combo podspec did exist (so had some platform-specific code).

I was hoping to avoid any macos or ios hacks at all by letting CocoaPods use the dependency or not based on the platforms it supports, but it doesn't work the way I hoped when only one is supported:

platform :ios

abstract_target 'FlutterTarget' do
  pod 'macos_only_pod', :path => '.flutter-plugins/../macos_only_pod' # top-level podspec only has `s.osx.*` properties pointing to macos/ paths.

  target 'Runner' do
    platform :ios, '8.0'
  end
end

$ pod install
Analyzing dependencies
[!] The dependency `macos_only_pod (from `macos_only_pod.podspec`)` is not used in any concrete target

so... that won't work.

See #39657 (comment) for a WIP implementation of platform-specific .flutter-plugins files, which would make newly created Podspecs only look at iOS/macOS plugins. (No migration in that patch; it's something we'd probably want to consider in a follow-up.)

@franciscojma86

@franciscojma86 Will this also be fixed by #47258?

@jmagman

@jmagman That's an obsolete PR for now. The JSON logic has already landed. The migration part will be discussed here , which might depend on the decisions taken in this proposal

Is there any ETA for supporting this feature? I tried creating a plugin that doesn't support iOS, but I got:

    Fetching external sources
    -> Fetching podspec for `Flutter` from `Flutter`
    -> Fetching podspec for `camerax` from `.symlinks/plugins/camerax/ios`
    [!] No podspec found for `camerax` in `.symlinks/plugins/camerax/ios`

I think the work here is to migrate the Podfile to parse .flutter-plugins-dependencies instead of .flutter-plugins and only include the iOS plugins

flutter/packages/flutter_tools/templates/cocoapods/Podfile-ios-objc

Line 70 in e491544

plugin_pods = parse_KV_file('../.flutter-plugins')

This will be much easier once #45197 is done so we don't need to migrate Podfile's twice (or hopefully ever again) like:

flutter/packages/flutter_tools/lib/src/macos/cocoapods.dart

Lines 36 to 38 in 4ecb1bb

    
           const String outOfDatePodfileConsequence = ''' 
        
             This can cause a mismatched version of Flutter to be embedded in your app, which may result in App Store submission rejection or crashes. 
        
             If you have local Podfile edits you would like to keep, see https://github.com/flutter/flutter/issues/24641 for instructions.''';

☹️

I think the work here is to migrate the Podfile to parse .flutter-plugins-dependencies instead of .flutter-plugins

Alternately, there's now flutter logic for setting up a symlink folder just like that one, which Windows and Linux use. We could have iOS (and macOS) use that instead, and just iterate over the directories that are created by flutter, instead of having to parse the file.

But either way it's a migration.

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

Allow plugins to not support iOS #39659

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	const String outOfDatePodfileConsequence = '''
	This can cause a mismatched version of Flutter to be embedded in your app, which may result in App Store submission rejection or crashes.
	If you have local Podfile edits you would like to keep, see https://github.com/flutter/flutter/issues/24641 for instructions.''';

Allow plugins to not support iOS #39659

Description

Activity

amirh commented on Sep 16, 2019

stuartmorgan-g commented on Sep 16, 2019

jmagman commented on Sep 16, 2019

stuartmorgan-g commented on Sep 16, 2019

jmagman commented on Sep 17, 2019

stuartmorgan-g commented on Sep 17, 2019

jmagman commented on Jan 18, 2020

franciscojma86 commented on Jan 21, 2020

blasten commented on Apr 10, 2020

jmagman commented on May 20, 2020

stuartmorgan-g commented on May 20, 2020

github-actions commented on Aug 20, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions