Hi, I'm using one ttf font that simulate a bitmap look in my app. However, macOS renders all font with anti-aliasing. On those kind of font, that introduce some artefacts. Is there a way to disable anti-aliasing or some tricks that would make like there were no anti-aliasing? Thanks.

I'm developing an audio player app that uses AVAudio​File to read PCM data from various formats. I'm experiencing severe performance issues when seeking in FLAC, while other compressed formats (M4A/AAC) work correctly. I don't intend to use them in my app, but I also tested mp3 files just by curiosity and they also have this issue. Environment: macOS 26 (Tahoe) Xcode 26.3 Apple Silicon (M1) The issue: After setting AVAudio​File​.frame​Position to a position mid-file, the subsequent call to AVAudio​File​.read(into​:frame​Count:) blocks for an unreasonable amount of time for FLAC and MP3 files. The delay scales linearly with the seek target, seeking near the beginning is fast, seeking toward the end is proportionally slower, which suggests the decoder is decoding linearly from the beginning of the file rather than using any seek index. (My app deals with “images” of Audio CDs ripped as a single long audio file.) The issue is particularly severe when reading files from an SMB network share (server on Ethernet, client on Wi-Fi with the access point ~2 meters away in line of sight). Quick Benchmark results: I tested with the same 75-minute audio content (16-bit/44.1 kHz stereo, 200,502,708 frames) encoded in five formats, seeking to the midpoint. Over SMB (Local Network, Server on Ethernet, Client on WiFi): Format | Seek + Read Time ----------|------------------ WAV | 0.007 s AIFF | 0.009 s Apple | 0.015 s Lossless | MP3 | 9.2 s FLAC | 30.2 s Locally (MacBook Air M1 SSD) : Format | Seek + Read Time ----------|------------------ WAV | 0.0005 s AIFF | 0.0004 s Apple | 0.0011 s Lossless | MP3 | 0.1958 s FLAC | 0.7528 s WAV, AIFF, and M4A all seek virtually instantly (< 15 ms). MP3 and FLAC exhibit linear-time behavior, with FLAC being the worst affected. Note that M4A (AAC) is also a compressed format that requires decoding after seeking, yet it completes in 15 ms. This rules out any inherent limitation of compressed formats, the MP4 container's packet index (stts/stco) is clearly being used for fast random access. Both MP3 (Xing/LAME TOC) and FLAC (SEEKTABLE metadata block) have their own seek mechanisms that should provide similar performance. Minimal CLI tool to reproduce: import Foundation guard CommandLine.arguments.count > 1 else { print("Usage: FLACSpeed <audio-file-path>") exit(1) } let path = CommandLine.arguments[1] let fileURL = URL(fileURLWithPath: path) do { let file = try AVAudioFile(forReading: fileURL) let format = file.processingFormat let buffer = AVAudioPCMBuffer(pcmFormat: format, frameCapacity: 8192)! let totalFrames = file.length let seekTarget = totalFrames / 2 print("File: \(fileURL.lastPathComponent)") print("Format: \(format)") print("Total frames: \(totalFrames)") print("Seeking to frame: \(seekTarget)") file.framePosition = seekTarget let start = CFAbsoluteTimeGetCurrent() try file.read(into: buffer, frameCount: 8192) let elapsed = CFAbsoluteTimeGetCurrent() - start print("Read after seek took \(elapsed) seconds") } catch { print("Error: \(error.localizedDescription)") exit(1) } Expected behavior: AVAudio​File​.read(into​:frame​Count:) after setting frame​Position should use the available seek mechanisms in FLAC and MP3 files for fast random access, as it already does for M4A (AAC). Even accounting for the fact that seek tables provide approximate (not sample-precise) positioning, the "jump to nearest index point + decode forward" approach should complete in milliseconds, not seconds. Workaround: For FLAC, I've worked around this by using libFLAC directly, which provides instant seeking via FLAC__stream​_decoder​_seek​_absolute(). libFLAC Performance: For comparison, libFLAC's FLAC__stream​_decoder​_seek​_absolute() performs the same seek + read on the same FLAC file in around 0.015, using the FLAC seek table to jump to the nearest preceding seek point, then decoding forward a small number of frames to the exact target sample.

