Home Blog

ios – ViewThatFits inflicting crash


Whereas testing on simulators, I’ve hit a problem the place ViewThatFits seems to have a threading challenge. This will trigger warnings or a crash.

The surroundings is the next:

  • Xcode 26.0 beta 5
  • Swift 6 with strict concurrency checking
  • minimal deployment goal iOS 17.0
  • debug construct configuration
  • iPhone 16 simulator operating iOS 18.5 (causes crash)
  • iPhone 15 simulator operating iOS 17.5 (causes warnings)

The next code can be utilized to breed the issue when operating with the next textual content dimension:

Screenshot

struct ContentView: View {
    let item1 = "The fast brown fox jumps over the lazy canine."
    let item2 = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua."
    @State non-public var isExpanded = false

    enum LayoutHint {
        case regular
        case spaceIsTight
        case scrolling
    }

    non-public func itemList(gadgets: [String], trace: LayoutHint) -> some View {
        VStack(alignment: .main, spacing: 9) {
            ForEach(Array(gadgets.enumerated()), id: .offset) { _, textual content in
                Textual content(textual content)
                    .font(.footnote)
            }
        }
        .body(maxWidth: .infinity, alignment: .main)
        .fixedSize(horizontal: false, vertical: true)
    }

    non-public func expandedExplanation(gadgets: [String]) -> some View {
        ViewThatFits(in: .vertical) {

            // If any of those 3 views are commented out, it really works
            itemList(gadgets: gadgets, trace: .regular)
            itemList(gadgets: gadgets, trace: .spaceIsTight)
            ScrollView {
                itemList(gadgets: gadgets, trace: .scrolling)
            }
        }
    }

    non-public var chevronUp: some View {
        Picture(systemName: "chevron.compact.up")
            .imageScale(.medium)
            .font(.title)
            .fontWeight(.semibold)
            .foregroundStyle(.grey)

            // If vertical padding is added, it really works
            // .padding(.vertical, 10)
            .body(maxWidth: .infinity)
    }

    non-public var expandedContent: some View {
        VStack(alignment: .main, spacing: 20) {
            expandedExplanation(gadgets: [item1, item2])

            // If chevronUp is commented out, it really works
            chevronUp
        }
        .padding()
    }

    non-public var collapsedContent: some View {
        Textual content("Present expanded")
            .foregroundStyle(Shade(.hyperlink))
            .padding()
            .body(maxWidth: .infinity)
    }

    var physique: some View {
        ZStack(alignment: .high) {
            if isExpanded {
                expandedContent
            } else {
                collapsedContent
            }
        }
        .clipped()
        .contentShape(.rect)
        .background {
            UnevenRoundedRectangle(
                topLeadingRadius: 0,
                bottomLeadingRadius: 20,
                bottomTrailingRadius: 20,
                topTrailingRadius: 0
            )
            .fill(Shade(.systemGray6))
            .ignoresSafeArea(edges: .high)
        }
        .onTapGesture {
            withAnimation(.easeInOut(period: 0.25)) {
                isExpanded.toggle()
            }
        }
        .body(maxHeight: .infinity, alignment: .high)
    }
}

Right here is the way it ought to look when the highest part is expanded (notice the textual content dimension):

Screenshot

The crash that occurs when operating on the iPhone 16 simulator with iOS 18.5 is as follows:

