- Makes build_macos.dart handle the case where there is only one Xcode
project in the macos/ directory, but it's not called Runner.xcodeproj
- Makes getInfo throw a tool exit when trying to get project info and it
can't find a project, since that is a configuration error by the user
rather than a tool bug.
Fix some places where Debug/Release was treated as a binary switch.
Makes similar changes to Windows and Linux to simplify adding profile
support to those platforms in the future. This means `--profile` builds
will fail on Linux and Windows for now, but that's fine since they
aren't actually supported, and unlike `--release` don't provide useful
functionality at the native code level.
Also fixes 'stopApp' always using Debug on macOS, to avoid showing an
error when running Profile (or Release).
Fixes#33203
We were using the `defaults` command-line utility to parse
Plist files, but it was never supported by Apple, and it
appears that in an upcoming OS release, it will be less likely
to work:
> WARNING: The defaults command will be changed in an upcoming
> major release to only operate on preferences domains. General
> plist manipulation utilities will be folded into a different
> command-line program.
Fixes https://github.com/flutter/flutter/issues/37701
This updates the flutter tool cache to download binary files for ideviceinstaller, ios-deploy, libimobiledevice, and dynamically linked dependencies from Flutter's GCP bucket.
Updates the Podfile template to use the CocoaPod disable_input_output_paths installation option which prevents the [CP] Embed Pods Frameworks build phase from outputting the Flutter.framework files.
Updates the Podfile template to use the CocoaPod disable_input_output_paths installation option which prevents the [CP] Embed Pods Frameworks build phase from outputting the Flutter.framework files.
Updates the Podfile template to use the CocoaPod disable_input_output_paths installation option which prevents the [CP] Embed Pods Frameworks build phase from outputting the Flutter.framework files.
Enables the CocoaPods-based plugin workflow for macOS. This allows a
macOS project to automatically fetch and add native plugin
implementations via CocoaPods for anything in pubspec.yaml, as is done
on iOS.
Splits Xcode validation out of the iOS validator and into a stand-alone
validator, and groups the CocoaPods validator with that top-level
validator instead of the iOS validator. iOS now validates only the
iOS-specific tools (e.g., ideviceinstaller).
Reorganizes many of the associated clases so that those that are used by
both macOS and iOS live in macos/ rather than ios/. Moves some
validators to their own files as part of the restructuring.
This is the macOS portion of #31368
Instead of requiring a name_output.sh, expect a file called
.app_filename in the macos/Flutter directory containing just the name of
the application. The expectation is that the Xcode build will create
that file with a script.
This is not intended as a long-term solution, but it's a substantial
improvement over name_output.sh:
- name_output.sh required constructing the full build output path; this
made sense when it was coupled with build.sh, but now that the
decision for where build output goes lives in flutter_tool, that logic
should as well.
- Changing the name of the application required also updating
name_output.sh, which is error-prone. With .app_filename, it can be
created using $PRODUCT_NAME, which means that the usual way of setting
the application name will automatically update this flow as well.
Part of #30706
- Removes SYMROOT from the Generated.xcconfig. Having it causes current
versions of Xcode to switch the project's build output to "Legacy",
which causes anything not overridden to use a project-relative build
directory instead of a shared directory in DerivedData, breaking
anything with subprojects that it depends on.
This means that `flutter run` and builds from Xcode will use
completely different build directories, but that each should be
internally consistent.
- Moves the FlutterMacOS.framework to $SRCROOT/Flutter. This is
consistent with the approach we're moving to for all desktop
platforms, and avoids issues finding it now that SYMROOT doesn't match
for the two different build modes.
Fixes#32494
