fix(ios): prevent alert view dismiss from triggering onBrowserClosed event

[andredestro]

This PR fixes an issue where dismissing an alert view triggered the onBrowserClosed event.

[OS-pedrogustavobilro]

Isn't it missing package.swift update?

[andredestro]

Isn't it missing package.swift update?

Since we're using from: "2.2.0", it will include all versions from 2.2.0 up to (but not including) 3.0.0. Therefore, if the changes are compatible, it should still function properly.

[OS-pedrogustavobilro]

Since we're using from: "2.2.0", it will include all versions from 2.2.0 up to (but not including) 3.0.0. Therefore, if the changes are compatible, it should still function properly.

Yes, but shouldn't we make sure the native code is the most up-to-date?

from: "2.2.0" can mean that we launch a new plugin version but this bug still remains because the native library version is not the most up-to-date no?

I suppose that it isn't a big deal since the bug isn't "severe". But still.

Let me know if what I said makes sense

[andredestro]

Since we're using from: "2.2.0", it will include all versions from 2.2.0 up to (but not including) 3.0.0. Therefore, if the changes are compatible, it should still function properly.

Yes, but shouldn't we make sure the native code is the most up-to-date?

from: "2.2.0" can mean that we launch a new plugin version but this bug still remains because the native library version is not the most up-to-date no?

I suppose that it isn't a big deal since the bug isn't "severe". But still.

Let me know if what I said makes sense

You're right, we should make sure the native code is using the most up-to-date version.

The from: "2.2.0" rule will always pick the most recent compatible version within the 2.x range (e.g., 2.2.1, 2.2.2...), unless the build environment is using a Package.resolved (which is usually ignored via .gitignore) file that pins it to an older version like 2.2.0.

To make things clearer, we could either:

• Manually update the version in Package.swift, or
• Use exact: instead of from: to guarantee the specific version used.

What do you think?

[OS-pedrogustavobilro]

I think because the plugin code is tightly coupled to the native library - in the sense that updates to the library will almost always result in new versions in the plugin - maybe exact makes more sense.

What is the experience for existing plugin clients using SPM when we update the dependency on the native library (not very relevant for this plugin right now, but relevant for future versions) - will cap sync fail like in CocoaPods, and users have to make manual changes to update the pods?