“swiftui”

Ok, thank you Ziqiao for the detailed & quick response, most appreciated. Folks who are exploring how to achieve that goal might consider shifting the direction. I agree... I just hope we can either clarify better alternative for those apps, or if not available, provide input to future APIs. In that case, I can ony suggest that yo file a feedback report, as mentioned in the post. If you already have one, please share so I can check the status. I see folks reporting this issue from time to time, but haven't yet seen them sharing their report. I have filed a feedback FB22115840 and created a sample project and provided a crash report. I think all the code is correct in terms of calling of completionHandler() and I've tried to simplify the project🤞🤞 really hope this is useful as would love to see a fix soon. The SwiftUI equivalent is backgroundTask(_:action:). I read the guidance but I still struggle to understand if on WatchOS, when using that API, you can avoid using a @WKExtensionDelegateAdapto

Thanks for the quick response. I’d prefer to use a pure SwiftUI text solution, but at the moment I need TextKit 2 for features SwiftUI still doesn’t expose—real-time syntax highlighting, paragraphStyle handling, tracking visibleRect changes, and related editor behaviors. Below is a minimal example showing how I’m using NSTextLayoutManager rendering attributes for a dynamic highlight. import SwiftUI struct RATestView: View { @State private var text = TextKit 2 rendering highlight demo. Type something and watch highlight update. @State private var search = highlight var body: some View { VStack { TextField(Search, text: $search) WrapperView(text: $text, highlight: search) .frame(height: 300) } } } private struct WrapperView: NSViewRepresentable { @Binding var text: String var highlight: String func makeNSView(context: Context) -> CustomTextView { let view = CustomTextView() return view } func updateNSView(_ nsView: CustomTextView, context: Context) { nsView.setText(text) nsView.s

These are 4 major changes that I have seen for Mac App Store review since the end of the last year. Quick rejection based on silly claims Wait time from 1-to-2 days to 4-to-5 days Reviewers ignoring rejection replies StoreKit 2 no longer working property in SwiftUI

I'd like to start with pointing you the following pure SwiftUI TextEditor sample, which may be good enough if your intent is to highlight a range of text (and do basic text editing) in a SwiftUI app: Building rich SwiftUI text experiences. If you do need TextKit 2 for other reasons, I'd suggest that you provide a minimal project that demonstrates the issue for folks to take a closer look. Best, —— Ziqiao Chen  Worldwide Developer Relations.

This post discusses using a Workout session to maintain background access. This is a very poor user experience as far as battery life goes but many apps are resorting to it for lack of better alternative. Yeah, but I'd say that, because of the limited resources, continuously running a watchOS app in background hasn't been a supported use case from day one. Folks who are exploring how to achieve that goal might consider shifting the direction. Also to be clear, using an active workout session in a non-workout app to extend the background execution time risks an App Review rejection. This post discusses getting crashes on WatchOS 26 for exhausting CPU time with background HKObserverQueries, I too am seeing this despite calling the completion handler immediately and not running any processing code, is there any solution? In that case, I can ony suggest that yo file a feedback report, as mentioned in the post. If you already have one, please share so I can check the status. I see folks reporting this issue from t

Experiencing the same issue here — native macOS (Swift/SwiftUI) app with Sparkle.framework, signed with Developer ID Application certificate using --options runtime and --timestamp on all binaries. We've submitted 12+ times over the past two days, both from local notarytool submit and from GitHub Actions CI. Two early submissions eventually came back Invalid (Sparkle nested binaries needed proper bundle-level signing rather than file-level). After fixing that, codesign --verify --deep --strict passes cleanly on every binary in the bundle. But every submission since the fix — about 10 of them — has been stuck at In Progress indefinitely. We're using App Store Connect API key auth (--key / --key-id / --issuer), and the submissions upload successfully with valid submission IDs. They just never resolve. Team ID: 9UT54V24XG Would appreciate any guidance or if someone from Apple could take a look at our queue. Happy to provide submission IDs if that helps.

The hover effects feature introduced in visionOS 26 represents a significant enhancement for creating immersive experiences, allowing users to interact with virtual objects using spatial gestures. However, the behavior of these gestures, particularly with the PSVR 2 controllers, can indeed vary based on how they are integrated into different types of views and applications. Clarification on Hover Effects and PSVR 2 Controllers Hover Effects in VisionOS: Hover effects are designed to provide feedback when a user's gaze is directed towards a virtual object. This is akin to a mouse hover on a desktop and can trigger spatial events or visual highlights. Controller Gestures: On the PSVR 2, traditional button presses (like pulling the trigger) are well-supported across various interfaces, including SwiftUI. However, gaze-based interactions like hover effects require additional handling to map spatial gestures to these events. Discrepancies in Behavior Sample Application Behavior: The sample you referenced