An older Flutter iOS framework-target mismatch

An iOS framework built for one target cannot be assumed to link into another. The original Flutter report recorded:

[App.framework] Linked and embedded framework 'App.framework' was built for iOS/iOS Simulator
Could not build the application for the simulator.
Error launching application on iPhone 11 Pro Max.

The earlier dependency reset

sudo gem install cocoapods

rm -rf ios/Podfile.lock
rm -rf ios/Pods
rm -rf ios/.symlinks

cd ios

pod install

Removing Podfile.lock changes the dependency-resolution baseline, not merely a cache. The source’s unpinned CocoaPods installation is historical rather than a version-matched repair.

Project references and path case

Just use Delete References, don't move to Trash

Default Disk Type on Mac is “In Case-sensitive”
Like Unity does not work on “Case-sensitive” disk type => Some libraries config with the path in-Case-sensitive but run on “Case-sensitive” -> It can be imported with wrong case => Just move the source to another “Case-sensitive” disk type.

The final case-sensitivity note is internally inconsistent about which filesystem to move to. Its useful observation is narrower: a wrongly cased import or path can behave differently on case-sensitive and case-insensitive filesystems. Fixing the actual path mismatch is distinct from assuming a disk move solves every import error.

The original Flutter issue provides the historical report. No dependency reset, filesystem move, or iOS build was performed for this revision.

← Back to the garden