“swiftui”

other than the fact that you can put AppKit and UIKit views into a swiftUI to fill some gaps in the framework, id say it’s kind of an entirely different way of making and thinking about app architecture.

I didn't start from a more normal place because I thought I'd see if Apple had made SwiftUI any better since the last time. It would've made a lot more sense if it was simply a programmatic view layout language that smoothly connected to normal frameworks, rather than the confusing ball of mystery it turned out to be.

Ran into the same thing and had Claude fix it. Short version as I understand it is that I had just upgraded my dev account from free to paid, and it didn't rebuild the WidgetKit extension under the new paid profile. Details from Claude: I diagnosed this for a user whose app showed these exact symptoms — black Dynamic Island container (tapping it opened the app, so the activity existed), empty expanded view, and no Lock Screen presentation, with the widget extension's SwiftUI content never rendering. Clean builds, a DerivedData wipe, reinstalls, and a device reboot all failed to fix it. The cause was a stale cached provisioning profile from a free-team era. The user had upgraded their personal Apple Developer membership from free to paid, which keeps the same Team ID — so Xcode's automatic signing saw no reason to regenerate cached profiles. Four of the app's targets carry entitlements (Family Controls, App Groups) whose provisioning needs changed with the upgrade, forcing fresh paid profiles; the Wid

Pretty sure this will be the last SwiftUI app I'll ever write. Never say never… 😉 Why didn't you start directly with Appkit of UIKit ? I personally have mixed feelings about SwiftUI, because, for the sake of apparent simplicity, it forces sometimes into convoluted solutions. IMHO, SwiftUI is great for rapid prototyping, but I do not use it for complex apps.

I found that I can send a custom notification from the function that receives the menu item action to my ContentView, and that works, getting around the whole this is not the view that you're searching for junk. Pretty sure this will be the last SwiftUI app I'll ever write. I tried one before that should've been simple, but again I hit a wall of complexity and things that just aren't possible and went back to the glory that is Cocoa for that. At least things show up in the debugger there.

J0hn is absolutely right that Timer and SwiftUI aren’t really best friends. Timer comes from the Objective-C world, and SwiftUI is not built on that *cough*… foundation. So, in a SwiftUI app I try to avoid Timer and instead lean in to Swift concurrency primitives. For example, if you want a simple repeating timer you can use a loop containing a Task.sleep(…): struct ContentView: View { var body: some View { … your view … .task { do { while true { … do work … try await Task.sleep(for: .seconds(5)) } } catch is CancellationError { return } catch { … handle ‘real’ errors … } } } } For more complex stuff, you have various options in the Swift AsyncAlgorithms package, for example, the AsyncTimerSequence type. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Additional informations: It's working fine with SwiftUI on iOS 17 and iOS 18. It's working fine with an equivalent UIKit code on iOS 26 and iOS 27. In my opinion, it's very likely to be a SwiftUI regression. I updated the feedback FB23661327 with these informations. I would love an Apple engineer to have a look at it and fix the issue before iOS 27 ships. Axel

Well, I need more than a refresher course, since I've just been trying to understand how each piece of SwiftUI works when I come to it. I never been so stymied and angry at a language in all my 48 years of programming. Here's the relevant code. Comments say what works and what doesn't: @main struct SpeakotronikApp: App { @State public var contentView = ContentView(); @State var showFileImporter:Bool = false; var body:some Scene { WindowGroup { self.contentView .environment(langModel) } .commands { CommandGroup(after:.newItem) { Button(Import…) { self.showFileImporter = true; } .fileImporter(isPresented:$showFileImporter, allowedContentTypes:[.text], allowsMultipleSelection:false) { result in switch result { case .success(let urls): for url in urls { // Tell the content view to read the file and add new terms that will be translated: self.contentView.importTerms(url:url); } case .failure(let error): print(Error selecting file: (error.localizedDescription)); } } } } } } struct ContentView: View { @Envi

Keep replying with your code updates and I'll help you get something working. While SwiftUI has some difficult parts, it is not difficult it's just different. It's important to remember you're not making views, you're just telling the SwiftUI runtime system how to make views, and it can be picky.

Menu Bars are one of the three most confusing aspects of SwiftUI app development imo. Imagine you had a multi-window app and each of those windows have an instance of your content view. Maybe you want a specific window to show the file import view. Maybe you only want one window to use the result of said import. It’s probably the active window, since that’s what the user is interacting with. There’s a way to achieve this and it is the technique that I would recommend. In an extension on the FocusedValues enum, I declare a Binding. You can probably do this with an @Entry too. var fousedWindowSheet: Binding? { get { self[FousedWindowSheetKey.self] } set { self[FousedWindowSheetKey.self] = newValue } } This allows focused windows to provide a hook that the menu bar can then leverage to present things. You content view can do this with the following: .focusedSceneValue(.fousedWindowSheet, $showingFocusedWindowSheet) (it provides it's own @State to the focus system and can use that state in its own .sheet

So... bit of a mind-bender, but you're losing your self reference, and possibly leaking timers into the runloop. SwiftUI views are not actually views, but more like view-blueprints, that can be asked for a view. This means they can be inited as needed by the system and body can be called as needed. This means your setupTimer method is at risk of getting called multiple times and timers could keep getting put into the run loop. It also means that the self reference inside the timer closure is super dubious. Throwing it into an observable controller that's stored as a state object property will keep the state more constant and it will work. (I'm leery of the .task method in this example and it's just to get the timer started. You probably want debounce protection if you're gonna store em in the runLoop. You should probably seek an alternative async/await solution for that) @Observable class Controller { var referenceDate: Date = Date() init() { } func setupTimer() { let calendar = Calendar.current guar

Thanks for the detailed write-up. To look into this I built a small tool around CIRAWFilter and ran it on several clear-sky ProRAW captures on shipping macOS 26.5.1. It decodes the sensor RAW, not the embedded preview, and samples the sky under a range of settings. I wanted to see the highlight color as measured channel values rather than by eye. Here is what I found, and where the evidence points. On my captures I could not reproduce a blue-to-gray/purple shift from boostAmount in the decoded RAW itself. I sampled the sky in Core Image's extended-range linear working space. At boostAmount = 1.0 the sky stayed blue-dominant across the whole brightness range, including bright areas near the sun. When I forced the sky to blow out, it desaturated toward white, with red the last channel to reach the ceiling. So it approached white or a faint cyan, never magenta or purple. I did not see red exceed green in any configuration, and a purple cast needs that. In my testing boostAmount = 0.0 did not preserve blue better

OK, so now the fileImporter is being run from the command in the app. It calls a function on the ContentView to import files. That function needs to do some other things to itself, so it sets the value of a @State TranslationSession.Configuration in the ContentView to a new instance, which is supposed to kick off a translationTask. Nothing happens, I assume because it's not being called from within a View hierarchy, but from the app. Why is it so difficult to make things work in SwiftUI?