I've moved you over to Core OS > Networking because the solution here won't be Swift specific.
To start, there's no such thing as an "Internet connection". There's two problems with this term:
The Internet is not a homogenous thing. You can have access to some parts of it but not others.
The Internet is packet based, not connection based, so asking about connections makes little sense. The N'th packet you send might make it through to the destination while the N+1'th does not, or vice versa.
My general advice on this front is...
If you need to make an Internet request, just make it. It's impossible for you to determine in advance whether a request will work or not and, even if you could, the answer could change immediately after you make that determination.
The System Configuration framework reachability API can give you limited information about whether a connection to a particular host will work or not. This is not perfect—you can get both false positives and false negatives—so you must not use it as a preflight mechanism. It is, however, great for failure guidance:
If a request fails, you can run a reachability query to see if it's failed for an obvious reason and use that information to tell the user what's going on.
If a request fails, you can use a reachability query to watch for reachability changes. If you get one, it's a good idea to retry your request.
The canonical example of this API is the Reachability sample code. Be aware, however, that this just shows how to run a query, it doesn't show you the best way to use those queries in the context of your overall app.
In general you should not modify the default network timeouts provided by the system. Rather, you should provide progress information and give the user a way to cancel and retry the request.
In my experience network requests fall into two categories:
solicited requests (A), that is, those that are the direct result of user action
unsolicited requests (B), that is, requests that happen 'in the background'
For A, you should have a cancel and retry user interface. This effectively puts the user in charge of the timeout.
For B, a long timeout shouldn't matter because you're not blocking the UI while waiting for the request to complete.
Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"