#0  0x0000000102506e28 in _dispatch_assert_queue_fail ()
#1  0x000000010253c388 in dispatch_assert_queue$V2.chilly.1 ()
#2  0x0000000102506db0 in dispatch_assert_queue ()
#3  0x0000000249df246c in swift_task_isCurrentExecutorWithFlagsImpl ()
#4  0x0000000102e80504 in closure #1 in closure #1 in ContentView.itemList(gadgets:trace:) ()
#5  0x0000000102e807d4 in thunk for @escaping @callee_guaranteed (@unowned Int, @assured String) -> (@owned Textual content) ()
#6  0x00000001d4c8cd24 in closure #1 () -> τ_0_2 in SwiftUI.ForEachState.merchandise(at: τ_0_0.Index, offset: Swift.Int) -> SwiftUI.ForEachState.Merchandise ()
#7  0x00000001d4c94dac in partial apply forwarder for closure #1 () -> τ_0_2 in SwiftUI.ForEachState.merchandise(at: τ_0_0.Index, offset: Swift.Int) -> SwiftUI.ForEachState.Merchandise ()
#8  0x00000001d4a7004c in closure #1 (Swift.UnsafeMutablePointer>) throws -> τ_0_0 in SwiftUI._withObservation(do: () throws -> τ_0_0) throws -> (worth: τ_0_0, accessList: Swift.Optionally available) ()
#9  0x00000001d473a6d8 in partial apply forwarder for closure #1 (Swift.UnsafeMutablePointer>) throws -> τ_0_0 in SwiftUI._withObservation(do: () throws -> τ_0_0) throws -> (worth: τ_0_0, accessList: Swift.Optionally available) ()
#10 0x00000001d48c9288 in withUnsafePointer ()
#11 0x00000001d4c8c160 in merchandise ()
#12 0x00000001d4c8e24c in forEachItem ()
#13 0x00000001d4c94b38 in perform signature specialization  of SwiftUI.ForEachList.applyNodes(from: inout Swift.Int, model: SwiftUI._ViewList_IteratorStyle, checklist: Swift.Optionally available>, rework: inout SwiftUI._ViewList_SublistTransform, to: (inout Swift.Int, SwiftUI._ViewList_IteratorStyle, SwiftUI._ViewList_Node, inout SwiftUI._ViewList_SublistTransform) -> Swift.Bool) -> Swift.Bool ()
#14 0x00000001d4c92ec8 in protocol witness for SwiftUI.ViewList.applyNodes(from: inout Swift.Int, model: SwiftUI._ViewList_IteratorStyle, checklist: Swift.Optionally available>, rework: inout SwiftUI._ViewList_SublistTransform, to: (inout Swift.Int, SwiftUI._ViewList_IteratorStyle, SwiftUI._ViewList_Node, inout SwiftUI._ViewList_SublistTransform) -> Swift.Bool) -> Swift.Bool in conformance SwiftUI.ForEachList : SwiftUI.ViewList in SwiftUI ()
#15 0x00000001d49a8374 in applySublists ()
#16 0x00000001d49a501c in applySublists ()
#17 0x00000001d460d09c in generic specialization  of SwiftUI.DynamicContainerInfo.updateItems(disableTransitions: Swift.Bool) -> (modified: Swift.Bool, hasDepth: Swift.Bool) ()
#18 0x00000001d460c258 in generic specialization  of SwiftUI.DynamicContainerInfo.updateValue() -> () ()
#19 0x00000001d462b764 in generic specialization > of implicit closure #1 (Swift.UnsafeMutableRawPointer, __C.AGAttribute) -> () in closure #1 () -> (Swift.UnsafeMutableRawPointer, __C.AGAttribute) -> () in closure #1 (Swift.UnsafePointer) -> AttributeGraph.Attribute in AttributeGraph.Attribute.init(τ_1_0) -> AttributeGraph.Attribute ()
#20 0x00000001c00ca438 in AG::Graph::UpdateStack::replace ()
#21 0x00000001c00cac04 in AG::Graph::update_attribute ()
#22 0x00000001c00d24dc in AG::Graph::input_value_ref_slow ()
#23 0x00000001c00e8054 in AGGraphGetValue ()
#24 0x00000001d496010c in SwiftUI.DynamicLayoutComputer.containerInfo.getter : Swift.Optionally available ()
#25 0x00000001d4960248 in updateValue ()
#26 0x00000001d4947d58 in partial apply forwarder for implicit closure #1 (Swift.UnsafeMutableRawPointer, __C.AGAttribute) -> () in closure #1 () -> (Swift.UnsafeMutableRawPointer, __C.AGAttribute) -> () in closure #1 (Swift.UnsafePointer) -> AttributeGraph.Attribute in AttributeGraph.Attribute.init(τ_1_0) -> AttributeGraph.Attribute ()
#27 0x00000001c00ca438 in AG::Graph::UpdateStack::replace ()
#28 0x00000001c00cac04 in AG::Graph::update_attribute ()
#29 0x00000001c00d22f0 in AG::Graph::input_value_ref_slow ()
#30 0x00000001c00e7e14 in AGGraphGetInputValue ()
#31 0x00000001d47d1904 in dimension ()
#32 0x00000001d4aab49c in sizeThatFits ()
#33 0x00000001d4aabe74 in protocol witness for SwiftUI.UnaryLayout.sizeThatFits(in: SwiftUI._ProposedSize, context: SwiftUI.SizeAndSpacingContext, little one: SwiftUI.LayoutProxy) -> __C.CGSize in conformance SwiftUI._FlexFrameLayout : SwiftUI.UnaryLayout in SwiftUI ()
#34 0x00000001d4934fcc in merged SwiftUI.UnaryLayoutEngine.sizeThatFits(SwiftUI._ProposedSize) -> __C.CGSize ()
#35 0x00000001d4934cf4 in protocol witness for SwiftUI.LayoutEngine.sizeThatFits(SwiftUI._ProposedSize) -> __C.CGSize in conformance SwiftUI.UnaryLayoutEngine : SwiftUI.LayoutEngine in SwiftUI ()
#36 0x00000001d4b700ac in sizeThatFits ()
#37 0x00000001d47d1970 in dimension ()
#38 0x00000001d4664b3c in protocol witness for SwiftUI.UnaryLayout.sizeThatFits(in: SwiftUI._ProposedSize, context: SwiftUI.SizeAndSpacingContext, little one: SwiftUI.LayoutProxy) -> __C.CGSize in conformance SwiftUI._FixedSizeLayout : SwiftUI.UnaryLayout in SwiftUI ()
#39 0x00000001d4934fcc in merged SwiftUI.UnaryLayoutEngine.sizeThatFits(SwiftUI._ProposedSize) -> __C.CGSize ()
#40 0x00000001d4934cf4 in protocol witness for SwiftUI.LayoutEngine.sizeThatFits(SwiftUI._ProposedSize) -> __C.CGSize in conformance SwiftUI.UnaryLayoutEngine : SwiftUI.LayoutEngine in SwiftUI ()
#41 0x00000001d4b700ac in sizeThatFits ()
#42 0x00000001d4b6ee60 in sizeThatFits ()
#43 0x00000001d3b4e35c in closure #1 (SwiftUI._ViewOutputs, Swift.Bool) -> Swift.Bool in closure #1 () -> () in SwiftUI.SizeFittingLayoutComputer.Engine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available ()
#44 0x00000001d3b4cfec in closure #1 (SwiftUI._ViewList_Sublist) -> Swift.Bool in SwiftUI.SizeFittingState.applyChildren(selectLast: Swift.Bool, to: (SwiftUI._ViewOutputs, Swift.Bool) -> Swift.Bool) -> () ()
#45 0x00000001d49a7640 in applySublists ()
#46 0x00000001d49b09e8 in merged partial apply forwarder for closure #1 (inout Swift.Int, SwiftUI._ViewList_IteratorStyle, SwiftUI._ViewList_Node, inout SwiftUI._ViewList_SublistTransform) -> Swift.Bool in SwiftUI._ViewList_Node.applySublists(from: inout Swift.Int, model: SwiftUI._ViewList_IteratorStyle, rework: inout SwiftUI._ViewList_SublistTransform, to: (SwiftUI._ViewList_Sublist) -> Swift.Bool) -> Swift.Bool ()
#47 0x00000001d49abddc in applyNodes ()
#48 0x00000001d49a8374 in applySublists ()
#49 0x00000001d49a501c in applySublists ()
#50 0x00000001d3b4c190 in applyChildren ()
#51 0x00000001d3b4e144 in closure #1 () -> () in SwiftUI.SizeFittingLayoutComputer.Engine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available ()
#52 0x00000001c00cafb0 in AG::Graph::with_update ()
#53 0x00000001d3b4e524 in protocol witness for SwiftUI.LayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available in conformance SwiftUI.SizeFittingLayoutComputer.Engine : SwiftUI.LayoutEngine in SwiftUI ()
#54 0x00000001d4b70194 in explicitAlignment ()
#55 0x00000001d4c16cfc in perform signature specialization  Swift.Optionally available in SwiftUI.StackLayout.(UnmanagedImplementation in _00690F480F8D293143B214DBE6D72CD0).placeChildren(in: SwiftUI.ProposedViewSize) -> (), Argument Varieties : [Swift.Optional]> of SwiftUI.StackLayout.UnmanagedImplementation.sizeChildrenGenerallyWithConcreteMajorProposal(in: SwiftUI.ProposedViewSize, minorProposalForChild: (SwiftUI.StackLayout.Little one) -> Swift.Optionally available) -> () ()
#56 0x00000001d4c1779c in perform signature specialization  Swift.Optionally available in SwiftUI.StackLayout.(UnmanagedImplementation in _00690F480F8D293143B214DBE6D72CD0).placeChildren(in: SwiftUI.ProposedViewSize) -> (), Argument Varieties : [Swift.Optional]> of SwiftUI.StackLayout.UnmanagedImplementation.placeChildren1(in: SwiftUI.ProposedViewSize, minorProposalForChild: (SwiftUI.StackLayout.Little one) -> Swift.Optionally available) -> () ()
#57 0x00000001d4c15fb4 in placeChildren ()
#58 0x00000001d4c15c84 in explicitAlignment ()
#59 0x00000001d4c14664 in explicitAlignment ()
#60 0x00000001d47a46a8 in merged protocol witness for SwiftUI.Format.explicitAlignment(of: SwiftUI.HorizontalAlignment, in: __C.CGRect, proposal: SwiftUI.ProposedViewSize, subviews: SwiftUI.LayoutSubviews, cache: inout τ_0_0.Cache) -> Swift.Optionally available in conformance SwiftUI._VStackLayout : SwiftUI.Format in SwiftUI ()
#61 0x00000001d496875c in closure #1 (Swift.UnsafeMutablePointer) -> Swift.Optionally available in closure #1 (Swift.UnsafeMutablePointer>) -> Swift.Optionally available in SwiftUI.ViewLayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available ()
#62 0x00000001d49684c4 in closure #1 (Swift.UnsafeMutablePointer>) -> Swift.Optionally available in SwiftUI.ViewLayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available ()
#63 0x00000001d496ab24 in partial apply forwarder for closure #1 (Swift.UnsafeMutablePointer>) -> Swift.Optionally available in SwiftUI.ViewLayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available ()
#64 0x00000001d48c9288 in withUnsafePointer ()
#65 0x00000001d496837c in explicitAlignment ()
#66 0x00000001d4968df0 in protocol witness for SwiftUI.LayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available in conformance SwiftUI.ViewLayoutEngine : SwiftUI.LayoutEngine in SwiftUI ()
#67 0x00000001d4b70194 in explicitAlignment ()
#68 0x00000001d47d26f0 in explicitAlignment ()
#69 0x00000001d4934c68 in explicitAlignment ()
#70 0x00000001d4934d08 in protocol witness for SwiftUI.LayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available in conformance SwiftUI.UnaryLayoutEngine : SwiftUI.LayoutEngine in SwiftUI ()
#71 0x00000001d4b70194 in explicitAlignment ()
#72 0x00000001d4663040 in SwiftUI.ViewDimensions.subscript.getter : (SwiftUI.AlignmentKey) -> CoreGraphics.CGFloat ()
#73 0x00000001d4569c74 in perform signature specialization  __C.CGPoint in SwiftUI._ZStackLayout.placeSubviews(in: __C.CGRect, proposal: SwiftUI.ProposedViewSize, subviews: SwiftUI.LayoutSubviews, cache: inout ()) -> (), Argument Varieties : [SwiftUI._ZStackLayout]> of generic specialization , SwiftUI.ViewDimensions>, __C.CGPoint> of Swift.Sequence.cut back(τ_1_0, (τ_1_0, τ_0_0.Aspect) throws -> τ_1_0) throws -> τ_1_0 ()
#74 0x00000001d458d844 in perform signature specialization  of SwiftUI._ZStackLayout.placeSubviews(in: __C.CGRect, proposal: SwiftUI.ProposedViewSize, subviews: SwiftUI.LayoutSubviews, cache: inout ()) -> () ()
#75 0x00000001d4967e0c in closure #1 (Swift.UnsafeMutablePointer) -> () in SwiftUI.ViewLayoutEngine.childGeometries(at: SwiftUI.ViewSize, origin: __C.CGPoint) -> Swift.Array ()
#76 0x00000001d4967bb8 in childGeometries ()
#77 0x00000001d4968aa4 in static SwiftUI.ViewLayoutEngine.defaultAlignment(_: SwiftUI.AlignmentKey, dimension: SwiftUI.ViewSize, information: Swift.UnsafeMutableRawPointer) -> Swift.Optionally available ()
#78 0x00000001d4968e10 in protocol witness for static SwiftUI.DefaultAlignmentFunction.defaultAlignment(_: SwiftUI.AlignmentKey, dimension: SwiftUI.ViewSize, information: Swift.UnsafeMutableRawPointer) -> Swift.Optionally available in conformance SwiftUI.ViewLayoutEngine : SwiftUI.DefaultAlignmentFunction in SwiftUI ()
#79 0x00000001d495287c in merged protocol witness for SwiftUI.Format.explicitAlignment(of: SwiftUI.HorizontalAlignment, in: __C.CGRect, proposal: SwiftUI.ProposedViewSize, subviews: SwiftUI.LayoutSubviews, cache: inout τ_0_0.Cache) -> Swift.Optionally available in conformance SwiftUI._ZStackLayout : SwiftUI.Format in SwiftUI ()
#80 0x00000001d496875c in closure #1 (Swift.UnsafeMutablePointer) -> Swift.Optionally available in closure #1 (Swift.UnsafeMutablePointer>) -> Swift.Optionally available in SwiftUI.ViewLayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available ()
#81 0x00000001d49684c4 in closure #1 (Swift.UnsafeMutablePointer>) -> Swift.Optionally available in SwiftUI.ViewLayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available ()
#82 0x00000001d496ab24 in partial apply forwarder for closure #1 (Swift.UnsafeMutablePointer>) -> Swift.Optionally available in SwiftUI.ViewLayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available ()
#83 0x00000001d48c9288 in withUnsafePointer ()
#84 0x00000001d496837c in explicitAlignment ()
#85 0x00000001d4968df0 in protocol witness for SwiftUI.LayoutEngine.explicitAlignment(_: SwiftUI.AlignmentKey, at: SwiftUI.ViewSize) -> Swift.Optionally available in conformance SwiftUI.ViewLayoutEngine : SwiftUI.LayoutEngine in SwiftUI ()
#86 0x00000001d4b70194 in explicitAlignment ()
#87 0x00000001d4663040 in SwiftUI.ViewDimensions.subscript.getter : (SwiftUI.AlignmentKey) -> CoreGraphics.CGFloat ()
#88 0x00000001d4aaa9f0 in generic specialization  of SwiftUI.FrameLayoutCommon.commonPlacement(of: SwiftUI.LayoutProxy, in: SwiftUI.PlacementContext, childProposal: SwiftUI._ProposedSize) -> SwiftUI._Placement ()
#89 0x00000001d49336cc in generic specialization  of SwiftUI.UnaryLayoutEngine.childPlacement(at: SwiftUI.ViewSize) -> SwiftUI._Placement ()
#90 0x00000001d4947910 in partial apply forwarder for generic specialization  of closure #1 (inout SwiftUI.UnaryLayoutEngine) -> SwiftUI._Placement in SwiftUI.UnaryChildGeometry.worth.getter : SwiftUI.ViewGeometry ()
#91 0x00000001d48c33f0 in partial apply forwarder for generic specialization , SwiftUI._Placement> of closure #1 (inout τ_0_0) -> τ_0_1 in SwiftUI.LayoutComputer.withMutableEngine(kind: τ_0_0.Kind, do: (inout τ_0_0) -> τ_0_1) -> τ_0_1 ()
#92 0x00000001d4b70d10 in partial apply forwarder for closure #1 (Swift.UnsafeMutablePointer) -> τ_1_1 in SwiftUI.LayoutEngineBox.mutateEngine(as: τ_1_0.Kind, do: (inout τ_1_0) -> τ_1_1) -> τ_1_1 ()
#93 0x00000001d48c9288 in withUnsafePointer ()
#94 0x00000001d4b6fe08 in mutateEngine ()
#95 0x00000001d49318d4 in generic specialization  of SwiftUI.UnaryChildGeometry.worth.getter : SwiftUI.ViewGeometry ()
#96 0x00000001d49413a4 in merged generic specialization > of implicit closure #1 (Swift.UnsafeMutableRawPointer, __C.AGAttribute) -> () in closure #1 () -> (Swift.UnsafeMutableRawPointer, __C.AGAttribute) -> () in closure #1 (Swift.UnsafePointer) -> AttributeGraph.Attribute in AttributeGraph.Attribute.init(τ_1_0) -> AttributeGraph.Attribute ()
#97 0x00000001c00ca438 in AG::Graph::UpdateStack::replace ()
#98 0x00000001c00cac04 in AG::Graph::update_attribute ()
#99 0x00000001c00d80b4 in AG::Subgraph::replace ()
#100    0x00000001d4d6f118 in SwiftUI.ViewGraph.updateOutputs(async: Swift.Bool) -> () ()
#101    0x00000001d4d6f618 in closure #2 () -> () in SwiftUI.ViewGraph.updateOutputsAsync(at: SwiftUI.Time) -> Swift.Optionally available ()
#102    0x00000001c00e70f8 in AGGraphWithMainThreadHandler ()
#103    0x00000001d4d69a90 in updateOutputsAsync ()
#104    0x00000001d4d643c4 in renderAsync ()
#105    0x00000001d3b436d4 in displayLinkTimer ()
#106    0x00000001d3b43eb4 in SwiftUI.DisplayLink.displayLinkTimer(__C.CADisplayLink) -> () ()
#107    0x00000001d3b444c0 in @objc SwiftUI.DisplayLink.displayLinkTimer(__C.CADisplayLink) -> () ()
#108    0x000000018b3e2e44 in CA::Show::DisplayLinkItem::dispatch_ ()
#109    0x000000018b3def44 in CA::Show::DisplayLink::dispatch_items ()
#110    0x000000018b4e7a40 in display_timer_callback ()
#111    0x00000001803ed914 in __CFMachPortPerform ()
#112    0x0000000180429a6c in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#113    0x0000000180429084 in __CFRunLoopDoSource1 ()
#114    0x000000018042397c in __CFRunLoopRun ()
#115    0x0000000180422cec in CFRunLoopRunSpecific ()
#116    0x0000000180f0e38c in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] ()
#117    0x0000000180f0e55c in -[NSRunLoop(NSRunLoop) run] ()
#118    0x00000001d3b45830 in perform signature specialization  of static SwiftUI.DisplayLink.asyncThread(arg: Swift.Optionally available) -> () ()
#119    0x00000001d3b44520 in @objc static SwiftUI.DisplayLink.asyncThread(arg: Swift.Optionally available) -> () ()
#120    0x0000000180f35148 in __NSThread__start__ ()
#121    0x0000000102cee5f0 in _pthread_start ()

