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.

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.

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.

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?

In your actual code, are you formatting a variable, or is it an integer literal as in the example? Assuming it’s a variable, I’d suspect not a localization bug but a change in behavior causing the variable to have a garbage value that gets formatted. Does this issue occur when (1) you run a Release build locally; and (2) when you submit a Debug build to TestFlight?

You said the quiet part out loud. Indeed “iPadOS” is mostly a marketing gimmick. On the technical side nothing really changed and there’s still a single iOS SDK. If you have separate build targets for iPad and iPhone (“and iPod touch!” says a lonely voice from the back row) then of course you can define your own compile-time condition for that in each target. But for App Store distribution it still needs to be a single build for all iOS devices, so building different binaries for different idioms wouldn’t be useful.

In general[1], there’s no public API to discover anything about other apps installed on the device. That would be a big privacy fail. There’s actually a tiny crack in the armor with the UIApplication.canOpenURL function, but it wouldn’t help with what you are trying to do.