Just be aware that if you publish on the App Store, reverting beyond Xcode 14.1 is going to be a problem sooner rather than later: Please note, starting April 2023, all iOS and iPadOS apps submitted to the App Store must be built with Xcode 14.1 and the iOS 16.1 SDK.

Not quite a condensed technical overview, but here’s one take on the topic of iOS vs iPadOS.

Start here: TN3111 - iOS Wi-Fi API overview.

What instructions are you following? It doesn’t sound correct, at least for the current version of Xcode. That File → Export command seems to be basically like Save As for the single file currently visible in the editor. If you want a single file archive (like zip or tar) of all the directories and files in your project, then you would do that outside Xcode using a suitable utility.

(Do you happen to be associated with @Dayanand_PR and this question?) Just glancing over the PAN profile, that’s a Bluetooth Classic profile (adopted over 20 years ago!) so Core Bluetooth can’t work with it. And there won’t be any additional library or SDK that can add to the capabilities of Core Bluetooth. There does seem to be PAN functionality built into iOS as a user-facing feature (for network tethering or sharing) but no API for an app to work with it.

Is PAN a GATT service? Note that Core Bluetooth supports only Bluetooth Low Energy (GATT services), or GATT over BDR/EDR.

The problem is unlikely to be specific to iOS 16.3. It’s not impossible, but you should consider more likely possibilities first. The app I created works normally on 16.2 and 16.4. Did you test with TestFlight? Did you locally test (from Xcode) with release builds, or just debug builds? See Testing a release build. the app reviewer says it doesn't work on iPad 16.3 Did the reviewer say it does work for them on 16.2 and 16.4? Or do you think they happened to test only on 16.3? And what exactly "doesn’t work” for the reviewer? Is there a crash report, missing functionality, etc.?

I think @eskimo actually meant to say: But, just to be clear, MetricKit does NOT provide real-time cellular signal strength.

And maybe include the suggestion that the data behind Available trusted root certificates for Apple operating systems be made available in machine-readable form, if my suggestion about that proves useful.

See the accepted answers in this thread and this thread.

You should consider the closure to be escaping. The syntax for declaring an enum associated value isn’t quite the same as an initializer so there’s nowhere to put the @escaping keyword, but the effect is the same: the closure is retained by the enum value and may be called later. If you do this in a class context and implicitly reference self then you’ll get the familiar warning about that: class Foo: NSObject { func foo() {         _ = Operation.opA {             print(description) // ERROR: Implicit use of 'self' in closure; use 'self.' to make capture semantics explicit         }     } }

If nobody has an answer about an API for this, you can at least get the certs during development from here: Available trusted root certificates for Apple operating systems. Then you could bake their fingerprints into your app. Unfortunately those pages don’t provide an easily digestible format such as CSV.

Apps like that aren’t really a thing on iOS. You may find them on other mobile platforms, but not here. Consider this: such a tool would be useful only if you could get the name of each process executable (rather than, say, just a process ID). And getting that information would be a massive privacy fail. Your app would be able to infer (and make fingerprints of, and sell to advertisers) a list of what other apps the user has installed on their device. That sort of abuse is most definitely not supported by any API on this platform. BTW, check out On Free Memory for discussion of why even aggregated memory information isn’t as useful as it sounds.

What platform? And just curious, who are you trying to protect against: a bad actor who quietly compromises a victim’s device to install their own root cert? Or a tech-savvy device owner who wants to use something like mitmproxy to inspect your app’s traffic? If the latter, then why?

Start here: TN3111 - iOS Wi-Fi API overview.