Start here: https://developer.apple.com/documentation/technotes/tn3111-ios-wifi-api-overview

Also, a couple minor adjustments: if let httpResponse = response as? HTTPURLResponse { It’s generally safe to force the response as! HTTPURLResponse. If that optional binding were to actually fail, what then? extension UploadInv: UIDocumentPickerDelegate, URLSessionDataDelegate, URLSessionTaskDelegate, URLSessionDelegate You don’t need to list URLSessionDelegate or URLSessionTaskDelegate there, because URLSessionDataDelegate already extends them. I’m a little surprised there isn’t a compiler warning for that.

Well urlSession(_:task:didCompleteWithError:) always gets called last because it indicates the end of the task. And urlSession(_:dataTask:didReceive:completionHandler:) (response headers) needs to get called before urlSession(_:dataTask:didReceive:) (body) because depending on how you call the completion handler, it can change how the body gets handled subsequently. And it’s just natural that your code would receive the headers before the body. But for your situation, I think you can simplify by eliminating the response method entirely. Note the documentation says it’s intended for specific cases that don’t seem to apply here. Instead, just check the error and HTTP response code in the completion method, and then process the accumulated body data as needed. (Or if you keep the response method, note you need to call the completion handler to tell the system what to do next. The documentation isn’t clear on whether you should call it synchronously or asynchronously. Seems to me you should call it synchronously since it seems to work like a function return value, but I may be missing something subtle there.)

the app will forcibly go to the home screen Nope, that’s not a supported app lifecycle in iOS. I want the app to run in the background First, please see this excellent summary of issues you need to consider: iOS Background Execution Limits. After reviewing that information, does your desired behavior align with any of the supported scenarios?

For people following along: he implemented some URLSessionTaskDelegate and URLSessionDataDelegate methods in the view controller, but the URL session knew only that it claimed to be a URLSessionDelegate. The fix was to change this: extension UploadInv: UIDocumentPickerDelegate, URLSessionDelegate { ...to this: extension UploadInv: UIDocumentPickerDelegate, URLSessionDataDelegate {

The error is subtle. But toss this line in somewhere such as viewDidLoad and the issue will reveal itself: assert(uploadSession.delegate! is URLSessionDataDelegate)

Why do you enter a default text and not a placeholder ? Placeholder isn’t the right choice for proposing text that the user may choose to accept without further editing; it should be used as a hint to help the user know what to enter. For example, if saving a new document the default (proposed) name could be Untitled and the placeholder could be Enter a name. The placeholder would appear only if the user erases the proposed name. And here’s a tip on enabling the button to match the text. If you reuse the text change handler for .editingDidBegin like this: textField.addTarget(self, action: #selector(self.alertTextFieldDidChange), for: .editingDidBegin) textField.addTarget(self, action: #selector(self.alertTextFieldDidChange), for: .editingChanged) ...then it will get called just before the alert appears, but after the needed alert?.actions array is set up. So now your enable/disable logic can be in just one place.

Have you considered using Bluetooth LE? The ESP32 includes BLE and it may be a better fit for your use case. Note there’s an existing BT SIG specification for a service called Automation IO that basically exposes GPIO over BLE, which sounds like what you are doing. You may even find an ESP32 library somewhere that implements that service. Or your own minimal service would work too of course.

If you mean exiting out of your app to the home screen of the device, that’s called “crashing” and will likely get you rejected by App Review. On iOS you should never have a user-facing feature for quitting the app.

It’s a field called associatedStoreIdentifiers.

If you rewind that WWDC video a bit to 3:27, when she says “when I press on the button” you can see there no visual feedback on the button itself, which is the issue we’re talking about. So it seems this behavior has been hiding in plain sight the whole time. It definitely doesn’t feel like the high level of polish and precision that we’re used to in an Apple user interface. Judging by the results if you search for “CLLocationButton” in the forum, it feels to me like this feature overall needed a little extra time in the oven before calling it done. Let’s see if it gets better in iOS 16.

You are seeing correct behavior. The iPhone 5s supports up to iOS 12, which you already have. It’s too old to run iOS 13 or newer.

Now that you have your JSONSerialization-based code working, you should consider whether this could be implemented more easily / safely / etc. using the Decodable protocol and the JSONDecoder class, if you have’t looked into this approach already.

Is this an unexpected error, or are you actually trying to use a version of Xcode that old?

Hint: "%.0f" is not a valid format string for an Int value. Tip 1: When sharing code, please paste it in as text and apply the Code Block formatting style, rather than a screenshot. Tip 2: Consider using a NumberFormatter (if you need any fancy formatting) rather than the more error-prone String(format:_:).