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

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)

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.

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.

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.

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.

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

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

What platform? And just curious, who are you trying to protect against: a bad actor who quietly compromises a victim’s device to install their own root cert? Or a tech-savvy device owner who wants to use something like mitmproxy to inspect your app’s traffic? If the latter, then why?

Apps like that aren’t really a thing on iOS. You may find them on other mobile platforms, but not here. Consider this: such a tool would be useful only if you could get the name of each process executable (rather than, say, just a process ID). And getting that information would be a massive privacy fail. Your app would be able to infer (and make fingerprints of, and sell to advertisers) a list of what other apps the user has installed on their device. That sort of abuse is most definitely not supported by any API on this platform. BTW, check out On Free Memory for discussion of why even aggregated memory information isn’t as useful as it sounds.

If nobody has an answer about an API for this, you can at least get the certs during development from here: Available trusted root certificates for Apple operating systems. Then you could bake their fingerprints into your app. Unfortunately those pages don’t provide an easily digestible format such as CSV.

You should consider the closure to be escaping. The syntax for declaring an enum associated value isn’t quite the same as an initializer so there’s nowhere to put the @escaping keyword, but the effect is the same: the closure is retained by the enum value and may be called later. If you do this in a class context and implicitly reference self then you’ll get the familiar warning about that: class Foo: NSObject { func foo() {         _ = Operation.opA {             print(description) // ERROR: Implicit use of 'self' in closure; use 'self.' to make capture semantics explicit         }     } }

See the accepted answers in this thread and this thread.

And maybe include the suggestion that the data behind Available trusted root certificates for Apple operating systems be made available in machine-readable form, if my suggestion about that proves useful.

I think @eskimo actually meant to say: But, just to be clear, MetricKit does NOT provide real-time cellular signal strength.