I reposted this issue from my previous post since I have a partial solution to it, and now have a more precise question. The previous post title was too broad. My app is not Document-based, the UI is written with SwiftUI and I had to implement the 'Open Recent' menu myself. The class RecentDiscsModel has a refresh() function that forces the new opened file to be seen in the menu. Without that, the app needed to be restarted to see them. (The files were appearing in the Dock menu, however.) My problem is, that when we open this 'Open Recent' menu, it closes when the UI is updating. My app being a Disc Player, the main and unique window UI is updating every second or more through many @Published properties from my AudioDiscPlayer class. I have no idea how to prevent this issue. @main struct MyApp: App @main struct MyApp: App { @NSApplicationDelegateAdaptor(AppDelegate.self) var appDelegate @StateObject private var recentDiscsModel = RecentDiscsModel.shared var body: some Scene { Window("Player", id: "main-window") { PlayerView() } .commands { CommandGroup(replacing: .newItem) { } CommandGroup(after: .newItem) { Button("Open...") { NotificationCenter.default.post(name: .openDocumentRequested, object: nil) } .keyboardShortcut("O", modifiers: .command) if recentDiscsModel.recentDocs.isEmpty == false { Menu("Open Recent") { ForEach(NSDocumentController.shared.recentDocumentURLs, id: \.self) { url in Button(url.lastPathComponent) { global.insertDisc(at: url) } } Divider() Button("Clear Menu") { NSDocumentController.shared.clearRecentDocuments(nil) recentDiscsModel.refresh() } } } } PlayBackMenu() } } } class RecentDiscsModel: ObservableObject | The class that handles the live refresh of the 'Open Recent' menu class RecentDiscsModel: ObservableObject { static let shared = RecentDiscsModel() @Published private(set) var recentFiles: [URL] = [] private init() { refresh() } func refresh() { let newDocs = NSDocumentController.shared.recentDocumentURLs if newDocs != recentDocs { recentDocs = newDocs } } } class Globals: ObservableObject | This is the class that handling opening cueSheet file: class Globals: ObservableObject { static let shared = MCGlobals() init() {} @Published var errorMessage = "" @Published var errorDetails = "" @Published var showingErrorAlert = false func handleFileImport(result: Result<URL, Error>) { switch result { case .success(let url): guard url.startAccessingSecurityScopedResource() else { errorMessage = "Unable to access file" errorDetails = "Permission denied" showingErrorAlert = true return } defer { url.stopAccessingSecurityScopedResource() } insertDisc(at: url) case .failure(let error): errorMessage = "Failed to import file" errorDetails = error.localizedDescription showingErrorAlert = true } } func insertDisc(at url: URL, startPlayback: Bool = false) { do { try AudioDiscPlayer.shared.insertDisc(at: url, startPlayback: startPlayback) NSDocumentController.shared.noteNewRecentDocumentURL(url) } catch { let nsError = error as NSError errorMessage = nsError.localizedDescription let reason = nsError.localizedFailureReason ?? "" let recovery = nsError.localizedRecoverySuggestion ?? "" errorDetails = "\n\n\(reason)\n\n\(recovery)".trimmingCharacters(in: .whitespacesAndNewlines) showingErrorAlert = true } RecentDiscsModel.shared.refresh() } }

I've already searched extensively on Apple Developer Forums and Stack Overflow, and didn't really find what I need or I missed it. I'm developing a macOS music player app that uses cuesheet files paired with audio files. The core functionality is working, opening and playing files works without issues, but I'm struggling with implementing proper file handling features due to my limited experience with UI frameworks. The current state of my app is intentionally simple: Single window interface representing a music player with track list Opening cuesheet files changes the “disc” and updates the window Built with SwiftUI (not AppKit) Not created as a Document-Based app since the user doesn't need to edit, save, or work with multiple documents simultaneously What I Need to Implement: Open Recent menu that actually works Recent files accessible from Dock menu Opening cuesheet files from Finder Drag-and-drop cuesheet files onto app window (lower priority) Problems I've Encountered: I've tried multiple approaches but never achieved full functionality. The closest I got was an “Open Recent” menu that: Only updated after app relaunch Its drop-down kept closing while music was playing My Questions Is it possible purely in SwiftUI? Is there documentation I'm missing? I feel like I might be overcomplicating this. I'm open to alternative approaches if my current direction isn't ideal: Should I redesign as Document-Based? Since I apparently need NSDocumentController, would it be better to start with a Document-Based app template and disable unwanted features, and how? Should I mix AppKit with SwiftUI? While SwiftUI has been wonderful for my main window, it's becoming frustrating for other UI parts, especially menus. Would using AppKit for menus and keeping SwiftUI for the main interface be a reasonable approach? I thought this would be straightforward: Customize the .fileImporter with the proper logic of what to do with the files Call NSDocumentController.shared.noteNewRecentDocumentURL(url) so the Open Recent menu is created a populated with opened files. Maybe it really is that simple and I've gotten lost down a rabbit hole? UI programming is quite new to me, so I might be missing something obvious. Any guidance, code examples, or pointing me toward the right documentation would be greatly appreciated!

