Module stability Swift 5.1

[nick3389]

Hello,

Since Swift 5.1 module stability is introduced for library compatibility for future releases of Swift. A .swiftinterface file is created which is actually the public header file for the library. To enable this, BUILD_LIBRARY_FOR_DISTRIBUTION must be activated in Build Settings. Is this something you have in mind or I can make a PR?

[jffmrk]

We do the following in our Podfile when importing the library (and others) to enable BUILD_LIBRARY_FOR_DISTRIBUTION so we don't get the warning in our project:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if ['ReachabilitySwift'].include? target.name
      target.build_configurations.each do |config|
        config.build_settings['BUILD_LIBRARY_FOR_DISTRIBUTION'] = 'YES'
      end
    end
  end
end

[nick3389]

@jffmrk Thanx for the suggestion, but I have a couple more dependencies and I must do this for each one of them. I will make a PR and see if it's accepted or not.

[rockebee]

Hi @nick3389, please correct me if I'm wrong, but I think what you are looking for has been applied already with PR #366, isn't it? Unfortunately no new release had been created since last October's v5.0.0 release, so you may need to refer to the most recent Git commit rather a version.

However, having said that, I'm myself running into an issue with the generated .swiftinterface files containing references to Reachability.Reachability and which I had to manually replace with Reachability in order to being able to compile it. Not really sure how that happens and whether this is a Carthage-related issue or not, but maybe you can let me know whether this is working out-of-the-box for you or not.

@ashleymills, any idea on the Reachability.Reachability issue and/or any plans to make an official 5.1.0 release or so which combines integrated patches since last October?

[nick3389]

@rockebee Thanx for the info. I didn't check this before. As for the Reachability.Reachability issue this is a limitation from Swift when your xcode project and one class/struct or whatever have the same name. Unfortunately, the only way until now is to remove the first reference.

[rockebee]

Thx @nick3389 for the info - do you have by chance some reference for this Swift limitation where I could read deeper into? Do you mean that (a) my project seems to use same name "Reachability" for something, or that (b) the Reachability project is using same name for project and for some class/struct/whatever?

• If first one: Not that I'd be aware of, but may need to double-check
• If the latter one: Any idea how is that supposed to play along with any dependency management system like Carthage or Cocoapod - there is no nice way to modify the dependencies' .swiftinterface files automatically I guess ...?!

(Sorry for getting OT)

[ashleymills]

@rockebee @nick3389 I've just created a v5.1.0 release. This should solve your initial problem.

[nick3389]

@ashleymills Actually I wanted to tell you that I still get the warning from XCode: Module 'Reachability' was not compiled with library evolution support; using it means binary compatibility for 'your_library' can't be guaranteed.

@rockebee It's the second one. You can read more about it here. You can use the following command after your xcframework is created:

find . -name "*.swiftinterface" -exec sed -i -e 's/Reachability\.//g' {} \;

Even better you can add it in a script which has all the commands for creating a xcframework, then navigate inside the .xcframework folder and run this command.

[rockebee]

@ashleymills: 👍 Thx! Much better than referring to a Git commit :)

@nick3389: For us the warning vanished after switching to latest Git commit as well as now with the new 5.1.0 release. Have you ensured that the dependency is rebuild after you updated the release reference? Apart from that thx for the addon info about the Swift issue and the script-approach to get rid of the doubled names. However, as we are not using XCFrameworks yet and also do not bundle our dependencies, I do not yet fully get the intended approach - does it mean each of our framework's consumers which are pulling MyFramework plus Reachability via Carthage will need to apply the .swiftinterface fix in their build phase?

[nick3389]

@rockebee The script actually renames the old file and creates a valid copy with the fixed file. I do the same when I have a new version for our XCFramework for our clients and it works just fine. So, your consumers won't have to do anything apart from importing the .xcframework in their project. To be honest, I do not use Carthage but Cocoapods and our clients get our framework through a private distribution channel, so they just copy-paste it into their project. So, I don't know if there is any issue with Carthage, but I guess we can give it a try. Most probably it will work ok!

@ashleymills Thanx!

[nick3389]

@ashleymills v5.1.0 is still not available in Cocoapods. The PodSpec is not updated as I saw.

[rockebee]

Hi @ashleymills, seems that the PodSpec is still not updated (at least latest Reachability version is still not yet available via Cocoapods). Would you mind to update and publish the PodSpec so that version 5.1 will be cocoa-available?

Many thx for your efforts!

[rockebee]

Hi @ashleymills, I know this one here is quite old and there isn't much progress on the project in general, but would you see any chance of getting the PR #373 approved and update PodSpec to 5.1.0 release as well as updating trunk accordingly? Seems that quite a few people would really like to see this happen ...

Thx in advance!

PS: It might make sense to update the Readme or to create a sticky issue about current state of the project, as there hasn't been much activity recently. Maybe ask for other volunteers to support you in keeping the library up-to-date?