A Summary of the WWDC25 Group Lab

I’ve updated to iPadOS 18.6 on the devices currently available to me, and the Local Network permission now appears to be working correctly in the extension. I’ll be able to run the full test suite in our lab environment within 24 hours to confirm this. If everything checks out, I’ll mark this as resolved.

I've only been able to get simultaneous animations playing on a rigged model by using hard-coded FromToByAnimations and ensuring that the animations do not have any collisions in terms of which joints they are animating. Then when using playAnimation, passing a blend layer offset to the each animation group. But I have not tried this approach of using Blend shapes from Blender

Hello! I was able to get a couple of patterns down for glass in charts; some through views and others with chart-specific protocols. here's an example .annotation: extension Charting.Views.Stock.Selection { struct Annotation: View { private let low: Double private let high: Double private let open: Double private let close: Double private let gain: Bool private var time: String public init(_ data: Charting.Model.Candle) { self.low = data.low self.high = data.high self.open = data.open self.close = data.close self.gain = data.gain self.time = data.date.formatted(.dateTime.hour().minute().timeZone(.exemplarLocation)) } @Environment(.colorScheme) private var colors var body: some View { VStack(alignment: .leading) { Group { HStack { Text(Low).font(.caption) Spacer() Text(low, format: .currency(code: USD)) } HStack { Text(High).font(.caption) Spacer() Text(high, format: .currency(code: USD)) } Divider() HStack { Text(Open).font(.caption) Spacer() Text(open, format: .currency(code: USD)) } HStack { Text(C

Thank you! So you are right, I was not starting the daemon, just loading it. I am also able to manually run it, but it required full-disk-access to the Terminal app! We also are creating a FAT binary to run on both Intel and Apple Silicon, so I will test that next. By the way, the examples are seriously lacking in detail - even your example. It took a long time to reproduce simply because there are missing steps. For example, the creating a new application DOES NOT create an Info.plist. That took a while to figure out. Telling someone to delete a key that shows up in that file doesn't really make any sense, particularly when they are not called the same thing in the Info tab in the project settings. Another thing is that once I added the ES code, it would not build because you also need to link the library for it. There were a few other things as well - such as telling me to delete main.storybook, or other things that actually had no extension showing in the project file list. Finally, my main confusion left

Thank you for responding! metadata.json from the .fmadapter package: { adapterIdentifier: fmadapter-foundation-lab-9799725, author: Foundation Lab, baseModelSignature: 9799725ff8e851184037110b422d891ad3b92ec1, creatorDefined: {}, description: Tool adapter., license: , loraRank: 32, speculativeDecodingDraftTokenCount: 5 } Code used to load the adapter: // From test-adapter-minimal.swift:39 let adapter = try SystemLanguageModel.Adapter(fileURL: adapterURL) // Also tried the name-based initializer: adapter = try await SystemLanguageModel.Adapter(name: adapterName) Please help make progress here. Thank you!

It is as-designed that a watchOS app can only start a new extended runtime session (WKExtendedRuntimeSession) when it runs in the foreground and is active, and that it can only schedule one session at a time. (Note that a frontmost app can run in the foreground, but is not active.) For anything beyond that, I’d suggest that you file a feedback report with your use case. Specific to smart alarms, we introduced AlarmKit in WWDC25, which is available in iOS 26 but can forward the alarm presentation to a paired watch when an alarm occurs. You might take a look if that fits your use case. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Aren't new features the same as enhancements? Usually the delicate part is bug fixes. Those would get applied to older, currently shipping code. You could do them either in a branch or in main, but the idea is that, one way or another, bug fixes will relatively quickly update the main branch. Then the delicate part is making sure that any pending branches are compatible with those bug fixes. In theory, since they're still pending, that's easy to do. At that point, you know about the bug and can fix any new code, while merging the fixes in the new main. But it's all based on what you're comfortable with and what you can manage. Working as a lone developer, I wouldn't do a new branch for anything unless it was going to require weeks of effort and/or substantial changes/extensive testing. But back in the day, with 600 developers on a project, everything went into its own branch and the SCM team managed that. Testing was no big deal because we had a very large testing group and months-long test procedure