Hi, I have trouble changing the color of the text of Link in SwiftUI. I tried with this code: Link("https://www.mylink.com/", destination: URL(string: "https://www.mylink.com/")!) .foregroundColor(Color.green) and this code: HStack(spacing: 0) { Link("https://www.mylink.com/", destination: URL(string: "https://www.mylink.com/")!) } .foregroundColor(Color.green) The link keeps getting the accent color. EDIT: I want to add that it used to work and I think the issue came with a beta of Xcode 26. I think that was around the beta 4 or beta 5. Is it a change of the APIs or a bug?

Hey all, Ran into a fun one on macOS 26.4.1 / Xcode 26.4.1, and I think I've narrowed it down enough to be worth sharing. Symptom: HSplitView's divider drags fine, but the cursor never changes to the resize cursor on hover. Just stays as the regular arrow. The cause (in my case): the HSplitView was conditionally rendered via an outer if let: struct PlayerDetailsView: View { let theme: Theme var playerVM = PlayerViewModel.shared var body: some View { let grayscaleCM = ColorMap(table: .grayscale) ZStack { VStack(spacing: 0) { Rectangle() .fill(LinearGradient(colors: [Color.black.opacity(0.45), Color.black.opacity(0)], startPoint: .top, endPoint: .bottom)) .frame(height: 8) Spacer() Rectangle() .fill(LinearGradient(colors: [Color.black.opacity(0.45), Color.black.opacity(0)], startPoint: .bottom, endPoint: .top)) .frame(height: 8) } .allowsHitTesting(false) if let disc = playerVM.disc { HSplitView { DiscInfoView( disc: disc, theme: theme, ) .frame(minWidth: 720, alignment: .topLeading) .buttonShadow() .focusable(false) TrackListView( theme: theme, playbackSequence: playerVM.tracksInPlaybackSequence, bonusTrackStartIndex: playerVM.player.disc?.releaseMetadata?.firstBonusTrackIndex, bonusTracksTitle: playerVM.player.disc?.releaseMetadata?.bonusTracksTitle, bonusTracksDisabled: playerVM.bonusTracksDisabled, onBonusIconTap: { playerVM.player.bonusTracksDisabled.toggle() } ) .frame(minWidth: 512) .focusable(false) } } } .background( LinearGradient( colors: [ grayscaleCM.color(for: 0.23), grayscaleCM.color(for: 0.17), ], startPoint: .top, endPoint: .bottom ) ) } } The fix: move the conditional inside the HSplitView, so the split view itself is always present in the hierarchy (swap line 21 and 22 of code above): HSplitView { if let disc = playerVM.disc { DiscInfoView( disc: disc, theme: theme, ) .frame(minWidth: 720, alignment: .topLeading) .buttonShadow() .focusable(false) TrackListView( theme: theme, playbackSequence: playerVM.tracksInPlaybackSequence, bonusTrackStartIndex: playerVM.player.disc?.releaseMetadata?.firstBonusTrackIndex, bonusTracksTitle: playerVM.player.disc?.releaseMetadata?.bonusTracksTitle, bonusTracksDisabled: playerVM.bonusTracksDisabled, onBonusIconTap: { playerVM.player.bonusTracksDisabled.toggle() } ) .frame(minWidth: 512) .focusable(false) } } I asked Claude AI about it and its guess is that conditionally inserting the HSplitView causes its underlying NSSplitView to get torn down and rebuilt on view updates, and the tracking areas responsible for the resize cursor never get a chance to settle. But that would be great to have a confirmation from someone at Apple who knows what's happening under the hood. Is this a known issue or an Expected behavior? Filed as FB22712819 in case anyone wants to duplicate. I posted this in case anyone had the same very specific issue... Cheers!