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. ☹️

If you are looking for a feature of the App Store to designate an app update as “required” (meaning the OS would automatically block your old versions from running or automatically install the update) then there isn’t one. The user always has control over app updates. Of course you can implement your own app logic to (for example) query a web API to see if a new version is available, and then degrade your app's functionality, such as displaying a message inviting them to update. But think really hard before doing this: it’s unexpected behavior and a terrible user experience. And of course you would need to have built this version checking functionality into whatever previous version of the app the user already has. Which, since you’re asking the question, probably isn’t the case right now. It’s best to do whatever you can on your back end to keep old versions working as long as possible.

Sounds like the same issue discussed in this thread.

One could argue Finder is actually a more logical place for this. In Xcode you don’t work directly with .mobileprovision files, so they aren’t present as project files that you could click on and see in an inspector pane. They just exist as free files in a known location. And it turns out Xcode does have a feature to show details for the profile for a target, though it seems to be limited to the profile used by the current scheme’s Run build configuration. It’s a little ⓘ button in the target’s Signing & Capabilities tab.

The benefit is for you (the developer) not having to support all those old versions, and to be able to use new and improved APIs introduced in newer versions. Do you actually have test devices running all those old versions? That’s a lot to manage. The simulator is great too, but the current Xcode supports simulator versions only back to iOS 12.4. If a user reports a bug on affecting only an older version on a specific device model that you don’t have and don’t have a simulator for, what do you do? And if you release an update, how broadly can you test it? If you want to use newer functionality, do you clutter your code with version-specific conditional logic to make it work? That can get tedious and error-prone. And in cases where newer APIs improve on older APIs (such as, for example, the fantastic diffable data sources for tables and collection views, added in iOS 13) then being unable to use them can be deeply frustrating. And in the Apple world, users adopt newer iOS versions much faster than Android, if you’re familiar with that world. So you’re likely to find the proportion of users on iOS versions 9, 10, 11, 12, and even 13 to be very small (see charts here) and arguably not worth the effort. Our poor Android counterparts have a much tougher time supporting all the OS versions still in wide use on devices of similar vintage.

Not in Xcode, but actually macOS Finder can display them in a friendly format via Quick Look.