Here's an untested idea worth a quick experiment: In a ZStack, superimpose a TextField view with .opacity(0) over a Text view. Bob Stern

I don’t know a perfect solution for allowing a user to select and copy static text in SwiftUI. If you use a TextField instead of Text, the content will be selectable, but it also will be editable,

One project is just a toy to try Catalyst. Another is a real project, which could be done via Catalyst (some minor problems) A third is a real project, which could be not be done via Catalyst, because

On iOS the idiomatic way to do this is not selecting the text, but a long-press gesture that brings up a context menu with a Copy item. —Jens

Is this a new project or one in which you already developed a lot of code? I get the impression it is new because your preceding post concerns an existing UIKit app that you want to port to Mac using

NSTextField can set both isSelectable (true) and isEditable (false). So far so good. But how to do this in iOS? I have a textField which is output only (editing makes no sense at all) but the user

iOS 15.4, macOS 12.3 When UserInterfaceIdiom = pad then UiButton.titleLabel is UILabel with UILabel.text = button title. Ok. But with UserInterfaceIdiom = mac the UiButton.titleLabel is a

replacing in: override func decodeRestorableState(with coder: NSCoder) all: languageFilter = coder.decodeObject(forKey: "languageFilter”) with: languageFilter = coder.decodeObject(of:

Have you tried using secure [de]coding? https://developer.apple.com/documentation/foundation/nssecurecoding https://developer.apple.com/documentation/foundation/nscoder/2292944-decodeobject# -ben

Xcode 13.2.1, Simulator running iOS15.2 with 13.0 as a deployment target, UIKit. I have a pretty standard configuration running an iPad in Simulator — SplitView master contains a TableView,

class ViewController: UIViewController { override func decodeRestorableState(with coder: NSCoder) { NSLog("\(#function) will super; coder \(coder); allowedClasses \(String(describing:

I don’t know an exact scenario, but hacking a class name in an archive is a trivial way of substituting a malicious class type for any other type. It will negate whatever protections secure coding

Yes, I understand that writing the class name into the archive bypasses what secure coding is supposed to accomplish, though it adds a small extra hoop to jump through for a would-be

This sounds so right. But unfortunately doesn’t work for __NSCFConstantString, which returns that, and not NSString. I haven’t yet tried on other classes, but most of the time it’ll be a

I think you’re Doing It Wrong™. Your solution is effectively disabling secure coding, which solves your run-time error, but leaves you with the exact security vulnerability that secure coding is

In respect of this particular issue, I think if you call `classForCoder` rather than `class` on the object of interest, you'll get the portable class name ("NSString") you're looking for. -ben

Well, I figured out a solution, though I’m not sure — it seems slightly smelly, even though it looks neat from the outside and is easy to use. Would appreciate any feedback. Basically, I walk up

Hi Glenn, This seemed like a perfectly fine idea in this case, so I tried it. Now I get a new message spewed to the log: 2022-02-24 20:50:13.158117+1100 GCSimpleContainers[26354:31119213] [general]

A suggestion? Archive the class name as a part of your archiving process, then get the class instance by NSClassFromString. You can then use that as the parameter for decodeObjectOfClass:forKey:. It's

Hi all, I was working on some demo code investigating the use of secure archiving, since I guess we all have to adopt that if we can. I have a simple container class (a linked list) that I decided to