Post

Replies

Boosts

Views

Activity

Reply to Network Framework
To be honest, what I (and others) have wanted is concurrency in NWConnection I've provided that for myself, with suggestions from this Forum, with the following: extension NWConnection { func asyncSend(data: Data?) async throws { try await withCheckedThrowingContinuation { (continuation: CheckedContinuation<Void, Error>) in send(content: data, completion: .contentProcessed { error in if let error { continuation.resume(throwing: error) } else { continuation.resume(returning: ()) } }) } } func asyncReceive(length: Int) async throws -> Data { try await withCheckedThrowingContinuation { continuation in receive(minimumIncompleteLength: length, maximumLength: length) { data, _, connectionEnded, error in if connectionEnded { logger.log("←→ connection did end") continuation.resume(throwing: NWError.posix(.ECONNRESET)) } else if let error { continuation.resume(throwing: error) } else { continuation.resume(returning: data ?? Data(repeating: 0, count: 4)) } } } } } The significantly increased power and sophistication in NetworkConnection is welcome but my app's networking (with the above Extension) works from Monterey onwards. I will file a request in Feedback Assistant .. in fact, I'll file two! One to enhance NWConnection to support async and the other to have NetworkConnection operate in current, and older, systems. [ FB17963806 ]
Jun ’25
Reply to Network Framework
As often happens, writing a question drove me to find my own answer. In this case, I wrote a sample using the new class "NetworkConnection" and (a) the documentation shows up in Xcode and (b) the new capabilities are not available before xOS 26.
Jun ’25
Reply to Differences between SwiftUI in Monterey and Sequoia
Thanks for those ideas. Now for a harder case, in which I need to do something of the form: var body: some Scene { if #available(macOS 13.0, *) { WindowGroup { AppView() } .defaultSize(CGSize(width: w, height :h)) .defaultPosition(UnitPoint(x: x, y: y)) } else { WindowGroup { AppView() } } } A SceneBuilder doesn't accept a control flow statement in its closure (like View does - your example earlier) var body: some Scene { WindowGroup { AppView() } if #available(macOS 13.0, *) { .defaultSize(CGSize(width: w, height :h)) .defaultPosition(UnitPoint(x: x, y: y)) } } Were this a View I could perform the platform conditional in a View extension using a ViewModifier to but there's no SceneModifier equivalent. My high-level challenge is to write a SwiftUI app that runs in macOS from Monterey to Sequoia, hence the need to condition out features missing in earlier generations.
Topic: UI Frameworks SubTopic: SwiftUI
Jan ’25
Reply to "The application bundle does not contain an icon in ICNS format"
[quote='760083021, RamsayCons, /thread/760083, /profile/RamsayCons'] I'm confident pressing "Submit" on this will suddenly clear my mental murk [/quote] .. and it did, sort of. Just as a test, I added the CFBundleIconFile and CFBundleIconName keys to my Fonts plist so that, when it was copied into Info, those keys would show up. They did and "validation" is happy but how to do this properly?
Jul ’24
Reply to OSLog output in Xcode console ignoring OSLogIntegerFormatting?!
Good call .. I removed both IDEPreferLogStreaming and IDELogRedirectionPolicy and logging appears as it should. A whisper of confusion remains because the culprit is IDEPreferLogStreaming. With only that set to YES the output formatting is defeated. Adding IDELogRedirectionPolicy restored correct formatting; removing both keeps formatting as it should be. .. no env vars = good .. both env vars = good only IDEPreferLogStreaming = bad
Jul ’24
Reply to OSLog output in Xcode console ignoring OSLogIntegerFormatting?!
I was logging a lot of data very fast and found a suggestion, buried in the log, to use “IDELogRedirectionPolicy=oslogToStdio” to avoid potential loss. Using that environment setting restored the desired formatting! "[guessing] .. I understand the “IDELogRedirectionPolicy” can influence how logging behaves (the 'privacy' for example) but could it be that very high rates of logging cause the logging system to save time by not doing formatting .. that kind of makes sense; the logged data is still correct, just not formatted? I see "IDELogRedirectionPolicy" is mentioned in the Xcode 15 release notes.
Jul ’24
Reply to "Enable-Private-Data" in a command line application ..
Thanks, Quinn, for the explanation; I like the "for fun" stuff .. it makes perfect sense, and is a little obvious after the fact! In passing, I'll mention finding another way of defeating (which I won't be explicit about, though it's not too hard to find). Dropping a particular plist file into a particular /Library/Preferences/.. location enables opening for a command line app (and everything else). It's not useful to me (and neither is the config profile) because I need to ask someone else, with a wider range of models of the hardware I'm working with), to run my program. I won't ask someone else to open global holes in their security .. an app-local solution which only opens for that one app and only for the duration of its execution is essential. For my immediate need, I can wrap the command line into a trivial *.app. I'll file a bug and report the FB# here ..
Topic: App & System Services SubTopic: Core OS Tags:
May ’24
Reply to "Enable-Private-Data" in a command line application ..
A minimal command line app is exhibiting the same unexpected behavior, and there's not much left to make mistakes in. Hopefully, someone will point out an appallingly simple error, else, I'll wrap this up into an FB. Source import Foundation import OSLog let loggingTest = Logger(subsystem: "com.ramsaycons", category: "LoggingTest") loggingTest.log("info: \(Bundle.main.infoDictionary!)") Info.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>OSLogPreferences</key> <dict> <key>com.ramsaycons</key> <dict> <key>DEFAULT-OPTIONS</key> <dict> <key>Enable-Private-Data</key> <true/> </dict> </dict> </dict> </dict> </plist> Xcode run output (whitespace modified for readability): info: [ "DTPlatformBuild": , "LSMinimumSystemVersion": 14.5, "DTXcode": 1540, "CFBundleSupportedPlatforms": <__NSArrayM 0x600000e58720>(MacOSX), "DTSDKName": macosx14.5, "DTCompiler": com.apple.compilers.llvm.clang.1_0, "DTXcodeBuild": 15F31d, "DTSDKBuild": 23F73, "DTPlatformName": macosx, "DTPlatformVersion": 14.5, "BuildMachineOSBuild": 23F79, "OSLogPreferences": { "com.ramsaycons" = { "DEFAULT-OPTIONS" = { "Enable-Private-Data" = 1; }; }; }] Program ended with exit code: 0 Console.app output: default 17:16:33.869184-0400 LoggingTest info: <private>
Topic: App & System Services SubTopic: Core OS Tags:
May ’24
Reply to SCN to USDZ
I may be diverting the topic "SCN to USDZ" somewhat but I performed the above action (using Xcode [15.3 beta 2] to read .scn and export .usdz) on one of my, admittedly, complex .scn files. The scene in question is entirely line segments (closed loops - actually world coastlines). The exported .usdz model bears no similarity to the .scn file -- it's just over one kilobyte, and viewed in Xcode it does open, but is "empty." I know RealityKit doesn't provide for a ".line" primitive in meshes and wonder if .usdz is similarly constrained (it seems unlikely to me, but maybe Xcode doesn't support that structure either). The .scn file is large (1.1MB) but renders instantly in QuickLook .. could it be too large to be converted (again unlikely). I'm no expert in 3D technologies and could be missing something obvious, but what the Xcode "conversion" delivers is unexpected. I'm bringing this here as I continue to explore conversions in the hope of a suggestion or two, OR being told what I'm attempting to do is not possible (and I can stop wasting time)?
Topic: Graphics & Games SubTopic: SceneKit Tags:
Feb ’24