0.0.14

Fixed

• injectEntitlement wrote a file Xcode never read. The op set the key in ios/Runner/Runner.entitlements and stopped, so unless somebody had already opened Xcode and added the capability by hand, CODE_SIGN_ENTITLEMENTS was unset and the entitlement was inert. The op now also points the application target at that file. Concretely this is what made an installer-driven iOS push setup impossible: the plist was correct and the build ignored it.

• A project.pbxproj the reader declined to touch aborted the whole plugin install, half-applied. XcodeProjectEditor refuses to write a project it cannot re-emit byte for byte, and that refusal arrived at InstallTransaction's dispatcher catch as an Error, so the install stopped. Stopping undid nothing: the entitlements plist and every earlier helper-backed write (pubspec.yaml, the gradle files, Info.plist, .env) had already landed and none of them roll back, so the operator was left holding a partial install and an exception string. The trigger is ordinary rather than exotic. Xcode escapes non-ASCII in that file as \Uxxxx, the parser resolves an escape it does not model to the bare character, and the re-emission then differs, so a project whose PRODUCT_NAME is "Caf\U00e9" was enough to reach it. The refusal is now a warning beside the two cases that were already non-fatal (no .xcodeproj at all, and a target already signing with a different entitlements file): it names the value to set on the application target and says that Runner/Runner.entitlements stays inert until the setting carries it. A project.pbxproj that is not a valid project file at all still aborts the install, because that is not the editor declining to write a project it read and it is not answered by editing a build setting by hand. The round-trip guard itself is unchanged; refusing to write a file it cannot reproduce exactly is what makes the editor safe to point at a real project.

• PlistWriter and PodfileEditor refused to edit a file that did not exist yet, which is every Flutter project's entitlements file until somebody opens Xcode, and every Swift Package Manager project's Podfile always. Both now create the file first. PlistWriter creates ONLY an .entitlements path: an absent Info.plist still throws, because that means the caller has the wrong path and inventing one would hide it.

• A created Podfile is now shaped for the platform it is created for. PodfileEditor's creation path is reached from setPlatformVersion, addPostInstallHook and addPodLine, and all three accept macOS, so the first cut wrote one iOS-shaped file for both: platform :ios, '12.0' and flutter_install_all_ios_pods. On a macOS project with no Podfile that produced a file nothing could build. setPlatformVersion(path, 'macos', v) matches platform :osx, missed the :ios line the creation had just written, and took its prepend branch, so the file ended up carrying TWO platform declarations; and flutter_install_all_ios_pods is not defined by the macOS half of Flutter's podhelper.rb, so pod install failed with an undefined method. Creation now takes the platform from the caller and emits platform :osx with flutter_install_all_macos_pods for macOS, which is also what makes the following setPlatformVersion REPLACE that line instead of adding a second one. The mapping lives in one place now, so the created file and the regex that later edits it cannot disagree again. Worth stating plainly, because it is a regression this branch introduced and not an old bug: before create-if-absent, that same call threw and wrote nothing. This is a helper-backed write path the installer does not roll back, so a wrong file has no undo.

• A created Podfile called four Flutter helper functions and defined none of them, so pod install failed on both platforms. The file said flutter_install_all_ios_pods (or the macOS one) and stopped there. Those are Ruby methods from Flutter's packages/flutter_tools/bin/podhelper.rb, and a Podfile only has them after it requires that file, which it can only do once it knows where the Flutter SDK is. So the whole preamble Flutter's templates/cocoapods/Podfile-* carry is load-bearing rather than decoration: a flutter_root function that reads FLUTTER_ROOT out of the generated xcconfig (ios/Flutter/Generated.xcconfig on iOS, macos/Flutter/ephemeral/Flutter-Generated.xcconfig on macOS, each raising a named error when it is absent because flutter pub get has not run), the require of podhelper relative to it, and the flutter_ios_podfile_setup / flutter_macos_podfile_setup call. The created file now carries all of it, generated from Flutter 3.47's own two templates, along with the analytics opt-out, the project 'Runner' build-configuration map and a post_install block calling the platform's flutter_additional_*_build_settings. It diverges from the templates in exactly two places, both deliberate: the iOS platform line is written uncommented, because setPlatformVersion edits that line and a commented one would make the bump inert, and the nested target 'RunnerTests' block is omitted, because CocoaPods aborts on a target name its Runner.xcodeproj does not carry and a project without a Podfile need not have a test target. Worth stating plainly: before this, the created file could not pod install on EITHER platform. The macOS fix above corrected which helper was named; it was still a name nothing defined.

