This bug was fixed at some point in the beta cycle.

The latest beta positions the search bar at the top right on iPad by default, just like iPadOS 18. I tweaked the others based on user interface idiom to achieve the remaining desired positions on iPad.

Setting directionalLayoutMargins top/bottom to a number less than 15 (the default value) has no effect (even negative numbers). A number greater than 15 does increase it beyond the default margins. Seems the system enforces minimum vertical margins :/

Thanks, I should note I want to reduce the vertical margins in the cell as opposed to setting an absolute fixed height dimension, in order to properly support dynamic type text sizes. This is the compositional layout I'm using: let layout = UICollectionViewCompositionalLayout { sectionIndex, environment in let config = UICollectionLayoutListConfiguration(appearance: .insetGrouped) return NSCollectionLayoutSection.list(using: config, layoutEnvironment: environment) }

I would try to see if you can make MKAddressRepresentations work for your needs, and if you could present the customization options to your customers based that line up with what that class offers I'll pursue this route, thanks! Existing customers will need to change their settings to choose one of the predetermined formats that most closely matches their use case. As folks reach out to report what they can't achieve anymore, I can file feedback reports requesting more formats be added to MKAddressRepresentations. The only thing I'm struggling to come up with is a friendly name to show in the UI for selecting the predetermined format of "city with context" both the short and full variants. Best I have is City, City and State, or City and State and Region - the word "state" is probably not appropriate everywhere. 🤔 it is very easy to naively construct geographically incorrect place descriptions ... we want to discourage folks from doing these string concatenation techniques, and instead rely on the framework to provide you with the correctly formatted information through MKAddressRepresentations Makes sense! With the approach to select specific date components, I took inspiration from DateFormatter.setLocalizedDateFormatFromTemplate(_:) where you specify which components you want and you'll get an appropriately formatted localized string. I thought I achieved that fairly well by preserving the order of components in the postal address just filtering out undesired ones, but can certainly imagine there could be scenarios where the resulting string doesn't really work for different locations around the world. I did file FB8648023 (Template API desired to format addresses with different components, similar to DateFormatter.setLocalizedDateFormatFromTemplate) hoping to replace my solution with a native API, but maybe that's infeasible given address complexity?

Hi Ed! The use case in my app is to get the address for where a photo was taken. The user selects which address component(s) they want included. So I look at each attribute from the full attributed address to see if the CNPostalAddressPropertyAttribute is a component the user selected if so I add it to an array. Once enumeration is complete I join the array with commas to separate the components. For examples, if they selected zip it would be just 92101, or if they selected street and city and state it’d be 3835 N Harbor Dr, San Diego, CA. (The selected attributes aren’t guaranteed to be in the final string and that is acknowledged.)

Seems like a good bug report to me! I don’t see anything missing, or have an explanation for the different behavior, so seems it could be not working as expected.

Thanks, but in this app I don’t have a split view. No sidebar and no plans to add one.

Found it! .scrollEdgeEffectHidden(scrollEdgeEffectHidden, for: .top) does the trick setting scrollEdgeEffectHidden via .onScrollGeometryChange(for: CGFloat.self) looking at the geometry.contentOffset.y

+1 I too would like to know in what scenarios would it be successful but not verified. I’m ignoring that scenario in my app, not unlocking the content unless it’s a verified purchase.

It seems perform is not invoked because the system does not support showing request value dialogs to ask the user which object they want to edit when using this intent in a ControlWidget. Not sure if that's documented somewhere.

Thanks for all your help! 🙏

destroyPersistentStore isn't the right API that deletes the data lol Can you clarify what you mean by "destroy those CoreData object"?

Thank you, this is very helpful. To confirm we're aligned: Open the database in read-only mode If loadPersistentStores fails, try it again in read-write mode If that succeeds destroy those CoreData object and do a read-only open again If that fails show an error message to the user destroy those CoreData object Is that accomplished via container.persistentStoreCoordinator.destroyPersistentStore, so all together like so? let container = NSPersistentCloudKitContainer(name: "AppName") let sharedStoreURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.domain.appname")!.appendingPathComponent("\(container.name).sqlite") guard FileManager.default.fileExists(atPath: sharedStoreURL.path) else { // Show error to user return } let description = container.persistentStoreDescriptions.first! description.url = sharedStoreURL description.isReadOnly = true container.loadPersistentStores { description, error in if let error { container.persistentStoreDescriptions.first?.isReadOnly = false container.loadPersistentStores { description, error in if let error { // Show error to user } else { try? container.persistentStoreCoordinator.destroyPersistentStore(at: sharedStoreURL, type: .sqlite) container.persistentStoreDescriptions.first?.isReadOnly = true container.loadPersistentStores { description, error in if let error { // Show error to user } } } } } }

There is not. Releasing an app update always replaces the current version. Those users would have to update to the newer OS to get the newest update (which could require buying a new device). For that reason you typically would not increase the deployment target to 26 when it is released, you’d give time for your users to update first.