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.

Do you mean you updated the App Privacy section in App Store Connect? That only updates the “nutrition label” shown in your App Store listing. You still need to implement any actual data collection logic within your app yourself.

Still not sure I understand the objective. Your app is for tech-savvy insiders, and for that audience it’s fine to tell them to update to a newer app version if the server certificate gets changed and no longer matches the one pinned in the app? That’s fine I guess. Given this, a lower-effort solution can be simply to notify the user whenever an SSL failure happens (the -1200 code) and remind them to update to the newest app version if available. You can check that error code in the Error object thrown (if using await) or passed to the completion handler of your URL session task call. The real type is NSError which has a code value you can check. It appears all SSL errors get reported as NSURLErrorSecureConnectionFailed (-1200). I just tried with https://expired.badssl.com and with a bad pinning setup and got the same -1200 for each. If this is sufficient for your needs, great. Or if you really really need to differentiate between types of SSL errors, then implement that delegate method with your own custom logic to inspect the server certificate. You’ll see challenge.protectionSpace.serverTrust is of type SecTrust so you’ll use the trust API functions for this. That’s an old CoreFoundation-style C API which is less fun to use from Swift, but of course it works.

First: why do you want to show the user a message specifically for the case that your server certificate expired? There’s nothing a user can do about it, and worrying about certificate configuration is the job of your server admins, not users. I’d suggest that you just allow network operations to fail as designed and inform the user with a more appropriate level of detail. Your URL task already fails with an error that provides this message suitable for display: “An SSL error has occurred and a secure connection to the server cannot be made.” Having said that, it appears cumbersome to do what you want. In the urlSession(_:didReceive:completionHandler:) delegate method, you would need to examine the certificate chain (challenge.protectionSpace.serverTrust) and essentially duplicate work that the system does by default when you subsequently tell it to performDefaultHandling. It gets messy. BTW (if I’m reading it right) your question isn’t specific to certificate pinning, whether Info.plist-based or homebrew. An expired certificate will fail the handshake regardless of the pinning situation.

Indeed UITableViewController isn’t the best choice for the layout you want. Here are some better options: Keep your existing UITableViewController but make it a child view controller embedded in a top-level container view controller, which will contain both it and the map. Change your view controller class to plain old UIViewController which will allow you to position both the map and the table view exactly where you want them. You still implement the table data source and delegate as before and there’s a bit more work (setting up an outlet and implementing a few behaviors you may need) but it’s not bad. I’d suggest trying option 1 first. It’s a cleaner architecture as it separates table-specific logic from map-specific logic. You may find it useful to put the map inside an embedded child view controller too. Then the container view controller is just responsible for coordinating between them rather than having unnecessarily deep knowledge of how they are implemented.

Has your app actually been rejected for this? That would almost certainly be a mistake by App Review. I have various apps on my phone here that behave exactly like this (location prompts in device language) as expected. (I don't think my anecdotal evidence falls under the rule of “past review performance is no guarantee of future results” because in this case it’s behavior provided by the system that is working exactly as designed.)

Slightly OT, but if your minimum platform version and architecture allow it, I’d highly recommend migrating to diffable data sources: UITableViewDiffableDataSource and friends. It can make things a lot easier and you’ll never have to implement (or even think about) those boilerplate delegate methods again.

The root cause seems to be in the interoperability of Objective-C (which MKMapItem is written in) and Swift, specifically regarding the complex rules for how initializers work. Here are two deep dives into the issue from some years ago: https://www.codeproject.com/Articles/783584/Subclassing-Objective-C-classes-in-Swift-and-the-p https://developer.apple.com/forums/thread/7817 My takeaway is that some Objective-C classes implement initializers in a way that doesn’t support what you’re trying to do. ☹️