[macOS] Migrate @NSApplicationMain attribute to @main

[loic-sharma]

This migrates Flutter to use the @main attribute introduced in Swift 5.3. The @NSApplicationMain attribute is deprecated and will be removed in Swift 6. See: https://github.com/apple/swift-evolution/blob/main/proposals/0383-deprecate-uiapplicationmain-and-nsapplicationmain.md

This change is split into two commits:

1. a508d3e - This updates the macOS app template and adds a migration to replace @NSApplicationMain uses with @main.
2. f434827 - I ran flutter run -d macos on each Flutter macOS app in this repository to verify the app migrates and launches successfully.

Follow-up to #146707
Fixes #143044

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[hellohuanlin]

Thanks for doing this!

@jmagman One thing in my mind is whether this kind of migration scripts will get out of hand in the future? Because keeping track of the delta can be tedious.

Strawman idea - what if we just regenerate the whole thing? This way we can have a simple one-for-all migration script that simply detects some sort of version change.

[hellohuanlin]

im wondering if it's possible to reuse the ios migration?

[loic-sharma]

They're very similar but subtly different - the affected file is different, the log messages are slightly different (due to differences in path), the attribute is different. The migration logic would need to be more a little more complicated to support both platforms.

Personally I think this duplication results in simple code that's easier to maintain. That said, both approaches are viable and I'm happy to defer to whatever the team prefers :)

[jmagman]

Strawman idea - what if we just regenerate the whole thing? This way we can have a simple one-for-all migration script that simply detects some sort of version change.

We can't regenerate files Flutter doesn't "own", at least not easily, or we would blow away the user changes. For example in https://github.com/flutter/flutter/pull/146707/files#r1566254461, if we had regenerated the AppDelegate the user would have lost all their changes.

flutter/examples/platform_channel_swift/ios/Runner/AppDelegate.swift

Lines 22 to 23 in 2240998

	@main
	@objc class AppDelegate: FlutterAppDelegate, FlutterStreamHandler {

The Xcode project files are another example: users are supposed to edit their Xcode project in some cases (as you know from your validator tool work), so we can't just regenerate it for them without keeping track of the deltas in a much more complicated, error-prone way.

There was an attempt to do something much more complicated with https://github.com/flutter/flutter/wiki/Flutter-migrate, (see https://flutter.dev/go/flutter-migrate and #40460), but it was extremely complicated and required users running a tool explicitly, and allowing rollbacks. There wasn't much appetite to finish up that project since these incremental migrations that essentially just string match (the first one was introduced in #51453) were doing a decent enough job. Before that, users would just get build errors and have to figure out how to fix them themselves.

[jmagman]

LGTM!