[various] Update example apps to Swift (#9347)
Converts the Objective-C iOS example apps for all non-iOS-plugin-implementation packages to Swift.
The process for this was (all using current stable, 3.32):
- Deleted example/ios.
- Ran flutter create --platforms=ios ..
- Reverted changes in ios/Runner/Assets.xcassets/AppIcon.appiconset (this doesn't really matter either way, I just decided not to thrash a bunch of icons, since there's no real reason to and it would have added a ton more files).
- Reverted changes outside of ios/, except for .gitignore which we may as well have a current version of.
- Added license blocks to template-created code files.
- Removed the RunnerTest target, its source file, and the Podfile adjustment to RunnerTest.
- Reverted bundle identifier changes in most cases, since it was often auto-detecting the old io.flutter.* org the examples were first created with.
- Re-added any important bits to Info.plist.
- Ran a build both with and without SwiftPM enabled, to ensure that all the Cocoapods and SwiftPM boilerplate is added to the projects to cut down on random diffs when people build later.
One-off changes:
- Added back Configuration.storkekit in in_app_purchase.
- Migrated the Google Maps API key code in AppDelegate.m to AppDelegate.swift
I did not convert the implementation packages in this PR because those will need to be handled more carefully, due to the presence of RunnerTest (and sometimes RunnerUITest) targets that need to be preserved.
Part of https://github.com/flutter/flutter/issues/148586
## Pre-Review Checklist
[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.
[tool] Use swift-format from Xcode (#9460)
As of Xcode 16, swift-format is part of the Xcode distribution. Since CI now uses Xcode 16, we can just always use that version.
This:
- Removes the swift-format-path logic.
- Removes the check for swift-format being available
- Defaults Swift formatting to true only on macOS
- Removes the swift-format CIPD package from .ci.yaml
- Updates Pigeon in packages using Swift Pigeon generation to pick up a fix for a lint issue picked up by the latest version of swift-format (which was already fixed in Pigeon).
Fixes https://github.com/flutter/flutter/issues/153803
## Pre-Review Checklist
[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.
[tool] Use swift-format from Xcode (#9460)
As of Xcode 16, swift-format is part of the Xcode distribution. Since CI now uses Xcode 16, we can just always use that version.
This:
- Removes the swift-format-path logic.
- Removes the check for swift-format being available
- Defaults Swift formatting to true only on macOS
- Removes the swift-format CIPD package from .ci.yaml
- Updates Pigeon in packages using Swift Pigeon generation to pick up a fix for a lint issue picked up by the latest version of swift-format (which was already fixed in Pigeon).
Fixes https://github.com/flutter/flutter/issues/153803
## Pre-Review Checklist
[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.
[url_launcher][web] Prevent browser from navigating when followLink isn't called (#8675)
When a DOM click event is received, we need to make a decision before the end of the event loop whether to allow the browser to navigate or not. At the end of the event loop, the browser will perform the navigation if we don't prevent it.
The problem occurs when the followLink signal arrives AFTER the event loop (this can happen in semantics mode when the web engine uses a debouncer to queue events and send them to the framework after some delay). This leads to a situation where we can't make a definitive decision by the end of the event loop, so this PR does the following:
1. [best case] If the followLink signal is received before the end of the event loop, we let the browser do the navigation for a full web link experience.
2. [meh case] If no followLink signal is received before the end of the event loop, we PREVENT the browser from navigating. But we keep waiting for the followLink signal. If the signal arrives a bit later, we fallback to a programmatic navigation through the launchUrl API.
Fixes https://github.com/flutter/flutter/issues/162927
Fixes https://github.com/flutter/flutter/issues/162408