The warning that’s seen when operating on the iPhone 15 simulator with iOS 17.5 is as follows:

warning: information race detected: @MainActor perform at StackOverflow/ContentView.swift:52 was not referred to as on the principle thread

Line 52 is the ForEach contained in the perform itemList.

It appears to me that this have to be a SwiftUI bug, particularly since it is just underneath sure circumstances. For instance, the problem will not be seen when any of the next modifications are made:

  • a distinct textual content dimension is used
  • the second textual content merchandise is shorter (1 line as a substitute of three)
  • any 1 of the three views inside ViewthatFits is commented out
  • vertical padding is added to the chevron
  • the chevron is faraway from view.

These modifications should not fixing the issue, they’re simply stopping it from occurring for the setup described. So I would like a extra dependable repair. Specifically, I’m questioning if there could be a method to stop the issue with some sort of annotation or actor directive within the code?

How can the code be fastened in order that the problems should not seen when operating as described?

Cisco & KDDI Ship Japan’s First Absolutely Managed SASE


The evolution of digital enterprise—pushed by distant work, cloud adoption, and the necessity for safe connectivity—has made safe, seamless entry extra important and extra complicated than ever. Safe Entry Service Edge (SASE) is redefining how organizations shield customers and knowledge throughout distributed environments. Service suppliers play an important position in accelerating SASE adoption by delivering scalable, built-in, and easy-to-manage options that align with at the moment’s fashionable department architectures.

