Does the device self-identify via any of its services? See if it implements the Device Information Service (which defines various characteristics including serial number) or maybe it exposes similar information in a custom service. Otherwise, there may be no good solution.

See this thread for some history. This part from an  engineer probably isn’t what you are hoping to hear: Battery level reporting is as accurate as it is intended to be.

There is a local variable [...] to store which alert action the user chose. Do you mean it’s a local variable on the caller’s stack, or is it actually a global/static variable, or something else? How does the alert presenting function access it? If it’s currently a local stack variable and is captured by the async block, can you test by changing it to a global/static?

Start reading here: iOS Background Execution Limits.

There’s always a lag of a few hours or days before App Store gets the memo. Just need to be patient.

The documentation isn’t explicit about what “send” means but I think it does imply that the operation is asynchronous: This [return] value is [...] false if the update isn’t successfully sent because the underlying transmit queue is full. From this I infer that it just attempts to add the data to a fixed-size transmit buffer, while the actual transmission over the air via the Bluetooth stack happens later.

Well, I suppose that could work but it doesn’t exactly improve readability. :wink: If this landed in the inbox of peer code reviews at my day job here, I’d ask them to redo it using a struct implementing Encodable, a JSONEncoder, and either string modifier addingPercentEncoding(withAllowedCharacters:) or one of the URL APIs that does percent encoding automatically.

For me, Xcode 16 is showing the match count in the find bar when I hit ⌘E when the find bar is already open, or when I hit ⌘F to open the find bar after ⌘E. Still need to hit ⌘F either way to get keyboard focus into the find bar, however. But note a huge advantage of ⌘E over ⌘C ⌘F ⌘V is that it puts your search text in the system’s find pasteboard, which is separate from the general pasteboard. So it won’t clobber regular code or text that you are editing via copy and paste.

I would like to be able to select the text I’m looking for, then use a shortcut that would immediately search for the selected text in the current editor. If you can get by on two shortcuts: ⌘ E (menu command Find → Use Selection for Find), then ⌘ G (menu command Find → Find Next)

If you post more info about your high-level goal here, I should be able to offer more insight into how to proceed. That format string is actually URL-encoded JSON: {"sign":null,"company":"兄弟海洋科技有限公司","businessNo":null,"scene":null,"interviewCode":"767676"} Even without the URL encoding, there are no %@ placeholders that the string initializer expects. So if the high-level goal is to generate this JSON with certain parameters inserted at run time, and then URL-encode it, there are far better techniques for doing so.

Definitely a bug, since your code actually crashes the Swift REPL: Welcome to Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1). Type :help for assistance. 1> import Foundation 2. class Claude { 3. var fieldBeingEdited = 0 4. let kTag = 0 5. 6. @objc func keyboardDone(_ sender : NSObject) { 7. DispatchQueue.main.async { [self] () -> Void in 8. switch fieldBeingEdited { 9. case kTag : break 10. default : break 11. } 12. } 13. } 14. } LLDB diagnostics will be written to /var/folders/z3/53rv5j6x0697yjhjh890hnnr0000gr/T/diagnostics-18fbd0 Please include the directory content when filing a bug report PLEASE submit a bug report to https://developer.apple.com/bug-reporting/ and include the crash backtrace. [ ... stack trace omitted ... ] If I remove the case kTag line, then it has no error.

So I just want to get confirmation from Apple if this will be a new update for UI events or just an issue that will be fix in upcoming iOS versions. I don’t see this mentioned in any iOS 18.* release notes. So there are a few possibilities: It’s a newly introduced bug. Consider submitting a bug report via Feedback Assistant. (And post the bug number here, just for the record.) It’s a fix of a previous bug, but they forgot to mention it in the release notes. Consider submitting a Feedback on this. It’s merely a change from old valid behavior to new valid behavior, with no release notes required. I vote for the 3rd interpretation. Unless the UIKit documentation already covers the relative ordering of these calls (thus establishing an API contract in this area) then either order is plausible. Is the view going to disappear? Yes. Did a new tab get selected? Yes.

I suspect @Climber1987Muc is referring to the issue of the app settings not appearing at all in the system settings on iOS simulator version 18.2 and later; see this thread for one discussion.

You can actually type other deployment targets (such as 17.0 or 17.5) directly into the build settings. Unfortunately this seems to confuse the simplified deployment target picker and it goes blank. I’d call that a bug, or least an unhelpful UI design. But the underlying setting will still be what you typed in.

Search the forum for “fixed format dates” and you’ll get a few hits explaining the issue and a couple ways to fix it. Among the available solutions, I recommend just switching to ISO8601DateFormatter instead of trying to use the original localization-focused DateFormatter.