I've not seen the issue I'm having discussed here since iOS 16 dropped. I've added the axis: .vertical parameter to a TextField view to make it expand vertically, eliminating the need for a ZStack hack that accomplished the same previously. The automatic keyboard avoidance behavior that was working as-expected prior to adding the new parameter has ceased. When I tap in the TextField now, the keyboard jumps up and covers it. It again works correctly if I remove the axis parameter. Has anyone else seen this? Here's the code snippet in question: TextField("", text: $********.userNotes, axis: .vertical)    .placeHolder(Text("My notes"), show: ********.userNotes.isEmpty)    .autocapitalization(.sentences)\    .textFieldStyle(CustomTextFieldStyle())    .background(Color(profile.appData.colorTheme.editableTextFieldColor))    .frame(width: UIDevice.current.userInterfaceIdiom == .pad ? 240 : 280)

I’ve developed a SwiftUI-based iOS recipe app (in Xcode 12, requiring iOS 14) and would like to be able to share recipes with other users of my app. I invoke a share sheet in code that successfully shares out a JSON-encoded object, but I’m puzzled at how to let a user consume that object via email, AirDrop, or Messages. I see the onOpenURL modifier, and the share extension, but don’t know which to use to 1. Make my app’s icon appear in the list of eligible receivers for my shared object, and 2. Consume the object. I’ve also read about developers having trouble importing from Messages. Should I be looking at creating a Messages extension, too?

Greetings, I'm developing a recipe app to learn SwiftUI. It persists the user's recipe data with Core Data, recently adding CloudKit support by switching the container type to NSPersistentClouKitContainer and adding history tracking and a merge policy. Upon installation the app instantiates a persistent store with a sizable set of recipe items from a bundled JSON file, which are eventually successfully synced to iCloud. Upon installing on a *second* simulator/device, though, the JSON-supplied data is eventually duplicated in the local persistent store when an iCloud sync happens, which takes about nine minutes to occur. Two questions, then: I thought that by setting NSPersistentHistoryTrackingKey true and setting a merge policy of NSMergeByPropertyStoreTrumpMergePolicy, Core Data+Cloudkit would prevent such duplication by comparing attribute by attribute per record. The data from each installation are identical...do I have to handle duplication control manually? If so, what, then, is the point of having a merge policy? Second, why does iCloud sync consistently take nine minutes to sync the cloud-based data to the local store on the second and subsequent installations? I'd skip using the JSON-based data if that sync happened in a minute or so. Changing the size of the cloud-based data by beginning with a smaller JSON file has no effect on how long sync takes to begin trickling in data. I'm at a loss as to what the best practice is for instantiating and maintaining data on subsequent installations.