I have created a custom hover effect per this WWDC video and many other examples on the Net: https://developer.apple.com/videos/play/wwdc2024/10152/ I can get the button to expand when looked at within a VisionOS device and it will invoke a tap event when tapped but there is no click sound like a normal SwiftUI button does in VisionOS! I can't for the life of me figure out why. Any help would be appreciated!

Hello. I am currently building an app using AR Kit. As for the UI, I am using SwiftUI and NavigationStack + NavigationLink for navigation and screen transitions! Here I need to go back and forth between the AR screen and other screens. If the number of screen transitions is small, this is not a problem. However, if the number of screen transitions increases to 10 or 20, it crashes somewhere. We are struggling with this problem. (The nature of the application requires multiple screen transitions.) The crash log showed the following. error: read memory from 0x1e387f2d4 failed AR_Crash_Sample-2025-03-07-115914.txt Incident Identifier: B23D806E-D578-4A95-8828-2A1E8D6BB7F8 Beta Identifier: 924A85AB-441C-41A7-9BC2-063940BDAF32 Hardware Model: iPhone16,1 Process: AR_Crash_Sample [2375] Path: /private/var/containers/Bundle/Application/FAC3D662-DB10-434E-A006-79B9515D8B7A/AR_Crash_Sample.app/AR_Crash_Sample Identifier: ar.crash.sample.AR.Crash.Sample Version: 1.0 (1) AppStoreTools: 16C7015 AppVariant: 1:iPhone16,1:18 Beta: YES Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: ar.crash.sample.AR.Crash.Sample [1464] Date/Time: 2025-03-07 11:59:14.3691 +0900 Launch Time: 2025-03-07 11:57:47.3955 +0900 OS Version: iPhone OS 18.3.1 (22D72) Release Type: User Baseband Version: 2.40.05 Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: AR_Crash_Sample [2375] Triggered by Thread: 7 Application Specific Information: abort() called Thread 7 name: Dispatch queue: com.apple.arkit.depthtechnique Thread 7 Crashed: 0 libsystem_kernel.dylib 0x1e387f2d4 __pthread_kill + 8 1 libsystem_pthread.dylib 0x21cedd59c pthread_kill + 268 2 libsystem_c.dylib 0x199f98b08 abort + 128 3 libc++abi.dylib 0x21ce035b8 abort_message + 132 4 libc++abi.dylib 0x21cdf1b90 demangling_terminate_handler() + 320 5 libobjc.A.dylib 0x18f6c72d4 _objc_terminate() + 172 6 libc++abi.dylib 0x21ce0287c std::__terminate(void (*)()) + 16 7 libc++abi.dylib 0x21ce02820 std::terminate() + 108 8 libdispatch.dylib 0x199edefbc _dispatch_client_callout + 40 9 libdispatch.dylib 0x199ee65cc _dispatch_lane_serial_drain + 768 10 libdispatch.dylib 0x199ee7158 _dispatch_lane_invoke + 432 11 libdispatch.dylib 0x199ee85c0 _dispatch_workloop_invoke + 1744 12 libdispatch.dylib 0x199ef238c _dispatch_root_queue_drain_deferred_wlh + 288 13 libdispatch.dylib 0x199ef1bd8 _dispatch_workloop_worker_thread + 540 14 libsystem_pthread.dylib 0x21ced8680 _pthread_wqthread + 288 15 libsystem_pthread.dylib 0x21ced6474 start_wqthread + 8 Perhaps I am using too much memory! How can I address this phenomenon? For the AR functionality, we are using UIViewRepresentable, which is written in UIKit and can be called from SwiftUI import ARKit import AsyncAlgorithms import AVFoundation import SCNLine import SwiftUI internal struct MeasureARViewContainer: UIViewRepresentable { @Binding var tapCount: Int @Binding var distance: Double? @Binding var currentIndex: Int var focusSquare: FocusSquare = FocusSquare() let coachingOverlay: ARCoachingOverlayView = ARCoachingOverlayView() func makeUIView(context: Context) -> ARSCNView { let arView: ARSCNView = ARSCNView() arView.delegate = context.coordinator let configuration: ARWorldTrackingConfiguration = ARWorldTrackingConfiguration() configuration.planeDetection = [.horizontal, .vertical] if ARWorldTrackingConfiguration.supportsFrameSemantics(.sceneDepth) { configuration.frameSemantics = [.sceneDepth, .smoothedSceneDepth] } arView.session.run(configuration, options: [.resetTracking, .removeExistingAnchors]) context.coordinator.sceneView = arView context.coordinator.scanTarget() coachingOverlay.session = arView.session coachingOverlay.delegate = context.coordinator coachingOverlay.goal = .horizontalPlane coachingOverlay.activatesAutomatically = true coachingOverlay.autoresizingMask = [.flexibleWidth, .flexibleHeight] coachingOverlay.translatesAutoresizingMaskIntoConstraints = false arView.addSubview(coachingOverlay) return arView } func updateUIView(_ _: ARSCNView, context: Context) { context.coordinator.mode = MeasurementMode(rawValue: currentIndex) ?? .width if tapCount == 0 { context.coordinator.resetMeasurement() return } if distance != nil { return } DispatchQueue.main.async { if context.coordinator.distance == nil { context.coordinator.handleTap() } } } static func dismantleUIView(_ uiView: ARSCNView, coordinator: Coordinator) { uiView.session.pause() coordinator.stopScanTarget() coordinator.stopSpeech() DispatchQueue.main.async { uiView.removeFromSuperview() } } func makeCoordinator() -> Coordinator { Coordinator(self) } class Coordinator: NSObject, ARSCNViewDelegate, ARSessionDelegate, ARCoachingOverlayViewDelegate { var parent: MeasureARViewContainer var sceneView: ARSCNView? var startPosition: SCNVector3? var pointedCount: Int = 0 var distance: Float? var mode: MeasurementMode = .width let synthesizer: AVSpeechSynthesizer = AVSpeechSynthesizer() var scanTargetTask: Task<Void, Never>? var currentResult: ARRaycastResult? init(_ parent: MeasureARViewContainer) { self.parent = parent } // ... etc } }

Hi, I am currently developing a document-based application for macOS and have encountered a challenge related to document container management. Specifically, I need to open a windowGroup that shares the same container as the one used in the DocumentGroup. However, my current approach of using a global shared model container has led to unintended behavior: any new document created is linked to existing ones, and changes made in one document are reflected across all documents. To address this issue, I am looking for a solution that allows each newly created document to be individualized while still sharing the document container with all relevant WindowGroups that require access to the data it holds. I would greatly appreciate any insights or recommendations you might have on how to achieve this. Thank you for your time and assistance. Best regards, Something like: @main struct Todo: App { var body: some Scene { DocumentGroup(editing: Item.self, contentType: .item) { ContentView() } WindowGroup { UndockView() .modelContainer(of documentGroup above) } } }

In UIKit, certain events like a button tap can be simulated using: button.sendActions(for: .touchUpInside) This allows us to trigger the button’s action programmatically. However, in SwiftUI, there is no direct equivalent of sendActions(for:) for views like Button. What is the recommended approach to programmatically simulate a SwiftUI button tap and trigger its action? Is there an alternative mechanism to achieve this(and for other events under UIControl.event) , especially in scenarios where we want to test interactions or trigger actions without direct user input?

Looking for a solution that keeps the presented view controller fullscreen. The background is that I need to take some screenshots of the presenting view controller while the modal is onscreen. It's a pretty messy operation and we don't want to distract and delay the user by doing it before the modal is presented.

Does causing a swiftui view refresh via modifying observed properties while an alert is visible allowed? I am seeing a warning 'Presenting view controller <SwiftUI.PlatformAlertController> from detached view controller is not supported, and may result in incorrect safe area insets and a corrupt root presentation. Make sure <SwiftUI.PlatformAlertController> is in the view hierarchy before presenting from it. Will become a hard exception in a future release.' and the warning 'Attempt to present <SwiftUI.PlatformAlertController> on (from ) while a presentation is in progress'. The second warning occurs more often.

I was determined to fully rely on SwiftUI's navigation system giving the fact I'm starting a new project - strongly reconsidering this after a very basic requirement. Namely: navigate between my two screens while wanting to hide the back button label. One of them has a large navigation title The other one has no navigation title The problem is that back button icon simply jumps from top, a little bit down (where the title is supposed to be) and then back to top while navigating - resulting in a rough bouncy animation. struct ParentView: View { var body: some View { NavigationStack { WelcomeView() .navigationDestination(for: WelcomeRoute.self) { route in destinationView(for: route) } } } ... } struct WelcomeView: View { var body: some View { ScrollView { VStack { ... NavigationLink(value: WelcomeRoute.Routes.next) { Text("Next screen") } } } .navigationTitle("WELCOME") .navigationBarTitleDisplayMode(.large) } } struct NextWelcomeView: View { var body: some View { ScrollView { VStack { .... Text("Hello") } } .toolbarRole(.editor) } }

When I toggle a panel like navigationsidebar, I get a message in the console. I guess it's not a big issue, but is there a way to fix this message? because it appears in every project. Unable to open mach-O at path: /AppleInternal/Library/BuildRoots/d187757d-b9a3-11ef-83e5-aabfac210453/Library/Caches/com.apple.xbs/Binaries/RenderBox/install/TempContent/Root/System/Library/PrivateFrameworks/RenderBox.framework/Versions/A/Resources/default.metallib Error:2

I am experiencing memory leaks in my iOS app that seem to be related to an issue between UIInputView and _UIInputViewContent. After using the memory graph, I'm seeing that instances of these objects aren't being deallocated properly. The UIInputViewController whichs holds the inputView is being deallocated properly along with its subviews.I have tried to remove all of UIInputViewController's subviews and their functions but the uiInputView is not being deallocated. The current setup of my app is a collectionView with multiple cells,each possessing a textfield with holds a UIInputViewController.When i scroll up or down,the views are being reused as expected and the number of UIInputViewController stays consistent with the number of textfields.However the number of inputView keeps increasing referencing solely _UIInputViewContent. class KeyboardViewController: UIInputViewController { // Callbacks var key1: ((String) -> Void)? var key2: (() -> Void)? var key3: (() -> Void)? var key4: (() -> Void)? private lazy var buttonTitles = [ ["1", "2", "3"], ["4", "5", "6"], ["7", "8", "9"] ] override func viewDidLoad() { super.viewDidLoad() setupKeyboard() } lazy var mainStackView: UIStackView = { let mainStackView = UIStackView() mainStackView.axis = .vertical mainStackView.distribution = .fillEqually mainStackView.spacing = 16 mainStackView.translatesAutoresizingMaskIntoConstraints = false return mainStackView }() private func setupKeyboard() { let keyboardView = UIView(frame:CGRect(x: 0, y: 0, width: UIScreen.main.bounds.width, height: 279.0)) keyboardView.addSubview(mainStackView) NSLayoutConstraint.activate([ mainStackView.topAnchor.constraint(equalTo: keyboardView.topAnchor, constant: 16), mainStackView.leadingAnchor.constraint(equalTo: keyboardView.leadingAnchor, constant: 0), mainStackView.trailingAnchor.constraint(equalTo: keyboardView.trailingAnchor, constant: -24), mainStackView.bottomAnchor.constraint(equalTo: keyboardView.bottomAnchor, constant: -35) ]) // Create rows for (_, _) in buttonTitles.enumerated() { let rowStackView = UIStackView() rowStackView.axis = .horizontal rowStackView.distribution = .fillEqually rowStackView.spacing = 1 // Create buttons for each row for title in rowTitles { let button = createButton(title: title) rowStackView.addArrangedSubview(button) } mainStackView.addArrangedSubview(rowStackView) } self.view = keyboardView } private func createButton(title: String) -> UIButton { switch title { ///returns a uibutton based on title } } // MARK: - Button Actions @objc private func numberTapped(_ sender: UIButton) { if let number = sender.title(for: .normal) { key1?(number) } } @objc private func key2Called() { key2?() } @objc private func key3Called() { key3?() } @objc private func key4Called() { key4?() } deinit { // Clear any strong references key1 = nil key2 = nil key3 = nil key4 = nil for subview in mainStackView.arrangedSubviews { if let stackView = subview as? UIStackView { for button in stackView.arrangedSubviews { (button as? UIButton)?.removeTarget(self, action: nil, for: .allEvents) } } } mainStackView.removeFromSuperview() } } Environment iOS 16.3 Xcode 18.3.1 Any insights would be greatly appreciated as this is causing noticeable memory growth in my app over time.

Why is there no option as a CarPlay developer to enable the creation of an App to track and enter your car's maintenance records? I know the pat reply would be Apple doesn't want you to do this while car is in motion. But I would normally do this while parked at the dealership or other service provider no?

I have a few crash report from TestFlight with this context and nothing else. No symbols of my application. Crash report is attached. crashlog.crash It crashes at 16H25 (local time paris) and a few minutes after (8) I see the same user doing task in background (they download data with a particular URL in BGtasks) with a Delay that is consistant with a background wait of 5 or 7 minutes. I have no more information on this crash and by the way Xcode refuses to load it and shows an error. ( I did a report via Xcode for this).

In the example code below: OuterView has a @State var number: Int? = 0 InnerView expects a binding of type Int. OuterView uses Binding.init(_: Binding<Value?>) to convert from Binding<Int?> to Binding<Int>?. If OuterView sets number to nil, there is a runtime crash: BindingOperations.ForceUnwrapping.get(base:) + 160 InnerView is being evaluated (executing body?) when number is nil despite the fact that it shouldn't exist in that configuration. Is this a bug or expected behavior? struct OuterView: View { @State var number: Int? = 1 var body: some View { if let binding = Binding($number) { InnerView(number: binding) } Button("Doesn't Crash") { number = 0 } Button("Crashes") { number = nil } } } struct InnerView: View { @Binding var number: Int var body: some View { Text(number.formatted()) } } There is a workaround that involves adding an extension to Optional<Int>: extension Optional<Int> { var nonOptional: Int { get { self ?? 0 } set { self = newValue } } } And using that to ensure that the binding has a some value even when number is nil. if number != nil { InnerView(number: $number.nonOptional) } This works, but I don't understand why it's necessary. Any insight would be greatly appreciated!

TLDR: NSLayoutManager's textContainer(forGlyphAt:effectiveRange:) and lineFragmentRect(forGlyphRange:effectiveRange:) are returning inconsistent results. Context: I'm developing a word processing app that paginates from an NSTextStorage using NSLayoutManager. My app uses a text attribute (.columnType) to paginate sub-ranges of the text at a time, ensuring that each columnRange gets a container (or series of containers across page breaks) to fit. This is to support both multi-column and standard full-page-width content. After any user edit, I update pagination data in my Paginator model class. I calcuate frames/sizes for the views/containers, along with what superview they belong to (page). The UI updates accordingly. In order to determine whether the columnRange has overflowed from a container due to a page break OR whether the range of text hasn't overflowed its container and is actually using less space than available and should be sized down, I call both: layoutManager.textContainer(forGlyphAt: lastGlyphOfColumn, effectiveRange: &actualGlyphRangeInContainer)` // and `layoutManager.lineFragmentRect(forGlyphAt: lastGlyphOfColumn, effectiveRange: nil) Apple Documentation notes that both these calls force glyph generation and layout. As I'm in early development, I have not set non-contiguous layout. So these should be causing full layout, assuring accurate return values. Or so I'd hoped. This does work fine in many cases. I edit. Pagination works. But then I'll encounter UI-breaking inconsistent returns from these two calls. By inconsistent, I mean that the second call returns a line fragment rect that is in the container coordinates of A DIFFERENT container than the container returned by the first call. To be specific, the line fragment rect seems to be in the coordinates of the container that comes next in layoutManager.textContainers. Example Code: if !layoutManager.textContainers.indices.contains(i) { containerToUse = createTextContainer(with: availableSize) layoutManager.addTextContainer(containerToUse) } else { // We have a container already but it may be // the wrong size. containerToUse = layoutManager.textContainers[i] if containerToUse.size.width != availableSize.width { // Mandatory that we resize if we don't have // a matching width. Height resizing is not // mandatory and requires a layout check below. containerToUse.size = availableSize } } let glyphRange = layoutManager.glyphRange(forCharacterRange: remainingColumnRange, actualCharacterRange: nil) let lastGlyphOfColumn = NSMaxRange(glyphRange) - 1 var containerForLastGlyphOfColumn = layoutManager.textContainer(forGlyphAt: lastGlyphOfColumn, effectiveRange: &actualGlyphRangeInContainer) if containerForLastGlyphOfColumn != containerToUse && containerToUse.size.height < availableSize.height { // If we are here, we overflowed the container, // BUT the container we overflowed didn't use // the maximum remaining page space (this // means it was a pre-existing container that // needs to be sized up and checked once more). // NOTE RE: THE BUG: // at this point, prints show... // containerToUse.size.height // =628 // availableSize.height // =648 containerToUse.size = availableSize containerForLastGlyphOfColumn = layoutManager.textContainer(forGlyphAt: lastGlyphOfColumn, effectiveRange: &actualGlyphRangeInContainer) } // We now check again, knowing that the container we // are testing flow into is the max size it can be. if containerForLastGlyphOfColumn != containerToUse { // If we are here, we have overflowed the // container, so containerToUse size SHOULD be // final/accurate, since it is fully used. actualCharRangeInContainer = layoutManager.characterRange(forGlyphRange: actualGlyphRangeInContainer, actualGlyphRange: nil) // Start of overflow range is the first character // in the container that was overflowed into. let overflowLoc = actualCharRangeInContainer.location remainingColumnRange = NSRange(location: overflowLoc, length: remainingColumnRange.length - overflowLoc) // Update page count as we have broken to a new page currentPage += 1 } else { // If we are here, we have NOT overflowed // from the container. BUT... // THE BUG: // ***** HERE IS THE BUG! ***** lineFragmentRectForLastChar = layoutManager.lineFragmentRect(forGlyphAt: lastGlyphOfColumn, effectiveRange: nil) let usedHeight = lineFragmentRectForLastChar.maxY // BUG: ^The lines of code above return a // fragment rect that is in the coordinates // of the WRONG text container. Prints show: // usedHeight // =14 // usedHeight shouldn't be just 14 if this is // the SAME container that, when it was 628 // high, resulted in text overflowing. // Therefore, the line fragment here seems // to be in the coordinates of the ENSUING // container that we overflowed INTO, but // that shouldn't be possible, since we're in // a closure for which we know: // // containerForLastGlyphOfColumn == containerToUse // // If the last glyph container is the container // we just had to size UP, why does the final // glyph line fragment rect have a maxY of 14!? // Including ensuing code below only for context. if usedHeight < containerToUse.size.height { // Adjust container size down to usedRect containerToUse.size = CGSize(width: containerToUse.size.width, height: usedHeight) } else if usedHeight == availableSize.height { // We didn't force break to a new page BUT // we've used exactly the height of our page // to layout this column range, so need to // break to a new page for any ensuing text // columns. currentPage += 1 } else if usedHeight > containerToUse.size.height { // We should have caught this earlier. Text // has overflowed, but this should've been // caught when we checked // containerForLastGlyphOfColumn != // containerToUse. // // Note: this error has never thrown. throw PaginationError.unknownError("Oops.") } } Per my comments in the code block above, I don't understand why the very same text container that just overflowed and so had to be sized up from 628 to 648 in order to try to fit a glyph would now report that same glyph as both being IN that same container and having a line fragment rect with a maxY of just 14. A glyph couldn't fit in a container when it was 628 high, but if I size it up to 648, it only needs 14? There's something very weird going on here. Working with NSLayoutManager is a bit of a nightmare given the unclear documentation. Any help or insight here would be massively, massively appreciated.

I’m having a weird UIKit problem. I have a bunch of views in a UIScrollView and I add a UIContextMenuInteraction to all of them when the view is first loaded. Because they're in a scroll view, only some of the views are initially visible. The interaction works great for any of the views that are initially on-screen, but if I scroll to reveal new subviews, the context menu interaction has no effect for those. I used Xcode's View Debugger to confirm that my interaction is still saved in the view's interactions property, even for views that were initially off-screen and were then scrolled in. What could be happening here?

Hello. I'm building an iOS application that builds a framework named Design.framework using Xcode 16.1. When I launch my application on iOS 17.X, i get the following runtime error dyld[47899]: Library not loaded: /System/Library/Frameworks/SwiftUICore.framework/SwiftUICore Referenced from: <E625A246-E36B-351A-B077-CC38BAB5E07B> /Users/v/Library/Developer/Xcode/DerivedData/iScribd-bexojbdreldwkvbpzioqueldnvng/Build/Products/Debug_AppStore-iphonesimulator/Design.framework/Design Reason: tried: '/Users/v/Library/Developer/Xcode/DerivedData/iScribd-bexojbdreldwkvbpzioqueldnvng/Build/Products/Debug_AppStore-watchsimulator/SwiftUICore.framework/SwiftUICore' (no such file), '/Users/v/Library/Developer/Xcode/DerivedData/iScribd-bexojbdreldwkvbpzioqueldnvng/Build/Products/Debug_AppStore-iphonesimulator/SwiftUICore.framework/SwiftUICore' (no such file), '/Users/v/Library/Developer/Xcode/DerivedData/iScribd-bexojbdreldwkvbpzioqueldnvng/Build/Products/Debug_AppStore-watchsimulator/PackageFrameworks/SwiftUICore.framework/SwiftUICore' (no such file), '/Users/v/Library/Developer/Xcode/DerivedData/iScribd-bexojbdreldwkvbpzioqueldnvng/Build/Products/Debug_AppStore-iphonesimulator/PackageFrameworks/SwiftUICore.framework/SwiftUICore' (no such file), '/Library/Developer/CoreSimulator/Volumes/iOS_21C62/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.2.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/SwiftUICore.framework/SwiftUICore' (no such file), '/System/Library/Frameworks/SwiftUICore.framework/SwiftUICore' (no such file, not in dyld cache), '/Library/Developer/CoreSimulator/Volumes/iOS_21C62/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.2.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/SwiftUICore.framework/SwiftUICore' (no such file) This error does not happen on iOS 18+. When i run dyld_info Design.framework/Design, i see that there is indeed a dependency on SwiftUICore.framework Design.framework/Design [arm64]: -platform: platform minOS sdk iOS-simulator 16.0 18.1 -uuid: 09880F25-DC86-3D8E-BCAE-1A283508D879 -segments: load-offset segment section sect-size seg-size max-prot init-prot 0x00000000 __TEXT 416KB r.x 0x00000000 __TEXT 416KB r.x 0x0000543C __text 355508 0x0005C0F0 __stubs 3168 0x0005CD50 __objc_methlist 32 0x0005CD70 __const 8296 0x0005EDD8 __swift5_typeref 15820 0x00062BB0 __cstring 6885 0x00064698 __constg_swiftt 2804 0x0006518C __swift5_builtin 40 0x000651C0 __swift5_reflstr 2952 0x00065D48 __swift5_assocty 816 0x00066078 __objc_methname 299 0x000661A4 __swift5_proto 368 0x00066314 __swift5_types 280 0x0006642C __swift5_fieldmd 3688 0x00067294 __swift5_protos 8 0x0006729C __swift5_capture 244 0x00067390 __unwind_info 2296 0x00067C88 __eh_frame 888 0x00068000 __DATA_CONST 16KB rw. 0x00068000 __DATA_CONST 16KB rw. 0x00068000 __got 3704 0x00068E78 __const 6864 0x0006A948 __objc_classlist 40 0x0006A970 __objc_imageinfo 8 0x0006C000 __DATA 32KB rw. 0x0006C000 __DATA 32KB rw. 0x0006C000 __objc_const 792 0x0006C318 __objc_selrefs 96 0x0006C378 __objc_classrefs 48 0x0006C3A8 __objc_data 208 0x0006C478 __data 4136 0x0006D4A0 __bss 12784 0x00070690 __common 4592 -linked_dylibs: attributes load path @rpath/CommonTools.framework/CommonTools /System/Library/Frameworks/Foundation.framework/Foundation /usr/lib/libobjc.A.dylib /usr/lib/libSystem.B.dylib /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation /System/Library/Frameworks/CoreGraphics.framework/CoreGraphics /System/Library/Frameworks/CoreText.framework/CoreText weak-link /System/Library/Frameworks/DeveloperToolsSupport.framework/DeveloperToolsSupport /System/Library/Frameworks/SwiftUI.framework/SwiftUI /System/Library/Frameworks/SwiftUICore.framework/SwiftUICore /System/Library/Frameworks/UIKit.framework/UIKit /usr/lib/swift/libswiftCore.dylib weak-link /usr/lib/swift/libswiftCoreAudio.dylib /usr/lib/swift/libswiftCoreFoundation.dylib weak-link /usr/lib/swift/libswiftCoreImage.dylib weak-link /usr/lib/swift/libswiftCoreMedia.dylib weak-link /usr/lib/swift/libswiftDarwin.dylib weak-link /usr/lib/swift/libswiftDataDetection.dylib weak-link /usr/lib/swift/libswiftDispatch.dylib weak-link /usr/lib/swift/libswiftFileProvider.dylib weak-link /usr/lib/swift/libswiftMetal.dylib weak-link /usr/lib/swift/libswiftOSLog.dylib /usr/lib/swift/libswiftObjectiveC.dylib weak-link /usr/lib/swift/libswiftQuartzCore.dylib weak-link /usr/lib/swift/libswiftSpatial.dylib weak-link /usr/lib/swift/libswiftUniformTypeIdentifiers.dylib weak-link /usr/lib/swift/libswiftXPC.dylib /usr/lib/swift/libswift_Concurrency.dylib weak-link /usr/lib/swift/libswiftos.dylib weak-link /usr/lib/swift/libswiftsimd.dylib weak-link /usr/lib/swift/libswiftUIKit.dylib I can add a -weak_framework SwiftUICore to "Other Linker Flags" in my Design.framework Build Settings, and that will solve my problem, but I'd like to know what prompts my Design.framework to depend on SwiftUICore despite having a minimum set to iOS 16? And how am I supposed to handle devices prior to iOS 18 which do not have this library? is adding the linker flag the right way forward?

Since beta 4, Using TipKit causes the app to crash. This was not the case in Beta 3. My app uses UIKit

Context: The SwiftUI @Query macro has an internal modelContext. The ModelActor also has a modelContext, from which the data should be read/written. Issue: When writing to @Model data fetched with @Query macro using a ModelActor, it will crash in the most not-obvious ways. Also, fetching @Model with ModelActor will result in errors in Swift 6 since @Model aren't sendable. Problem to Solve: - How to write a good amount of data to SwiftData/CoreData without blocking the UI thread? Would the recommendation from the Apple team be that a large amount of data should be read/written with ModelActor and a small amount should be done with the @Query's internal modelContext ?

I have DNG files that I want to open and show as EDR content in my app. It seems like the DNG files should have enough per pixel information to show more colors that Display P3 but whenever I load the images using CIRawFilter and then inspect the outputImage color space it is always "DisplayP3", not something like "ITU-R BT.2100 PQ" there doesn't seem to be any way to make it load with a different color space for displaying EDR images. Does this make sense for DNG files, it seems like it should? If I open the same file using CIImage with the expandToHDR option e.g. CIImage(contentsOf: rawURL, options: [.expandToHDR: true]) then it does have the desired EDR color space, but then I don't get any of the properties that are available via the CIRAWFilter class to manipulate the data. Basically I just want to be able to open the DNG file via CIRAWFilter and then display it in my SwiftUI app as an EDR image by adding the allowedDynamicRange(.high) property. Image("my-dng-image").allowedDynamicRange(.high) Or do DNG files (just RAW not ProRAW) not contain enough information to be displayed as EDR images, seems like they should.

I want to create a MKRoute from a list of MKMapPoints or coordinates. But apparently MKRoute can only be generated from a MKDirections request from Apple's servers. The primary use of my app will be activities (eg hiking) in the back country where (1) a network connection likely won't be available and (2) there likely will not be a trail in Apple's map network. For example I want to provide navigation for following a recorded GPS track or my only MKPolyLines. Note that I am required to use MapKit (3rd party map SDKs are not an option for a number of reasons). It feels like a huge missed opportunity if MapKit doesn't allow Routes to be created from a predetermined list of coordinates. Does anyone know of any solutions for this problem either somehow creating a MKRoute from a list of coordinates or a 3rd party library? I've searched but haven't had any luck finding a solution. It seems like something like this must exist so I thought I'd ask.

What particular configuration will allow a document based app (DocumentGroup) to open the application into the selected document when the document is touched in Files.app. The sample code doesn't show this behaviour and instead will open the app but will not open the selected document. This also is the behaviour with the Xcode document based app template. Using LSSupportsOpeningDocumentsInPlace = YES in the plist does not make any difference. .onOpenURL is not a modifier on Scene only View and if the app is opened from cold the document view will not exist. In any case I would expect the DocumentGroup to open the document directly with no further intervention. What additional magic do I need to get a document to open directly from Files.app (or Messages) . For example Swift Playgrounds shows the correct behaviour, opening the selected project directly.