We’re excited to announce a serious milestone in our partnership with KDDI, one in every of Japan’s largest telecom and ICT service suppliers. Not too long ago, KDDI introduced its launch of Japan’s first totally managed, single-vendor SASE resolution, powered by Cisco. This announcement highlights the increasing affect of our collaboration and demonstrates our shared dedication to advancing safe, cloud-delivered networking for enterprises. On this weblog, we’ll discover how partnerships just like the one between Cisco and KDDI are accelerating SASE adoption throughout world enterprises.

Service suppliers convey world attain, deep networking experience, and sturdy managed companies, making them splendid companions for organizations navigating SASE adoption. By leveraging options from main distributors, service suppliers may help companies streamline the transition to SASE, scale back operational complexity, and safe their branches, customers, and cloud functions—all by a single, unified platform.

Cisco is a acknowledged chief in single-vendor SASE, combining industry-leading networking and safety capabilities right into a cohesive cloud-delivered service. Cisco SASE empowers organizations to attach branches, safe distant employees, and shield cloud functions—all with centralized visibility and administration. The end result: branches which might be agile, safe, and future-ready.

  • Unified Administration: One platform for networking and safety, decreasing complexity and operational overhead.
  • Constant Safety: Finish-to-end visibility and safety, regardless of the place customers or functions reside.
  • Scalability: Simply broaden to new branches or distant customers with out infrastructure complications.
  • Optimized Efficiency: Built-in SD-WAN delivers dependable, high-performance connectivity.
  • Sooner Innovation: Speedy deployment of latest options and safety updates throughout the enterprise.

