I've been successfully integrating the Foundation Models framework into my healthcare app using structured generation with @Generable schemas. While my initial testing (20-30 iterations) shows promising results, I need to validate consistency and reliability at scale before production deployment. Question Is there a recommended approach for automated, large-scale testing of Foundation Models responses? Specifically, I'm looking to: Automate 1000+ test iterations with consistent prompts and structured schemas Measure response consistency across identical inputs Validate structured output reliability (proper schema adherence, no generation failures) Collect performance metrics (TTFT, TPS) for optimization Specific Questions Framework Limitations: Are there any undocumented rate limits or thermal throttling considerations for rapid session creation/destruction? Performance Tools: Can Xcode's Foundation Models Instrument be used programmatically, or only through Instruments UI? Automation Integration: Any recommendations for integrating with testing frameworks? Session Reuse: Is it better to reuse a single LanguageModelSession or create fresh sessions for each test iteration? Use Case Context My wellness app provides medically safe activity recommendations based on user health profiles. The Foundation Models framework processes health context and generates structured recommendations for exercises, nutrition, and lifestyle activities. Given the safety implications of providing health-related guidance, I need rigorous validation to ensure the model consistently produces appropriate, well-formed recommendations across diverse user scenarios and health conditions. Has anyone in the community built similar large-scale testing infrastructure for Foundation Models? Any insights on best practices or potential pitfalls would be greatly appreciated.

I'm implementing a horizontal carousel in iOS 26 Beta 3 using SwiftUI ScrollView with LazyHStack. The goal is to programmatically scroll to a specific card on view load. What I'm trying to do: Display a horizontal carousel of cards using ScrollView + LazyHStack Automatically scroll to the "current" card when the view appears Use iOS 26's new ScrollPosition object for programmatic scrolling Current behavior: The ScrollPosition object receives scroll commands (confirmed via console logs) The scrollTo(id:anchor:) method executes without errors However, the ScrollView does not actually scroll - it remains at position 0 Manual scrolling and scrollTargetBehavior(.viewAligned) work perfectly Code snippet: @State private var scrollPositionObject = ScrollPosition() ScrollView(.horizontal) { LazyHStack(spacing: 16) { ForEach(cards, id: .id) { card in CardView(card: card) .id(card.id) } } .scrollTargetLayout() } .scrollPosition($scrollPositionObject) .scrollTargetBehavior(.viewAligned) .onAppear { let targetId = cards[currentIndex].id DispatchQueue.main.asyncAfter(deadline: .now() + 0.3) { scrollPositionObject.scrollTo(id: targetId, anchor: .center) } } Workaround that works: Using the iOS 17 scrollPosition(id:) binding instead of the ScrollPosition object: @State private var scrollPosition: UUID? .scrollPosition(id: $scrollPosition) .onAppear { scrollPosition = cards[currentIndex].id } Environment: iOS 26 Beta 3 Xcode 26 Beta 3 Physical device (iPhone 16 Pro Max) Is this a known issue with ScrollPosition in Beta 3, or am I missing something in the implementation? The older binding approach works fine, but I'd prefer to use the new ScrollPosition API if possible.

Testing Foundation Models framework with a health-focused recipe generation app. The on-device approach is appealing but performance is rough. Taking 20+ seconds just to get recipe name and description. Same content from Claude API: 4 seconds. I know it's beta and on-device has different tradeoffs, but this is approaching unusable territory for real-time user experience. The streaming helps psychologically but doesn't mask the underlying latency.The privacy/cost benefits are compelling but not if users abandon the feature before it completes. Anyone else seeing similar performance? Is this expected for beta, or are there optimization techniques I'm missing?