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.

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.

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?

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

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

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.

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.

My question: How to return a nullable [pointer] from an Objective-C method which also throws? There’s a function attribute for that: swift_error. It’s hinted at in the documentation here and described fully at https://clang.llvm.org/docs/AttributeReference.html#swift-error. The default behavior, as you have seen, is equivalent to __attribute__((swift_error(null_result))). In your case, you’ll want to use __attribute__((swift_error(nonnull_error))). Then throwing will be controlled by whether you populate the error out-parameter.

Here another thread where someone found a solution that worked for them. A quick internet search for "user rejected certificate for github.com” turns up more of the same, and the issue seems to be around something at the client end blocking something it shouldn’t. Are you behind a corporate firewall, or ad blocker, or corporate safe browsing proxy, or something like that? Is your Xcode configured to access GitHub via HTTPS, or via SSH? Are you able to clone the repo from the command line (using git clone) via either of those protocols?

Building and running on macOS 12.3.1, base SDK 10.14 It’s because your app is built with an old SDK version. You’re seeing a clever compatibility trick to sidestep bugs in some (or many) older apps that checked the version number in an unsafe way. If you raise your SDK to the current version, then you should get the true version string. Here’s one article that explains it pretty well: https://eclecticlight.co/2020/07/06/why-big-sur-wont-stumble-over-version-numbers/

I battled this too, and lost; see this thread. (Takeaway: it’s a bug.) You could mention my Feedback ID in your own bug report. It may help the  folks to keep track of duplicate reports on this.

I have an engineering background, but very very new to iOS development. Welcome! Unfortunately it’s not good news on this issue... our organization built has a dependency to UIremotekeyboardwindow, which i'm told, will no longer be supported after iOS 16 is released. Actually that was never a supported API and should never have been used by apps in the first place. It’s an internal implementation detail of the OS that people have figured out how to exploit over the years for various purposes. But since it’s not a public API, it could get changed any time and break apps that use it. Apps should use only public, documented APIs. What exactly did the existing code accomplish via this API? There may, or may not, be a way to do it via public APIs. should we expect all apps that use this class to crash once a phone is updated to iOS 16? It depends on each app. If designed to fail gracefully (and simply lose the relevant functionality) then great. Or if never designed to handle the case of it no longer working on future OS versions, then not so great. See this thread for a longer discussion of a similar issue. The solution may even be relevant to your situation.