KDDI, a serious Japanese service supplier, in partnership with Cisco, is now delivering Japan’s first totally managed, single-vendor SASE resolution. KDDI makes use of Cisco’s SASE resolution to offer companies with seamless, safe connectivity throughout department places of work, distant customers, and cloud functions. KDDI’s single-vendor strategy with Cisco allows fast deployment, centralized coverage administration, and high-performance networking, making certain sturdy safety whereas decreasing operational complexity for purchasers navigating digital transformation.

“By way of our partnership with Cisco, KDDI is proud to supply Japan’s first totally managed, Cisco single-vendor SASE resolution. By integrating zero belief entry capabilities, corresponding to steady verification and safe, identity-based entry to functions from Cisco Safe Entry with our enterprise community companies utilizing Cisco SD-WAN’s cloud-managed, SASE-ready structure, centralized coverage management, built-in safety and real-time software optimization, we get rid of the complexity of multi-vendor environments and ship a seamless, safe expertise for companies embracing hybrid work. This marks a major step ahead in simplifying safety operations whereas accelerating zero belief adoption throughout the Japanese market.”

Junji Hori, Basic Supervisor Product Division Enterprise Answer Division, KDDI

Be taught extra: KDDI Launches Cisco SASE Answer (Japanese)

TKC Company, a number one Japanese firm supporting over 10,000 tax professionals and entities makes use of Cisco’s Safe Entry to implement a single-vendor SASE resolution, changing its legacy VPN system for two,800+ customers. Going through tight timelines and excessive confidentiality wants, TKC adopted Cisco’s cloud-first, zero-trust strategy. The answer mixed steady person authentication and identity-driven, safe software entry through Cisco Safe Entry with Cisco SD-WAN’s cloud-managed, zero-trust community structure, centralized coverage enforcement, and built-in security measures. A unified shopper and console simplified operations for safety lowered reliance on a number of instruments. This contemporary, cloud-managed structure lowered complexity and delivered cost-efficient, scalable connectivity.

