BTW Google gave me a workaround to this but with a caveat that it may not work long term. I put this modifier on my tabView and the tabs now appear along the bottom on iPad as well. .environment(.horizontalSizeClass, .compact)

I have't found any solutions so I have resorted to using TipViews where ever possible. They seem more reliable especially with slider controls which definitely don't play well with popover tips. I think TipKit still has a few kinks that need to be worked out. The concept is great but the flakiness is frustrating.

Could be the same issue. I tried reporting this directly to Apple with a request for Technical Assistance because I hadn't seen any other reports of this behavior. I had developed a SwiftData app that used CloudKit and therefore required all model relationships to be treated as optional. I was sorting an object using a relationship's title field (which was clearly optional) and this worked fine in all simulator and Xcode downloads with no issues. I didn't run into it until I tried using TestFlight to get some beta feedback and the app immediately crashed and the feedback was sparse so I took several months to finally track down what was causing it. I would certainly like to see this fixed because it creates limitations that only surface very late ih the app dev process which is very frustrating. If it shouldn't ever work then it should also crash in the simulator and any Xcode downloads IMHO.

I am not asking for help fixing a crash. I did that by commenting out one line of code where I was asking SwiftData to sort ModelA results on a title string from an associated ModelB object. ModeB has a one to many association to ModelA and must exist before any ModelA objects are created BUT CloudKit requires that you specify the relationships between these two models as Optional. Therefore when I tried to sort ModelA results by a Title in ModelB I needed to declare the property as a force unwrapped title of ModelB in the SortDescriptor. It would be ludicrous to try to show the actual code so that you can follow everything. Suffice it to say that this SortDescriptor was accepted by the compiler, and gave me exactly what I wanted when I ran the App either in a Simulator or on a device that downloaded the app from Xcode. BUT when the app was uploaded to the App Store and then downloaded from TestFlight the App would immediately crash with no useful error pointing to the problem. Bottom line is I found the issue after months of digging and now I just want to restore the capability I had before I had to comment out that line of code. As I said I tried using a computed property in ModelA (rather than store the title from ModelB it would fetch it when needed) and used that computed property as the sort descriptor but although this is also accepted by the compiler this fails as well. I suppose I can do a sort on the array AFTER it is fetched by SwiftData but that seems less efficient. Anyway wondering if anyone else has run into this limitation and has found a better workaround.

The code was exactly the same as I am using for all the tips I created (I have about 20 tips scattered across about 8 different views). All of these tips were originally setup as popover tips and I was using TipGroups to control the sequencing. All worked exactly as expected in the simulator but when I ran it on my physical device I started seeing the anomalies. Below is indicative of how I was invoking them all. One thing I did notice about the 2 tips that were displaying as sheets was that they were for buttons at the bottom of the view. Right above them was a list subview that was clearly taking up all the available screen real estate so it was as though the framework didn't think there was enough room to display them as popovers and resorted to using a sheet. There were some other anomalies attaching popovers to sliders. Either they didn't display properly or could not be dismissed. But NONE of this was a problem in the simulator! Everything worked just fine. In frustration I resorted to using TipView for the problematic Tips and I now have something that even though it is not completely consistent in the way tips are shown at least is is more predictable and that is better than having users get confused by popups either not appearing as expected or not being able to be dismissed (which of course throws off the TipGroup so that no subsequent tips in that group will ever appear). It's frustrating that you can spend a day to two setting something like this up and everything is working perfectly in the simulator and then when try it on a real device you need to spend another day trying to work around the anomalies. @State var groupTips = TipGroup(.ordered) { RecipeCardTip() InfoSheetTip() GetStartedTip() } //later in the code something like this is attached to a button .popoverTip(groupTips.currentTip as? GetStartedTip)

Well no thanks to Apple or anyone on here I did finally figure out what was causing the crash. It was something I had heard in passing in some Youtube video on SwiftData (I've watched so many I can't remember exactly where) I picked it up but it could well have been either Paul Hudson or Stewart Lynch said something about SwiftData not liking optionals in predicates. Well it turns out that I was using a title of an optional object (although the way the app is implemented this Optional is really optional) in a sortDescriptor and this is what was causing the issue. The super frustrating thing is it worked fine in both the simulator and locally downloaded from Xcode builds with not even a hint of a problem so the fact that it only showed up months into development when I finally decided to start external testing was unfortunate since by then the app was way more complicated and the errors reported via TestFlight were cryptic (Swifthdata Getter Exception?) How is that supposed to help one figure out what is going wrong. Also after months of wrestling this this I finally tried reaching out to Apple Developer Support and that was a black hole. NOT IMPRESSED!

UPDATE: Issue seems to be related to a view initializer and not to creating the Habit object. The view is part of the home view which is displayed immediately and this is what was causing the crash. I was able to get a version of the app to work with a simple ListView and no initializer and am now proceeding to add back the initializer one step at a time to find out what is the culprit. But again this issue never occurs in a build directly from Xcode so I need to add each new build to TestFlight to see if there is a problem. Wish I could get some Apple help on this... Seems like it does not like any Predicate in the initializer. Even this simple initializer causes a crash (but not when I use the Xcode build). init(navigationPath: Binding<NavigationPath>, searchString: String = "", sortOrder: [SortDescriptor<Habit>] = []) { _habits = Query(filter: #Predicate { habit in if searchString.isEmpty { true } else { habit.title.localizedStandardContains(searchString) || habit.detail.localizedStandardContains(searchString) } }, sort: sortOrder) self._navigationPath = navigationPath }

Thanks for the suggestion. Yes I am doing CloudKit syncing of the entire SwiftData store that includes all four model types. Not sure why if three of the models are working fine: to create, save, edit, delete why the fourth would crash the app but perhaps I am missing something more subtle. Also I did not alter any settings for CloudKit for dev vs production I simply turned it on (in Signing and Capabilities) and assumed it was working for both dev and production environments. How should I check that?