I tried to modify CustomLayoutProject in order to create some kind of ZStack which resizes child views to size of the largest one and positions them one over another with some vertical offset. And I'm stuck. Setup is next: I've created EqualSizeZStack: Layout and put in instead of ButtonStack() in ContentView like this: EqualSizeZStack { Buttons() }.border(.blue) I've restricted buttons width by setting their text width .frame(width: 200) instead of .frame(maxWidth: .infinity). Updated Goldfish model text to be 4x longer, so related button can grow up in restricted width (and it does). Layout container gets requested height, and largest size is calculated and assigned correctly (this logic was not changed). But smaller buttons just refuse to apply largest button size no matter what I do. What did I miss? func placeSubviews(in bounds: CGRect, proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) { guard !subviews.isEmpty else { return } let maxSize = maxSize(subviews: subviews) let placementProposal = ProposedViewSize(width: maxSize.width, height: maxSize.height) var nextY = bounds.minY for index in subviews.indices { subviews[index].place( at: CGPoint(x: bounds.midX, y: nextY), anchor: .top, proposal: placementProposal) nextY += vOffset } }

I have a universal iPad / iPhone application which presents different interface for .regular and .compact horizontal size classes. The architecture of the app is similar to this refined example: import SwiftUI struct CompactView: View { var body: some View { Text("CompactView") } } struct ContentView: View { @Environment(\.horizontalSizeClass) var horizontalSizeClass var body: some View { Group { if horizontalSizeClass == .regular { NavigationSplitView { Text("Sidebar") } detail: { Text("Detail") } } else { CompactView() .onAppear { print("Why am I here?") } } } .onChange(of: horizontalSizeClass) { newValue in print("Size class: \(newValue!), app state: \(UIApplication.shared.applicationState)") } } } Recently I've discovered a strange behaviour: when user presses home button on iPad, application interface changes its horizontalSizeClass from .regular to .compact and back to .regular for a moment when entering background state. And it's sufficient to lose all transient state including presented modals with their state. The console output for this example in described case is: Size class: compact, app state: UIApplicationState(rawValue: 2) Why am I here? Size class: regular, app state: UIApplicationState(rawValue: 2) Could anybody explain why this is happening or give any relevant reference? Yes, I'm aware of the split mode and multitasking and that iPad interface transitions to .compact in those cases. But my question relates to only this one specific case: is this an expected behaviour (and if yes, then why)? Or is it an SDK bug? Thanks.

A have the application with iOS and Mac Catalyst versions and I need to make a cloud client for the app's documents. FileProvider would be the great choice for this feature, but I can't believe it doesn't support Mac Catalyst. At this moment I'm almost certain that NSFileProviderReplicatedExtension does not support Mac catalyst officially. And if it so, It would be great to hear the exact status and future plans if any. Unofficially, I managed to run it. I switched the extension's target Supported Destination from Mac Catalyst to Mac and it started to compile. This move seems legit to me. But domain also had to be created, and this part was a way trickier. I've added new bundle to host app(iOS and catalyst), but with supported platform - macOS in build settings. There I created an NSObject subclass DomainManager which calls NSFileProviderManager's addDomain method in its createDomainIfNeeded(), which is also exposed in public extension to NSObject - a kind of "informal protocol" The catalyst app creates bundle by name and loads principal class (DomainManager), but as NSObject reference, and then calls createDomainIfNeeded() method on it. The location defined by domain appears in Finder sidebar, and the dataless item "a file" appears in this location, as defined by stub implementation in the extension enumerator method. This means file system instantiated the extension instance under Mac catalyst and called the protocol method on it. I.e. it seem to work. But the question is whether this solution is stable and legit for the App Store distribution. Or is it pandora box with unforeseeable consequences for user data? Thanks in advance.