Hiroyo Ichikawa, Director of IT Funding Planning for TKC Company, stated, “Gone are the times of complicated processes like equipment procurement, website planning, and complicated deployments. Having the ability to launch shortly made the advantages of cloud deployment – like utilizing a cloud-based VPNaaS vs. an on-premises VPN – very tangible for us.”

Be taught extra: From Legacy VPN to Cloud-First Safety: How TKC has Strengthened Safety and Decreased Complexity (Case Research)

A number one monetary agency turned to its service supplier and Cisco SASE to help a distant workforce and keep regulatory compliance. The one-vendor resolution supplied safe distant entry, knowledge loss prevention, and real-time menace detection, all whereas making certain a constant person expertise throughout places of work and residential networks.

As organizations redefine their department architectures to fulfill the calls for of a digital-first world, Service Suppliers worldwide are leveraging Cisco networking and safety options and driving SASE adoption. With single-vendor SASE, companies achieve the simplicity, safety, and scalability they should innovate and thrive—at the moment and into the longer term.

Discover Cisco SASE to study extra.


We’d love to listen to what you suppose! Ask a query and keep linked with Cisco Safety on social media.

Cisco Safety Social Media

LinkedIn
Fb
Instagram

Share:



ios – ToolbarItemGroup .bottomBar placement not exhibiting up in FileDocument


