For the issue of missing spaces, is this when the system adds a small dot in front of the app name? (After installing from App Store or TestFlight.) The system will try to compress your app name to accommodate it and may remove spaces. When there’s no dot (the normal case) then the name should look the same as it did during development.

Usage description keys such as NSHomeKitUsageDescription go in your app’s Info.plist file. See here for examples of others that work the same way. Wherever that error message is coming from, it’s not well-written. Consider submitting a Feedback about that.

What’s the issue? The simulator is accurate. But note the phone has two “Display Zoom” options: Standard and Zoomed. Mismatch between these modes may be what the OP is reporting above. As for the mismatch where the device’s physical pixel resolution isn’t equal to the (Standard mode) point resolution multiplied by the scale (3.0), that’s correct. Some iPhone models slightly downscale the “logical” point coordinate system into the “native” pixel coordinate system. But you should be able to ignore this. Just test your app using both Standard and Zoomed modes on simulator models that support it.

Go to your target settings and select the Info tab. You’ll add your setting in the Custom iOS Target Properties section. In this screen the key name is rendered as Privacy - HomeKit Usage Description. Under the hood Xcode stores it as a user-defined build setting with a key of INFOPLIST_KEY_NSHomeKitUsageDescription and then copies it into the final Info.plist file at build time. You can see this key (after you add it) in the Build Settings list, but this is really more of an implementation detail.

By experiment with the Swift REPL, I’m seeing that the simulator’s ProcessInfo.processInfo.systemUptime is just a passthrough to the same property on macOS. It seems to indicate the time the Mac has been awake, as documented. But testing your code here, I’m seeing that systemUptime and every event timestamp are in sync, differing only by milliseconds as expected instead of thousands of seconds. Does this problem repro for you in a minimalist test app, in addition to your main app? And what is this “main thread clogged up somehow” condition that motivated this in the first place? Needing to debounce system click events like this is very unusual.

I looked at the profile under my development account and I can see the HomeKit entitlement Do you mean you see that capability enabled in your App ID, or you mean you have a manually-created provisioning profile and see it there? Is the app using a manual provisioning profile or one that Xcode manages for you? (The kind not listed in your account online.) I have HomeKit enabled in the .entitlements file Did you add the HomeKit capability via Xcode’s Signing & Capabilities screen, or by manually editing the entitlement file? Just trying to figure out what may be different from the standard automated behavior, if any.

Wait, is the error message from just trying to build in Xcode, or is it when trying to upload an archived build to App Store Connect? I assumed the latter since it does sound like the kind of messages you can get upon a failed upload. Either way, does the issue repro if you create a new empty app and perform the steps to add HomeKit? And if it’s when trying to upload, does the organizer’s Validate feature produce the same error, or does Validate run clean and it fails only when trying a real upload?

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.

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

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

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.

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

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.

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.