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:_:).

If your device supports Bluetooth LE, then yep you can work with it via Core Bluetooth. I did once implement both ends of a simple serial protocol over BLE (iOS central, BlueZ/Linux peripheral) and while it’s doable, my advice is to avoid this if possible and instead design a custom BLE profile that meets your needs. Shoehorning a serial stream into GATT is tricky to get right: you’re using characteristics to implement TX and RX buffers, ACKs, flow control, etc. (Though there are some implementations of it out there you may consider.) Here’s a good analysis of pros and cons of serial over BLE: https://punchthrough.com/serial-over-ble/

Are you talking about a Bluetooth Classic device supporting Serial Port Profile, such as an HC-05 module or similar? Core Bluetooth doesn’t support that.

Sounds like a restriction on free developer accounts, something like this: https://developer.apple.com/forums/thread/46202 However (from simple web searches) it sounds like the limit applies to how many app IDs you can create (or modify) rather than actual builds. If you’re developing your first app and just started encountering this error, please post some details to help troubleshooting. How many app IDs have you created? Have you been making changes (adding/removing capabilities) to app IDs? Sounds like changes count against that quota. Or if that comment refers to building 10 separate apps, and if that’s due to wanting to use a free account for building and sideloading apps found somewhere else, then that may be outside the scope of this developer forum.