I am having bother getting a ToolbarItemGroup positioned on the backside of the display with .bottomBar placement in a FileDocument app.

Instance code under exhibits the problem. Situation seems on iOS 18.6.1 {hardware} and likewise iOS 18.5 simulator.

The toolbar is displayed with different placement values akin to .computerized.
Additionally, the toolbar is positioned accurately utilizing .bottomBar within the ContentView’s preview.

This difficulty is definitely simply the beginning of debugging a bigger mission that has the .bottomBar toolbar disappear (seemingly randomly) after a couple of minutes of the app working. Nevertheless, I doubt I can debug the bigger mission with out understanding the above difficulty.

Any recommendation?

import SwiftUI
import UniformTypeIdentifiers

@foremost
struct toolbar_debugApp: App {
    var physique: some Scene {
        DocumentGroup(newDocument: toolbar_debugDocument()) { file in
            ContentView(doc: file.$doc)
        }
    }
}

struct ContentView: View {
    @Binding var doc: toolbar_debugDocument

    var physique: some View {
            Textual content(doc.textual content)
            .toolbar() {
                ToolbarItemGroup(placement: .computerized) {
                HStack{
                    Button("Open") { print("Open!")}
                    Spacer()
                    Button("Save") { print("Save!")}
                }
            }
        }
    }
}

extension UTType { static var exampleText: UTType { UTType(importedAs: "com.instance.plain-text") } }
struct toolbar_debugDocument: FileDocument {
    var textual content: String
    init(textual content: String = "Good day, world!") { self.textual content = textual content }
    static var readableContentTypes: [UTType] { [.exampleText] }
    init(configuration: ReadConfiguration) throws {
        guard let information = configuration.file.regularFileContents,
              let string = String(information: information, encoding: .utf8)
        else {
            throw CocoaError(.fileReadCorruptFile)
        }
        textual content = string
    }
    func fileWrapper(configuration: WriteConfiguration) throws -> FileWrapper {
        let information = textual content.information(utilizing: .utf8)!
        return .init(regularFileWithContents: information)
    }
}

aws – SRS v6 Docker Cluster – WebRTC Fails Whereas FLV/HLS Work


I’m organising an SRS origin-edge cluster utilizing Docker. I need to publish a single RTMP stream to the origin and play it again on the proxy utilizing HTTP-FLV, HLS, and WebRTC. My motivation is that once I stream a number of cameras with WebRTC via my AWS server, the second digicam experiences latency. From my understanding, SRS works on a single thread which may create points. Thus, I made a decision to make use of multi-containers system (Please let me know if there are higher methods to do!). For now, I’m simply attempting two containers:

  1. origin that receives the stream
  2. proxy that pulls the stream from origin and stream on an html web page

I used to be capable of:

  • Setup a single-container setup works completely for all protocols (FLV, HLS, and WebRTC).
  • Create a multi-container setup, HTTP-FLV and HLS playback works accurately, which proves the stream is being pulled from the origin to the proxy.

My drawback:

WebRTC playback is the one factor that fails. The browser makes a profitable connection to the proxy (logs present connection established), however no video ever seems. The proxy log exhibits it connects to the origin to tug the stream, however the connection then instances out or fails with a video parsing error (avc demux annexb : not annexb).

My docker-compose.yml:

model: '3.8'
networks:
  srs-net:
    driver: bridge
companies:
  srs-origin:
    picture: ossrs/srs:6
    container_name: srs-origin
    networks: [srs-net]
    ports: ["1936:1935"]
    expose:
      - "1935"
    volumes: ["./origin.conf:/usr/local/srs/conf/srs.conf:ro"]
    command: ["./objs/srs", "-c", "conf/srs.conf"]
    restart: unless-stopped      
  srs-proxy:
    picture: ossrs/srs:6
    container_name: srs-proxy
    networks: ["srs-net"]
    ports:
      - "1935:1935"
      - "1985:1985"
      - "8000:8000/udp"
      - "8080:8080"
    depends_on:
      - srs-origin
    volumes: 
      - "./proxy.conf:/usr/native/srs/conf/srs.conf:ro"
      - "./html:/usr/native/srs/html"
    command: ["./objs/srs", "-c", "conf/srs.conf"]
    restart: unless-stopped

origin.conf:

hear 1935;
daemon off;
srs_log_tank console;
srs_log_level hint;

vhost __defaultVhost__ {
}

proxy.conf:

hear              1935;
max_connections     1000;
daemon              off;
srs_log_tank        console;
srs_log_level       hint;

http_server {
    enabled         on;
    hear          8080;
    dir             ./html;
    crossdomain     on;
}

http_api {
    enabled         on;
    hear          1985;
    crossdomain     on;
}

rtc_server {
    enabled         on;
    hear          8000;
    candidate      xxx.xxx.xxx.xxx; # IP tackle
}

