And remember that your bundle is read-only so, as Scott suggested, you want to open it with SQLITE_OPEN_READONLY. One more thing I just remembered (from doing this years ago)... you may also need to do this when you call sqlite3_open_v2: add the SQLITE_OPEN_URI flag pass the path as a file: URI rather than a raw path append query parameter ?immutable=1 to that URI This makes SQLite work correctly when the file is on a read-only disk, which is basically what your app bundle is. See these pages for more detail: https://www.sqlite.org/c3ref/open.html https://www.sqlite.org/uri.html#coreqp

See a similar finding in this thread: WeatherKit REST API new columns for CurrentWeather. Basically, if it’s not documented, it doesn’t exist. Just make sure your parsing logic safely ignores any objects or fields it doesn’t recognize.

let fileURL = try! FileManager.default.url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: false).appendingPathComponent("TurMer.sqlite”) Once this line is executed, it tells me that everything is correct. Not quite correct. That line returns a URL for where that file would be located (within your Documents directory) whether it exists or not. It doesn’t check if that a file actually exists at that location. In this case, no such file exists. When your app first starts, the Documents directory is empty. See @eskimo’s reply above for finding your database file within your app bundle, which is totally separate from the Documents directory. if sqlite3_open(fileURL.path, &BaseDatos) != SQLITE_OK In this line we have opened the database. Everything is correct, it tells me that the database exists Not quite. Note the documentation for sqlite3_open says that the database will be created if it doesn’t already exist. So this actually creates and opens an empty database. That’s why the subsequent query fails. In general, don’t use sqlite3_open in new code. You should switch to sqlite3_open_v2 which gives you better control over its behavior. Use the flag SQLITE_OPEN_READONLY (since you said earlier that your database is read-only) or use SQLITE_OPEN_READWRITE if desired. This will cause sqlite3_open_v2 to fail if the file doesn’t already exist, which would have alerted you to the problem earlier.

Crashing Xcode itself is definitely worth submitting a Feedback report. And of course let the crash reporter submit the crash report to Apple when it offers to do so.

Are you Remember that this forum is a community of developers, not an official communication channel to Apple. going to [do something] in the future [...]? Nobody on this forum can answer questions like that. Your best bet is to file a Feedback with your requested enhancement.

Even better, you can use the concise and stylish trailing closure syntax: temp(type: "Here") { print("hey") } Also, consider keeping the callback argument label. With trailing closure syntax you don’t use it anyway, and it improves clarity if you pass a method or function name instead of a literal closure block, like this: temp(type: "Here", callback: methodOrFunctionThatPrintsHey)

That looks like output from parts of the system that aren’t your own app, so it’s almost certainly not something documented. I’d just ignore it as “log noise.”

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

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

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.

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?

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.

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

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

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