❓ Issue: Session Disconnects When Switching From Wi-Fi to Mobile Data

[vishalblueberry]

Hi team,
I’m facing an issue with network switching while using the HashKit Library on iOS.
I'm using this commit id 6b445c2

Scenario:

My iPhone has both Wi-Fi and Mobile Data turned ON.

The app is currently using Wi-Fi for the HashKit session.

When I turn OFF Wi-Fi, the device should automatically switch to Mobile Data.

Problem:
As soon as I turn off Wi-Fi, the HashKit session gets disconnected and the library does not automatically reconnect using the available Mobile Data network.

Expected Behavior:
The session should stay connected or automatically reconnect when the network switches from Wi-Fi to Mobile Data.

Question:
Is this expected behavior in HashKit, or is there any setting/configuration required to support automatic reconnection on network change?

Thanks for your help!

[noho501]

I think you may want to listen for network changes and reconnect if necessary. I am also applying the same logic in my app.

init(networkMonitor: NetworkMonitor = NWPathMonitorNetworkMonitor()) {
    self.networkMonitor = networkMonitor
    Task {
        await self.setupNetworkMonitoring()
    }
}

private func setupNetworkMonitoring() async {
    networkMonitor.startMonitoring()
    networkMonitor.onNetworkStatusChange = { [weak self] isConnected in
        Task {
            await self?.handleNetworkStatusChange(isConnected: isConnected)
        }
    }
}

[vishalblueberry]

Yes, I’m using the same Apple-provided API to monitor network changes, but my issue is a bit different. Let me explain.

In the older version of HashinKit, we had the flexibility to publish or connect using different RTMP URLs dynamically. This was extremely useful in scenarios like network issues or server failovers, where we needed to retry with a different endpoint.

In the legacy implementation, we could simply pass a new endpoint directly via the RTMP connection:

rtmpConnection.connect(rtmpEndpoint)

However, in the latest version of HashinKit, the endpoint must be provided at the time of building the session instance, and there is no option to update or override it later. For example:

session = try await SessionBuilderFactory.shared .make(URL(string: streamUrl)) .setMode(.publish) .build()

If I want to switch to a new URL, I am forced to create a completely new session instance. This feels incorrect, adds overhead, and doesn't align with the earlier design where switching endpoints was supported without rebuilding the entire session.

Request:
It would be very helpful if the latest HashinKit could support updating or reconnecting with a new URL on an existing session — similar to how the RTMP connection allowed dynamic URL changes in previous versions.

Is this behavior intentionally removed, or is there a recommended approach for implementing retry logic with alternate endpoints in the latest version?

[shogo4405]

@noho501 Thanks for the follow.

It’s designed so that I can provide additional details at the next event.
RTMPConnection.Code.connectClosed.rawValue
(See: the linked code section.)

HaishinKit.swift/RTMPHaishinKit/Sources/RTMP/RTMPSession.swift

Lines 90 to 98 in 3e52fd8

	for await event in await connection.status {
	switch event.code {
	case RTMPConnection.Code.connectClosed.rawValue:
	_readyState.value = .closed
	disconnected()
	default:
	break
	}
	}

Of course, using the NetworkMonitor approach should work fine as well.

[shogo4405]

@vishalblueberry

If someone made that kind of claim, I’d think, “Ah, I see. Since the parameter part of rtmp://hostname/streamName?parameter can change, maybe it wouldn’t hurt to design it so that it’s configurable.”

But honestly, I still don’t really understand what the core issue is or what exactly they’re struggling with.
From the way that post reads, it seems like the person is having trouble with how to retry the connection. That’s how I interpreted it too.

In recent years I’ve gotten tired of this kind of unclear communication, so I stopped doing support.
So there’s really only one thing I can say:

It’s OSS — feel free to customize it yourself. The code is public, and changing it won’t bother anyone!

P.S.
The old RTMPConnection-style connection method is still available.