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?

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.

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.

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.

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.

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.

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.

if the calling code was already on the main thread, and the function they called also called the DispatchQueue.main.async, it seems like that call was delayed/not-called, and being requeued on the run loop for the next call. That is correct behavior, not a bug. No matter what queue you are currently executing on, the async() call just adds your closure to the target queue and returns. Is there any better way to debug this? No magic bullet here, but I’ve found this function is handy for verifying assumptions about what queue you are executing on: dispatchPrecondition(condition: .onQueue(.main)) // or whatever queue you want to check

Your NSExceptionAllowsInsecureHTTPLoads key is in the wrong place. It needs to be a child of the domain key (your redacted red item) rather than a child of the Exception Domains key which is one level up. It should look like the last screenshot shown on this page. Tip: In Xcode’s property list editor, to add a key to a dictionary, make sure to expand the dictionary (so the disclosure chevron points down) before you click the ⊕ button. That will create the new key as a child of the current row. Otherwise (if not expanded) it will add the new key as a sibling of the current row, which may have happened in your case.

That will work. Elsewhere the documentation makes it more explicit: WeatherKit requires iOS 16, iPadOS 16, macOS 13, tvOS 16, or watchOS 9. REST APIs can be used for websites and other platforms. Older versions of iOS would fall under “other platforms”.

Scratch that. Now I’m going with the theory (commented in your other thread) that your chart is correct but actually showing weather data from somewhere else. If the longitude were flipped from 119ºW to 119ºE then it would designate a place with the same season and the same daily sun cycle, just shifted about 8 hours behind. This could explain all the weird results you’re seeing.

How are you formatting those time strings? You would need to use a date formatter with the time zone set correctly. WeatherKit uses the good old Date type and (in my testing here) they are correct, whether I view them in the debugger or print them using a date formatter set to my time zone.

Are you sure WeatherKit doesn’t match the Weather app in the iOS 16 beta? I just tested and got perfect agreement between WeatherKit and the app. Then of course I’m seeing minor disagreement with the iOS 15 Weather app, which is to be expected since the underlying data source is different.

I think the wind API should be interpreted as documented, and you’re just seeing bad data as mentioned in your other post. In simple testing here, I get perfect agreement between the iOS 16 Weather app and WeatherKit for various test locations (including Penticton, BC), but disagreement between those and the iOS 15 Weather app. In particular the wind direction there is roughly backwards between the two.

Actually according to the documentation both direction and compassDirection should refer to the direction the wind is coming from. Respectively, Direction the wind is coming from in degrees, with true north at 0 and progressing clockwise from north. ...and: General indicator of wind direction, often referred to as “due north”, “due south”, etc. Refers to the direction the wind is coming from, for instance, a north wind blows from north to south. In the example Wind object: WeatherKit.Wind(compassDirection: East, direction: 90.0 °, speed: 7.09 km/h, gust: Optional(18.18 km/h)) It’s indicating “wind out of the east” (as a simplified weather report may phrase it), specifically from compass direction 90º, which is due east. A wind blowing from due west would be blowing from a direction of 270º.