Temporarily remove Wormholy

[mokagio]

Description

#15663 shows how Wormholy currently does not build with SwiftPM. This PR temporarily removes it in the interest of finishing the CocoaPods removal.

I say temporarily because, as discussed internally, we value having a library like Wormholy in the app.

I considered simply leaving the library as the only CocoaPods one. Given it's only used in the app target, it wouldn't affect the upcoming modules move work. But I think we're better off getting rid of CocoaPods sooner rather than later. This would make the setup leaner and unlock further improvements such as dropping the workspace file

Steps to reproduce && Testing information

I guess referring to green CI is enough here.

Screenshots

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS Prototype by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS Prototype
	Build Number	30050
	Version	PR #15668
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	a5f6224
	Installation URL	60glsvcsr57ro

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[mokagio]

[AliSoftware]

I wonder if it wouldn't be better to completely remove all the references to Wormholy completely, including such code, instead.

My rationale is that, while I got that the team values having a network debugging tool that's embedded directly within the app, given the current compatibility issues between Wormholy and SPM to only enable it in debug, and that we don't know if they're ever gonna be resolved (and even if we do, no idea how long it'll take until we find a compatible solution):

• Maybe once we get back to this topic of having a network debugging tool in-app, we'll end up choosing an alternative library to Wormholy, one that provides similar features but is compatible with how we want to integrate in the project with SPM
• Maybe, as much as the team wishes to have such a tool in the codebase, we'll never find a satisfying solution in SPM's world for that, and that legacy code will thus be left to rot and pollute the codebase with dead code; not ideal for maintenance mid-to-long term.
• Even if we were to find a solution to integrate Wormholy back into the codebase via SPM, one could just revert this PR, to restore all the Swift code related to Wormholy's integration to speed up the future re-integration of that package via SPM.

I mean, git is exactly made for this (ability to revert changes), so might as well clean things up anyway.

[AliSoftware]

I considered simply leaving the library as the only CocoaPods one. Given it's only used in the app target, it wouldn't affect the upcoming modules move work. But I think we're better off getting rid of CocoaPods sooner rather than later. This would make the setup leaner and unlock further improvements such as dropping the workspace file

Agreed 👍

---

Approving to unblock; though I'd suggest to just completely remove all the Wormholy-related code instead of keeping the entry and replacing it with an alert, as we can always git-revert if we end up integrating it again with SPM (or not, if we go with a different network-debugging package after all)

[AliSoftware]

I wonder if it wouldn't be better to completely remove all the references to Wormholy completely, including such code, instead.

My rationale is that, while I got that the team values having a network debugging tool that's embedded directly within the app, given the current compatibility issues between Wormholy and SPM to only enable it in debug, and that we don't know if they're ever gonna be resolved (and even if we do, no idea how long it'll take until we find a compatible solution):

• Maybe once we get back to this topic of having a network debugging tool in-app, we'll end up choosing an alternative library to Wormholy, one that provides similar features but is compatible with how we want to integrate in the project with SPM
• Maybe, as much as the team wishes to have such a tool in the codebase, we'll never find a satisfying solution in SPM's world for that, and that legacy code will thus be left to rot and pollute the codebase with dead code; not ideal for maintenance mid-to-long term.
• Even if we were to find a solution to integrate Wormholy back into the codebase via SPM, one could just revert this PR, to restore all the Swift code related to Wormholy's integration to speed up the future re-integration of that package via SPM.

I mean, git is exactly made for this (ability to revert changes), so might as well clean things up anyway.

[mokagio]

Thanks @AliSoftware ! You put into words the feeling I had when looking at my inconsistent diff, where some of the code was removed and other commented.

I have a Linear project for the followup https://linear.app/a8c/project/re-introduce-network-logger-in-woocommerce-ios-22394768b3b5 . I'll remove the remaining code and add a line about this PR as a source to reintroduce the code to toggle Wormholy in the project.

[mokagio]

Just a screenshot with the result of the updates to the settings screen removing the Wormholy entry:

A search now only returns entries in the localizations, plus one in the licenses file. I thought the latter was generated automatically, but I can't find the script. I'm chasing that down... Track via https://linear.app/a8c/issue/AINFRA-617