vhost __defaultVhost__ {
    enabled         on;

    # Allow cluster mode to tug from the origin server
    cluster {
        mode            distant;
        origin          srs-origin:1935;
    }

    # Low latency settings
    play {
        gop_cache       off;
        queue_length    1;
        mw_latency      50;
    }

    # WebRTC configuration (Not working)
    rtc {
        enabled         on;
        rtmp_to_rtc     on;
        rtc_to_rtmp     off;
        
        # Essential for SRS v6
        bframe          discard;
        keep_bframe     off;
    }

    # HTTP-FLV (working)
    http_remux {
        enabled     on;
        mount       /[app]/[stream].flv;
    }
    
    # HLS (working)
    hls {
        enabled         on;
        hls_path        ./html;
        hls_fragment    3;
        hls_window      9;
    }
}

The ffmpeg pipe I exploit in my python code from my host machine to push video frames to my AWS server:

IP_ADDRESS      = ip_address
        RTMP_SERVER_URL = f"rtmp://{IP_ADDRESS}:1936/reside/Camera_0"
        BITRATE_KBPS    = bitrate # Goal bitrate for the output stream (2 Mbps)
        # Threading and queue for body processing
        ffmpeg_cmd = [
            'ffmpeg',
            '-y',
            '-f', 'rawvideo',
            '-vcodec', 'rawvideo',
            '-pix_fmt', 'bgr24',
            '-s', f'{self.frame_width}x{self.frame_height}',
            '-r', str(self.camera_fps),
            '-i', '-',

            # Add audio source (silent audio if no mic)
            '-f', 'lavfi',
            '-i', 'anullsrc=channel_layout=stereo:sample_rate=44100',

            # Video encoding
            '-c:v', 'libx264',
            '-preset', 'ultrafast',
            '-tune', 'zerolatency',
            '-pix_fmt', 'yuv420p',
            # Keyframe interval: 1 second. Consider 0.5s if still high, but increases bitrate.
            '-g', str(2*self.camera_fps), 
            # Force no B-frames (zerolatency should handle this, but explicit is sometimes better)
            '-bf', '0', 
            '-profile:v', 'baseline',   # Necessary for apple devices 

            # Specific libx264 options for latency (often implied by zerolatency, but can be explicit)
            # Add options to explicitly disable features not in Baseline profile,
            # ensuring maximum compatibility and avoiding implicit enabling by preset.
            '-x264-params', 'cabac=0:ref=1:nal-hrd=cbr:force-cfr=1:no-mbtree=1:slice-max-size=1500', 
            # Force keyframes only if input allows (might not be practical for camera input)
            '-keyint_min', str(self.camera_fps), # Ensure minimum distance is also 1 second
            
            # Rate control and buffering for low latency
            '-b:v', f'{BITRATE_KBPS}k',         # Your target bitrate (e.g., 1000k)
            '-maxrate', f'{BITRATE_KBPS * 1.2}k', # Slightly higher maxrate than bitrate
            '-bufsize', f'{BITRATE_KBPS * 1.5}k', # Buffer size related to maxrate
            
            '-f', 'flv',
            RTMP_SERVER_URL
        ]

self.ffmpeg_process = subprocess.Popen(ffmpeg_cmd, stdin=subprocess.PIPE, stdout=subprocess.DEVNULL, stderr=subprocess.PIPE, bufsize=10**5)

ios – Why doesn’t calling serialQueue.sync() end in a impasse?


Whereas finding out DispatchQueue, I got here throughout one thing I don’t fairly perceive.

I created a customized serial queue and executed a synchronous block on it. After I printed the thread that was working the block, it turned out to be the principle thread. This confused me, as a result of the queue wasn’t the principle queue, but the block nonetheless executed on the principle thread.

let serialQueue = DispatchQueue(label: "serial.queue")

serialQueue.sync {
    print("present thread = (Thread.present)") // present thread = _NSMainThread
}

Within the documentation for sync(), I discovered the next assertion:

As a efficiency optimization, this perform executes blocks on the
present thread at any time when attainable, with one exception: Blocks submitted
to the principle dispatch queue all the time run on the principle thread.

Primarily based on this description, I assumed that if the block was certainly executed on the present thread (the principle thread on this case), then a impasse ought to have occurred.

Right here’s the reasoning I had:

  1. The primary thread calls serialQueue.sync(). As a result of it’s synchronous, the principle thread turns into blocked till the block completes.
  2. The block is submitted to the serial queue, which then makes an attempt to execute it on the principle thread (the present thread).
  3. Nevertheless, because the essential thread is already blocked, it wouldn’t be capable to course of the duty, which ought to trigger a impasse.

However opposite to my expectation, no impasse occurred and the code executed simply high-quality. I can’t work out why.

Query.

  1. Why is a block executed on the principle thread though it was submitted to a customized serial queue?
  2. If, because the documentation suggests, sync() executes on the present thread as an optimization, why doesn’t this result in a impasse on this case?
  3. Can the principle thread nonetheless execute different duties whereas it’s blocked? I want to perceive how precisely the principle thread operates.