Our project files are sorted alphabetically. It’s not clear what you mean: are you just manually sorting the files in your target’s Build Phases → Compile Sources list in Xcode? By my experiment in 14.2, hand sorting that list still works correctly and persists as expected. Or are you modifying the underlying .pbxproj file outside of Xcode? I imagine Apple’s response would be something like: don’t do that because it’s not supported. I suspect the latter since your screenshot shows the PBXBuildFile section of the project file. That’s not the section that defines the order of the user-visible Compile Sources list. If you don’t modify the project file outside of Xcode, do you still experience unwanted changes to the file every time it is opened?

do we need to update our "Minimum Deployment Target" to 16.1? Definitely not. You need to use Xcode 14.1 or later but can still target as far back as iOS 11.

Here’s a good WWDC presentation for getting started: Developing CarPlay Systems, Part 1.

Interesting utility there. My first advice would be to just remove it. Does your project actually suffer the sort of merge conflicts that xUnique claims to address? It mentions conflicts due to the same file being added on different machines, but that sounds like a larger process problem. There are definitely lots of large teams and large apps that get by fine using robust branching strategies and plain old Xcode. Or if you do still need it, then you probably need to modify xUnique to sort the way Xcode now does. Maybe see if the original author still plans to maintain it even after all these years.

It’s still confusing to figure out exactly what you’re doing. I'm assuming my app is actually supposed to be on the simulator You need to run the app on either the simulator or on real devices. You are the developer of the app, right? So you have the source code and can build it in Xcode? Then from Xcode you should be able to launch the app to run on the simulator or on a connected iPhone or iPad. Then you can operate the app just like a real user until you get to the screens you want to capture pictures of. so that I don't have to go through safari to access it. What does that mean exactly? What URL do you enter into Safari? how do I take my app from my app store connect page and make sure it is on the Xcode simulator You don’t get anything from App Store Connect. You are the one supplying the app and the screenshots to App Store Connect. Xcode does the uploading of the app itself, and you generate the screenshots and upload them via the App Store Connect web interface. Or... are you developing your app using a 3rd party development tool (not Xcode)? That could have a different workflow for launching the app in the simulator. If so, please clarify what you are using and maybe someone will have some advice.

Seems to be connected to your Mac’s keyboard mapping. That’s a U+00AC NOT SIGN character (in Unicode terms) which is mapped to Option+L on the U.S. English keyboard layout. And I see that Option+L is how you type the @ sign on the German keyboard layout. Trying typing Shift+2 which is how to get the @ sign on U.S. English. Could be a bug, or maybe there’s a setting to control this. The simulator does have a menu option for Use the Same Keyboard Language as macOS.

I’m not seeing any change. The little square next to Sort by: Newest (instead of the usual down arrow) suggests your browser is using the wrong font for some reason, rather than being a deliberate change. I’m seeing the usual correct font everywhere in Safari 16.3 on macOS 13.2.1. Ha... after I posted that reply, then when returning to the main page I got the incorrect font too as shown in the picture. Then after logging out and back in, the fonts are correct again. Maybe just a sporadic server issue.

Just to manage expectations: Apple often tends to not document such details. And of course they are free to change such implementation details across OS releases or under different operating conditions. The public API gives an app what it needs at the moment: each location result has an associated accuracy, and your app can measure their rate. If your app can’t function properly with insufficiently accurate or insufficiently frequent updates, then it’s best to degrade gracefully at run time based on the actual behavior, rather than trying to “pre flight” it based on assumptions made during development. I am hoping that the newest iPhones can provide a faster update rate. And who knows, maybe the next iPhone will trade off for power efficiency and give you a slower update rate. (Back to managing expectations.)

See this thread for some discussion of date handling in WeatherKit.

Start here: TN3111 - iOS Wi-Fi API overview.

Are you certain the actual date is changing, or just the representation generated by the description property? The creation date attribute is a CFDate (equivalent to NSDate and Swift Date) so it has no concept of time zone or region or format. Do you have an example where description strings generated under different regions or time formats actually represent different creation dates for the same keychain item? BTW, don’t use the description property in your user interface; it’s just for developer-facing things like debugging and logging. Make sure to use a suitable NSDateFormatter / DateFormatter whenever showing a date in the user interface.

launching Xcode 14.3 in Rosetta is no longer allowed. Does this include running app processes in x86_64 arch? They actually added an “official” way to do that, via new menu command Product → Destination → Destination Architectures → Show Rosetta Destinations or Show Both. If you set your destination as a Rosetta simulator explicitly this way, does it still crash?

I keep getting Thread 1: Fatal error: Couldn't parse Launchdata.json as Array: Is there a 2nd line of detail in that error message? Looks like your code is trying to output it, but I don’t know how fatalError handles line breaks. When you are able to see what the caught error is then the problem will be more clear. But moving on to what it will actually tell you: that’s not valid JSON because it’s missing commas between the key/value pairs.

This is a known issue; see thread Bug in forum handling of feedback IDs.

You may want to file a Feedback on those questionable names before they get locked in and documented. With standard  verbosity and attention to detail I’d expect something like cloudCoverLowAltitude or cloudCoverAtLowAltitude. Definitely no Pct on the end. The existing cloudCover property shows that “cover” implies a fraction from 0 to 1. (And strictly speaking, the documentation shouldn’t describe cloudCover as a “percentage.”)