Exactly, the first check : A check on our status page that defines if the server is working properly We get a json that defines the status of our server on each different macro services (authentication resource access, etc) with operational, downtime, issues The second check: A check on an endpoint to see if the server is reachable is made only if the first one succeed and yes this is more of a reachability of our APIs endpoints, just expecting a body with ok. If the request goes on timeout or cannot find the host there is probably something blocking the outgoing connection. We applied this further control due to the fact that the domain of the first check is different from the second and we experienced some issues where the user had reachability of the first one, but not on the second due to firewall rules blocking requests to api.xyx domains. Best, Andrea

@eskimo ok the whole context is a little bit more complicated. We have 3 components to check if internet is available and our server is in a healthy status and reachable. The internet monitor A check on our status page that defines if the server is working properly A check on an endpoint to see if the server is reachable Use cases If the device is not connected we notify the user If is connected but without internet we notify the user (this is something that at the moment we cannot do) If one of our request fails for some URLErrors we start to check our server status page. If something is not working we say the user the "we are experiencing problem" As a plus we check the reachability of an endpoint (it could happen that some network can access the status page but not the backend endpoint) At the moment if we are in a situation like the one mentioned before due to the fact that we cannot have the state connectedWithoutInternet we fallback on some URLError and start the process of checking our server that of course fail thus the user is informed, but the message we are sending is that we have a problem, while the resolution of the issue could be "try to connect to another network" because you don't have internet. This is not very optimal I would love to have something like in iOS settings when I connect to this kind of network Is there a way to configure NWPathMonitor to receive the same information?

Hello Quinn sorry for for getting back to you late. I tried but still is giving me satisfied as an answer. I also tried with different mobile router each one without SIM, but the answer is the same. Thank you, Andrea

Thanks, but It doesn't work, that black background is inside the player not under it

I have the same issue too. It doesn't happen on all devices but is consistent on iPhone 8 with iOS 16.7.5. The NSProcessInfoPowerStateDidChange is never called and the state is never updated during the same app session, it keeps returning the same value. Most weird the systemUptimeChanges, isLowPowerModeEnabled is the only state that never changes. Tried to dispatch on main thread, but the result are the same. protocol SystemPowerInfoProvider { var isLowPowerModeEnabled: AnyPublisher<Bool, Never> { get } } final class DefaultSystemBatteryOptimizationStateProvider: SystemPowerInfoProvider { var isLowPowerModeEnabled: AnyPublisher<Bool, Never> { _isLowPowerModeEnabled } private lazy var _isLowPowerModeEnabled: AnyPublisher<Bool, Never> = { return Just(ProcessInfo.processInfo.isLowPowerModeEnabled) .merge(with: NotificationCenter.default .publisher(for: Notification.Name.NSProcessInfoPowerStateDidChange) .map { notification -> Bool? in guard let processInfo = notification.object as? ProcessInfo else { return nil } return processInfo.isLowPowerModeEnabled } .compactMap { $0 } ) .eraseToAnyPublisher() }() } Where you able to solve it?

https://developer.apple.com/system-status/ As you can see here the service for TF and ApStore are not functioning

Same italy