Repackage go binaries into XCFramework package supporting iOS/macOS (and probably iOS Simulator/Catalyst)

[mredig]

The update leverages GitHub Actions to prebuild the go binaries and make a GitHub release, allowing SPM to use a binary xcframework target.

[mredig]

I wasn't aware of the sign off requirement and I cannot rebase the commit messages without breaking the history that the tags and newly added workflow based releases rely on.

If merging this with the upstream code base is something the team wants to proceed with, you have my permission to manually apply the differences yourself based on my changes, otherwise I/we can probably come up with a solution by just managing a separate branch/squash history or something like that.

Signed-off-by: Michael Redig juniper.fife_0b@icloud.com

[beni7192]

Summary

The official iOS WireGuard client frequently stops receiving incoming traffic (Rx = 0) after a few minutes of activity on certain mobile networks — especially in Iran and similar environments. Outgoing packets (Tx) continue to be sent, but no response is ever received unless the tunnel is toggled off and on again. The exact same configuration works flawlessly on macOS and on alternative iOS clients such as ShadowRocket or Passepartout.

---

Steps to Reproduce

1. Import a known-working WireGuard config (tested on macOS or Linux).
2. Connect using the official iOS client.
3. Use any traffic-generating app (e.g., Telegram, browser, ping).
4. After a few minutes (typically 2–10), the incoming traffic drops to zero while outgoing continues.
5. Disconnecting and reconnecting the tunnel restores functionality — temporarily.

---

Environment

• Device: iPhone 13 Pro
• iOS Version: iOS 17.5.1 (also tested on iOS 16.x)
• WireGuard App: v1.0.16 (latest from App Store)
• Network Type: LTE/4G (mobile data) – tested with multiple carriers (e.g., MCI / Irancell in Iran)
• Server Side: Linux WireGuard / MikroTik RouterOS — stable and verified
• Keepalive: PersistentKeepalive = 25

---

Observations

• ShadowRocket using same WireGuard config does not have this issue.
• The problem is reproducible with various servers and protocols (UDP over different ports).
• The iOS client seems to silently stop receiving packets, possibly due to:
  • UDP NAT timeout not being handled properly.
  • iOS backgrounding or socket suspension.
  • Keepalive packets not being sent properly under certain conditions.

---

Why This Matters

This issue severely affects usability of the official iOS client in regions with network restrictions or aggressive NAT/firewall setups. Many users in Iran, China, and similar countries face this. Other apps somehow manage to maintain tunnel state and receive traffic properly under the same conditions.

---

Request

Please investigate:

• Whether PersistentKeepalive logic is being suppressed under certain conditions.
• If additional socket options or timers (like SO_KEEPALIVE or similar) are needed.
• Whether iOS-specific backgrounding constraints interfere with UDP tunnel stability.

I'm happy to assist with logs, test builds, or further debugging.

Thanks for your work on WireGuard!

[mredig]

Summary

The official iOS WireGuard client frequently stops receiving incoming traffic (Rx = 0) after a few minutes of activity on certain mobile networks — especially in Iran and similar environments. Outgoing packets (Tx) continue to be sent, but no response is ever received unless the tunnel is toggled off and on again. The exact same configuration works flawlessly on macOS and on alternative iOS clients such as ShadowRocket or Passepartout.
...

This looks unrelated to the topic at hand. Are you sure you posted this in the right channel?