Please see this thread for an explanation of what’s happening. Note that this isn’t specific to TestFlight. Your bundle version is getting changed when you upload to the build to App Store Connect, so it would be the same for both TestFlight and for release on the App Store.

Calling sysctl() and sysctlbyname() in an iOS app is fine. However, certain entries return EPERM to indicate that Apple has blocked them. I don’t know where those may be documented, and the set of blocked ones has changed over time, so you’ll just need to experiment and see what works. And it’s best to carefully test with each new iOS release.

i have an iphone SE earlier version If you mean you have a first generation iPhone SE (released in 2016), it’s not compatible with iOS 16. The official compatibility list is near the bottom of this page.

As per Apple beta 4 release notes UIKit UIDevice orientation issue is been fixed. Fixed: Attempting to set an orientation on UIDevice via setValue:forKey: isn’t supported and no longer works. (93367651) i am not sure why its not working for me. It’s not going to work. Unfortunately the release note could be worded a bit more clearly. Here’s how to understand it: “It was a bug that this setValue:forKey: technique ever had an effect. It should never have been used by any apps. This behavior has now been fixed so that the setValue:forKey: technique no longer has an effect." All those sites, articles, posts, gists, etc., that document this setValue:forKey: technique... they are wrong and always were. See also this thread where @eskimo declared it unsupported, years ago.

We are developed app under "Apple Developer Program as an organization account" and [something went wrong] Aha, maybe an issue with your developer program role. If I log into my personal account, then the entitlement request page works. But if I log into my company’s account where I hold the Developer role, then the same link leads to a “you don’t have permission for this” page. So I’m guessing the request needs to be submitted by an Admin or possibly App Manager.

I read that at some point you could do it with Core Telephony but not anymore. You could do it by exploiting a security vulnerability, which Apple eventually fixed. There never was a documented, supported way. If Apple is not allowing that, I'm going to need documentation or something official to back me up You are required to prove a negative? There’s no documented API for this functionality because it doesn’t exist, and lack of documented API for something should be interpreted as implying that it’s not supported. But if it helps, there are some fairly recent forum replies in various threads from  people confirming all this.

Does this occur only on iOS 16? See this thread for more on that. Actually, see that thread either way. There’s valuable advice from @eskimo in there. Is it possible to use the UUID (even if apple doesn't like it) ? If you mean the old uniqueIdentifier property, then nope, it’s dead and buried. There isn’t even a documented entitlement you could request to make it work again.

I implemented "com.apple.developer.device-information.user-assigned-device-name" on app, it's don't work. Provisioning profile "iOS Team Provisioning Profile: com.yourdomain.yourapp" doesn't include the com.apple.developer.device-information.user-assigned-device-name entitlement Just to clarify, are you saying you applied for the entitlement, and received approval, and verified the entitlement is now present in your app ID and provisioning profile, and still got that error message? a lot of Apps to used on "UIDevice.current.name" on app. A question toward @eskimo that isn’t covered in the new doc: is this one of those features that still works the old way for existing apps built with an older SDK? Or will all existing apps get the new behavior when running on iOS 16?

Here’s a problem: // OUTPUT: status: 0 (notDetermined) At this point the user has not yet authorized you to access their location, so CNCopyCurrentNetworkInfo won’t work, as documented. (I’m assuming your app doesn’t happen to meet one of the other requirements that would allow it to work.) This first call to locationManager(_:didChangeAuthorization:) may just be the result of creating your CLLocationManager object, where it helpfully informs you what the initial authorization status is. You need to wait for the user to actually authorize the location access (via the prompt presented by requestAlwaysAuthorization) which will then call your locationManager(_:didChangeAuthorization:) again with the updated status. After that happens, CNCopyCurrentNetworkInfo should work as expected.

Actually I thought this had been resolved in The Present™, but it seems the timeline has been altered, and we all know from sci-fi how dangerous that can be. ;-) There was a post a few days ago from an  person announcing the URL of a page to request the entitlement. But that post has mysteriously disappeared, even though the linked page is still live. So I guess we can infer that last week’s Present is now this week’s Future.

What is the most straightforward official apple API to test it out See CNCopyCurrentNetworkInfo() (link) and NEHotspotNetwork.fetchCurrent() (link). In particular, note the requirements listed in the first linked page. Have you confirmed at least one of them is satisfied? Usually this means the user needs to give authorization to access their location.  there is absence of a switch next to Access WiFi Information. Is it expected? Yes. If an entitlement or capability is listed there, then you have it.

Crashing in a strlen-like function sounds like the string may not be null-terminated. That would be a bug (since the documentation for es_string_token_t explicitly says the string is null-terminated) but something to keep in mind. Assuming this remains impossible to repro locally, any chance you could (say) sanity-check or log the value of length? Or just call strlen() directly on the string pointer first and see if that crashes with the same frequency as the current String initializer.

If you are asking if this is expected behavior, then yes it is. If you are asking why this is, then see here.

See this thread for more on this issue. Basically you’re seeing the new behavior for iOS 16 (protecting the privacy of the device name) and Apple has announced there is an entitlement to get around it, but they don’t seem to have announced yet how to actually get that entitlement.

Nothing has changed. There is still no public API to get cellular signal strength. Exactly why do you want this?