iOS: Migrate FlutterAppDelegate to ARC

[cbracken]

Migrates the FlutterAppDelegate.mm translation unit to be compiled with the -fobjc-arc compiler flag.

No test changes since no this change includes no semantic changes, and thus covered by existing tests such as testReleasesWindowOnDealloc.

Issue: flutter/flutter#137801

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 and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I'm pretty sure this patch makes me a software ARCictect.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

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

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[matanlurey]

test-exempt: No semantic changes.

[jmagman]

This imports "FlutterViewController" so that's why it wasn't done yet. We were migrating leaf -> root. That made me refactor some as I was doing the other ARC work, like #52271.

However, I'm not sure if the value of doing that is worth needing to migrate FlutterViewController and FlutterEngine monsters together (they are so snarled I couldn't break the import cycle). wdyt?

[jmagman]

That made me refactor some as I was doing the other ARC work, like #52271.

Another example #52729

[cbracken]

I'm tempted to migrate piecewise what we can safely migrate until we whittle it down to nothing. As you say, that lands us at the FlutterEngine/FlutterViewController tangle in the end. Any reason to limit ourselves to taking a leaf to root approach?

[cbracken]

Any reason to limit ourselves to taking a leaf to root approach?

Answering my own question -- I'd likely need to look at the FlutterViewController header to answer that one. Taking a look.

Answer: it looks like there's nothing that would be problematic in there at the moment, and I'd expect the compiler to shout if anyone were to add, say, an assign property etc.

[jmagman]

Any reason to limit ourselves to taking a leaf to root approach?

@stuartmorgan I thought there was a design doc for this, but I can't find it. I wasn't able to untangle the dependencies of the remaining MRC files:

engine/shell/platform/darwin/ios/BUILD.gn

Lines 182 to 194 in f21f2b2

	"framework/Source/FlutterAppDelegate.mm",
	"framework/Source/FlutterEngine.mm",
	"framework/Source/FlutterEngineGroup.mm",
	"framework/Source/FlutterEngine_Internal.h",
	"framework/Source/FlutterHeadlessDartRunner.mm",
	"framework/Source/FlutterPlatformPlugin.h",
	"framework/Source/FlutterPlatformPlugin.mm",
	"framework/Source/FlutterViewController.mm",
	"framework/Source/FlutterViewController_Internal.h",
	"framework/Source/accessibility_bridge.h",
	"framework/Source/accessibility_bridge.mm",
	"platform_view_ios.h",
	"platform_view_ios.mm",

I'm not sure when we're even going to have the bandwidth to migrate all of those in one monster-PR, especially with merge conflicts (I sure gave up). What do you think about merging the rest individually, ignoring the dependency tree, if we commit to actually doing it all ASAP but in separate PRs? Can you think of why that's a really bad idea, vs keeping these last few MRC files around forever?

[stuartmorgan-g]

Any reason to limit ourselves to taking a leaf to root approach?

@stuartmorgan I thought there was a design doc for this, but I can't find it.

When we were still on the old, pre-ARC scoped_nsobject we basically had to do leaf-up because we couldn't have any transitive dependencies on scoped_nsobject or it wouldn't compile.

With the ARC-safe scoped_nsobject, I don't think there should be any ordering requirements.

[jmagman]

Thank you!