• addPodLine and addPostInstallHook refuse to create a Podfile when the caller does not name a platform. Both gained an optional platform: argument; without it an absent file throws FileSystemException exactly as it did before this branch. Neither method can infer the platform from its own arguments, and a Podfile is platform-shaped down to the podhelper function it calls, so guessing produces the broken file described above. Refusing to create one is the recoverable failure. setPlatformVersion already takes the platform and creates as before.

• InjectPodfileLine creates an absent Podfile again. The refusal above cost the op the capability it was given earlier on this branch: InstallTransaction called addPodLine without platform:, so on a project whose ios/ or macos/ directory holds no Podfile (every Swift Package Manager project, always) the op stopped with Podfile not found instead of writing one. It carries op.platform and now forwards it, so both platforms get a file of the right shape. It is the only PodfileEditor call site in lib/ that mutates a file; the other reference, ConflictDetector, only computes the path.

• A created Podfile no longer declares a deployment target three major versions below the project's own. It said platform :ios, '12.0', a constant with nothing behind it; the created file now declares iOS 15.0 and macOS 12.0, the values Flutter 3.47's own flutter create templates carry (templates/cocoapods/Podfile-ios and Podfile-macos), and iOS 15.0 is also the IPHONEOS_DEPLOYMENT_TARGET of the consumer this work was driven by. Reading the project's real target would beat any constant, but it lives in Runner.xcodeproj/project.pbxproj and the helper is handed a Podfile path only. Under-declaring is the harmful direction: CocoaPods then resolves pod versions older than the project can use.

Added

• XcodeProjectEditor.setEntitlementsPath(), a trivia-preserving OpenStep-plist reader and writer for .pbxproj, with one public setter and no general mutation API. Three properties are load-bearing rather than incidental. It scopes the write to the PBXNativeTarget whose productType is com.apple.product-type.application, reached through its buildConfigurationList: a stock Flutter project holds nine XCBuildConfiguration blocks and only three are the app's, so a naive sweep would put a signing entitlement on the test bundle and the project defaults. It parses, re-emits and compares byte for byte before touching disk, and refuses rather than writing a partially-edited project, because a truncated .pbxproj cannot be opened and the installer's helper-backed ops do not roll back. And it never REPOINTS a configuration that already names a different entitlements file: every macOS Flutter project carries Runner/DebugProfile.entitlements and Runner/Release.entitlements, and silently overwriting those would drop the sandbox grants they hold.

Documentation

• The installer DSL page described the smaller half of what injectEntitlement does. Its table said the op sets a key in Runner.entitlements and said nothing about the CODE_SIGN_ENTITLEMENTS write into <platform>/Runner.xcodeproj/project.pbxproj, a second file the transaction cannot roll back, nor about the three cases that warn and skip it (no .xcodeproj, a target already signing with another entitlements file, which is every macOS project, and a project the .pbxproj reader refuses). A plugin author reading that page would stage the op without knowing which files it touches, which is the same under-reporting the dry-run preview exists to prevent.
• The caret constraint quoted by doc/getting-started/installation.md, doc/commands/install.md and doc/plugins/authoring.md now tracks this release. One of them still said ^0.0.4, which tells a reader the package never moved.