Post

Replies

Boosts

Views

Activity

Submit bug reports or not?
Over the years I have submitted a variety of bug reports to Apple. Some for annoyance bugs big and small but also a number of (for me) critical issues. Responses to all of these I received were in the range of "no response...", "yep we know", "please verify a fix in Xcode version such and so" etc. and also requests to build example code if the issue persists. I am starting to wonder if it is worth it to spend time to provide a bug report at all. Responses, if I get them, come in many many moons after I reported them - in many cases I am no longer on that version of Xcode, that library or in that part of the code. I have built example/test code in the past but that can take a good amount of time, which I don't really have. Additionally, I have provided test code that than has no further follow up/answer from Apple - I guess I just chucked a bunch of my time on the window on that one. Bug reports and the time spent on them are purely for Apple's benefit and maaaaybe in the very long run for our benefit. With every new Xcode release, things are fixed but many more new problems and changes are introduced. I know I am just a little potato to Apple and don't expect VIP treatment - but I don't want to spend that time nor have any hope on some smallish answer on the issue reported. So what is your opinion, keep providing bug reports or nah save yer time already.
3
0
854
Feb ’23
Xcode hold the fold?
Is there any way that code folding can be persistent between coding sessions? Yes, I know I can fold all methods with a shortcut - not looking for that. I like the methods I previously folded stay that way until I unfold them myself. Folding was introduced in Xcode 8 I believe, now we're at 13. Is about time it is able to save folding state, no?
3
0
1.1k
May ’22
Reading tag text CoreNFC error 92
I've written a small test app to bring my understanding of CoreNFC up to snuff. The app just reads a tag and writes a simple string to it. The app has NFC entitlement, NFC privacy statement as required.The app reports the tag has read/write capability.When I read the tag message with NXP's 'TagWriter' app it states "This is a test" + current date. This is what I expect. When I read it with the app I wrote I get two chinese characters obscuring the first character i.e. capital 'T'. E.g. "<chinese>his is a test 2019-12-18 03:27:08". This is the method I use to extract the text:func printNDEF(_ messages:[NFCNDEFMessage]) { DispatchQueue.main.async { for message in messages { for record in message.records { if let string = String(data: record.payload, encoding: .utf16) { print("MSG:\(string)") } } } } }So please enlighten me what I do wrong here? Why is that first 'T' replaced by chinese whereas the NXP app does this correctly?Then when I write to the tag the same string but with updated date/time. I get an error '92', LLDB reports; [CoreNFC] 00000002 83870f00 -[NFCNDEFReaderSession setAlertMessage:]:92 This is the method I use:func doWriteTest(_ session: NFCNDEFReaderSession, tag:NFCNDEFTag) { print("Write Test") guard let record = NFCNDEFPayload.wellKnownTypeTextPayload(string: " This is a test \(Date())", locale: .current) else { return } let myMessage = NFCNDEFMessage.init(records: [record]) tag.writeNDEF(myMessage) { (error) in if let error = error { session.alertMessage = "Write NDEF message fail: \(error)" } else { session.alertMessage = "Write NDEF message successful!" } } }The method reports it was successful and the tag is indeed written to with the new date/time. No idea why I get error 92 and what it means. Note that I do have a session alert message, the NFC session is started with this:func createNFCSession() { session = NFCNDEFReaderSession(delegate: self, queue: nil, invalidateAfterFirstRead: false) session?.alertMessage = "Hold phone near tag." session?.begin() }Any help is much appreciated.
0
0
1.2k
Dec ’19