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.?

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

(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.

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.

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

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

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.

//serialize the lambada //deserialize the lambada and use it Are you referring to the Java technique of serializing lambdas, like what’s described at https://www.baeldung.com/java-serialize-lambda ? Swift has no equivalent feature.

Do you have an Apple (not 3rd party) crash report for this? See the note about that from @eskimo in your other thread. If this 3rd party report happens to be accurate, then you’ll need to take it up with the vendor of the closed-source SDK you are using. But it would be unexpected for anyone to actually be calling setDefaultFormatterBehavior and extra unexpected for it to crash, so I’d suspect the crash report isn’t accurate. The crash may still be caused by that SDK but you need an Apple crash report to be sure.

Or the issue is that the bezels don’t match any iPad device. The aspect ratio for both is longer than any known iPad so it does sort of look like an iPhone. The one for iPad Pro (2nd generation) is way off: that model has a thick top bezel and square corners, as shown in the tab thumbnail above it. The iPad Pro (6th generation) has thin bezels and round corners so it matches a little better, but note one of your shots has both square and round corners. Your best bet is to regenerate all these screenshots using the correct simulator, and include the device bezels when capturing the screenshots.

And by the way, this list on 14.3 is not showing enough simulators. You can create more simulators yourself. Click Manage Run Destinations at the bottom of that list, then switch to the Simulators tab and hit the + button at the bottom. It looks like the oldest simulator supported is iOS 13.7, but this may be sufficient to reproduce the problem. BTW, the App Store usage chart shows very few people are still on iOS 13. And as you can see it’s a pain to support such old versions. Just something to think about.

Can you give details of the bug affecting only 16.3? This may be helpful to someone else.

As for iOS 13 support, also consider this: all devices that can run iOS 13 can also run iOS 14 and even iOS 15. So if you are not also supporting iOS 12 or earlier, then there’s no good reason to set your minimum target platform to 13 or 14. Anybody with an iOS 13-compatible device should be running iOS 15 or higher.

There’s no documented setting for that. Imagine if there were: many apps would use it and thus defeat the purpose of the offload feature. For now your best bet is to advise the user to disable the global offload feature, with a detailed explanation of the motivation for doing so. But it’s still the user's choice. You could also file a Feedback requesting support for this, such as a hard-to-get entitlement for apps like yours.

Does this thread describe what you are seeing?