If NWPathMonitor was only introduced in iOS12/macOS10.14 that's problematic, this is a module used widely so rather than go past the current react-native minimum (which is 11) this module really should maintain compatibility with the iOS/macOS versions supported by the most recent couple of versions. It was 10 until quite recently (react-native 0.65 was released just a short while ago with that change to 11)

12 shouldn't be the minimum for quite a while

Similarly, react-native-macos runs on macOS 10.13 so using these symbols exclusively is problematic at this point

Separately - the compile error reminded me of this thebergamo/react-native-fbsdk-next#97 - I wonder if a separate commit (or separate PR?) with the needed change would do the trick.

That said, I haven't had any problems compiling netinfo with any version of Xcode up to and including the last Xcode 13 beta - I had not checked the RC and it's released proper as 13 now, but I assume it will still work. I'm surprised to see a compile error.

@mikehardy thanks for reviewing my PR! I really appreciate it!

Regarding compile errors – I compiled the example, and since errors are in React-Core, probably that's just some older version of ReactNative or something like that. I can dig into this.

Regarding deployment target:
I believe that SCNetworkReachability won't be able to differentiate between WiFI and Ethernet (here's the list of supported flags), so, unfortunately, to address that issue I had to use NWPathMonitor.

We can go with one of two options here:

• We could just close this PR because the feature visibility is rather small – I think, react-native is way more popular in mobile. If anyone would face this issue, they would be able to use my fork (or create their own)
• I can revert SCNetworkReachability and wrap it into ifdef to keep compatibility with older OSes. But this solution would be rather messy because we would have two independent approaches to achieve the same result. Which would complicate testing.

Please let me know your thoughts

I am actually all for new (better) API uses, and if it requires an IFDEF for new APIs, with the "old" style marked clearly as "delete when iOS deployment target is greater than XYZ" and the APIs themselves (in the README) are also marked clearly as "uses XYZ strategy for ios < NN / macOS < NN, uses ABC strategy for ios >= YY / macOS >= YY". That puts the information for necessary testing out there, marks it for sunset, and lets the newer/better APIs shine

I can say that I just compiled the module itself using Xcode 13 and it's fine, and I know it was fine on Xcode 12.5 etc so that must be some sort of error local to your environment or as you mention something about the react-native version in the example. The example is probably pretty stale so it's easy to guess that is the source...

(actually, rather than ifdef since those symbols should be available in all supported Xcode versions, maybe an if (@available(iOS 12.0, macOS 10.14, *) check, assuming that construction compiles)

Happy to merge this as long as it has some backwards-compatibility for the old style, iOS 12 is still not even the react-native default so that's a non-starter for a while unfortunately. Probably 2 years really.