It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

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.

Thank you for the contribution!

There are some test failures:

URLLauncherTests.m:14:3: error: unknown type name 'FLTURLLauncherPlugin'; did you mean 'URLLauncherPlugin'?
  FLTURLLauncherPlugin *plugin = [[FLTURLLauncherPlugin alloc] init];
  ^~~~~~~~~~~~~~~~~~~~
  URLLauncherPlugin

https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8790012544451333521/+/u/Run_plugin_tests/native_test/stdout

Also:

    - ERROR | [iOS] xcodebuild:  /Volumes/Work/s/w/ir/x/w/plugins/packages/url_launcher/url_launcher_ios/ios/Classes/URLLauncherPlugin.swift:50:64: error: 'universalLinksOnly' is only available in iOS 10.0 or newer

https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8790012544451333521/+/u/Run_plugin_tests/native_test/stdout

At this exact moment url_launcher supports iOS 9, however I was working on (but got distracted) getting the minimum up to iOS 11 #6865 which should make this go away without the need for an availability check. Let me pick that up again and you can rebase.

At this exact moment url_launcher supports iOS 9, however I was working on (but got distracted) getting the minimum up to iOS 11 #6865 which should make this go away without the need for an availability check. Let me pick that up again and you can rebase.

#7110

During the migration, I dropped the @available(iOS 9, *) attributes and a flag check for iOS 10+ support, seeing as how Flutter now supports a minimum of iOS 11. When I opened the project in Xcode, it also seemed to update a few scattered config options from iOS 9 to iOS 11 - if those are unwanted, let me know and I'll exclude those changes.

#7110 has landed, would you mind rebasing on that? That should take care of the podspec lint failure and have the Xcode project/Podfile changes.

@Serdnad Thanks for the contribution! I noticed this PR does not have tests. To reduce the risk regression we want to backfill tests, as discussed in the swift migration section of the wiki.

@hellohuanlin I noticed that part of the wiki, but wasn't sure what would benefit from unit testing here that wasn't already tested in the UI tests.

I can write unit tests for canLaunchUrl, but I'm not sure what else there is in here that can be easily unit tested. Could you list some functions that should have tests, or point me to an example of unit tests for plugins?

I noticed that part of the wiki, but wasn't sure what would benefit from unit testing here that wasn't already tested in the UI tests.

The Dart integration testing of this plugin is extremely minimal due to the inability to test native UI from those tests; native unit test coverage can be far more thorough here.

I can write unit tests for canLaunchUrl, but I'm not sure what else there is in here that can be easily unit tested. Could you list some functions that should have tests

All system interactions (launching URLs externally, interactions with the Safari view controller, etc.) can be unit tested via protocol mocking, so that there's meaningful test coverage of the implementation.

My bad, I'd completely missed the native tests in the example project. I tested and then migrated the few that were already there to Swift, and then filled in additional unit tests - at least one for each supported handler method, and one for a nonexistent method.

I also cleaned up a bit of unused code that I'd initially ported over, and updated the example project so that the universal link button opens a Youtube link, instead of the default link that'll never be opened in an app.

@Serdnad I recommend doing test backfilling and swift migration in separate PRs, so that it's easier for review.

You may also want to checkout this section of the design doc about regression.

Thanks for the review jmagman! Not sure why I needed to add those changes before - I applied your suggestions just now and everything's building fine.

@hellohuanlin I separated the new unit tests out into #7123, and will rebase (and format) this PR after that one's in.

The initial pass was done with a conversion tool, and then I manually fixed any errors, made the code slightly more idiomatic

@Serdnad out of curiosity, what conversion tool did you use? How was it to use? How much did you have to change to make it idiomatic?

@jmagman I actually used chatGPT haha. Fed it a couple functions at a time and pieced them together afterwards. The initial code was pretty good, though I think I had to make a couple fixes to get it to compile.

From there, making it more idiomatic was mostly simplifying a few spots using optional chaining, and iirc tweaking a function signature or two, but that was about it.

Little unconventional, but free to use (for now at least), and I have no doubt it was faster than it would've been for me to do manually.

I actually used chatGPT haha.

Unfortunately, the guidance we've received from our legal team is that we can't accept contributions that were authored or co-authored by a generative system such as ChatGPT, because the authorship is not well defined, and thus can't be covered by the CLA that all our contributors agree to. Regretfully, we'll need to close this PR as a result :(

We're sorry for the unexpected outcome here; it's great that you're interested in helping to modernize our plugin implementations, and we hope you'll consider contributing to other migration efforts in the future (without using ChatGPT or similar systems)!