A Summary of the WWDC25 Group Lab

I haven't been able to find much in the documentation on whether this behavior is enforced in classificationResponse handlers. Apple's barebones page on SMS and Call Spam Reporting[1] says the system always deletes your extension’s container after your extension terminates, but that doesn't answer whether you can write to an App Group container. No, you cannot. This could have been more directly stated, but this is basically implementing one of the strongest possible restrictions* around your extension. For comparison, the filter data provider extension, which can examine the contents of all network traffic, is allowed to write to its data container but cannot write ANYWHERE else on the system (nor can its container be read). ILClassificationUIExtensionViewController takes that level of protection one step further and doesn't even preserve your app’s own container. *We could have simply blocked writing, but I suspect container writing was allowed to provide a bit more implementation flexibility. For

Here's what we said in WWDC25 Platforms State of the Union: As you evaluate your app's UI and the time you need to adopt the new design, we're providing an option to continue to use your app's current design with Xcode 26. We intend this option to be removed in the next major release. — Ed Ford,  DTS Engineer

[quote='860281022, RickMaddy, /thread/787500?answerId=860281022#860281022, /profile/RickMaddy'] where does this all stand? [/quote] For a summary of the current state of the issues being discussed in this thread, see my 27 Aug 2025 reply. However, your questions extend beyond that, so let’s dig in. [quote='860281022, RickMaddy, /thread/787500?answerId=860281022#860281022, /profile/RickMaddy'] is there any viable way for a solo developer with one Mac to develop and test a macOS app that runs on more than one version of macOS? [/quote] Yes. As marco.masser suggested, you can boot your Mac into older versions of macOS and test there. I want to stress that, while VMs are super useful, they are not a substitute for testing on real hardware [1]. VMs have limits: Some are bugs, as we’ve been discussing on this thread. Some of them are absent features. Of these, the lack of TestFlight support is the most critical. I’ll come back to that below. Some of them are just fundamental to VMs. For example, if you’re

After a bunch of more digging around, I am finally getting a little traction on how to create a SwiftUI interface. And I am posting this here in hopes of helping someone else in my position. struct MyCustomView: View { @State private var volume: Double = 0 var body: some View { Group { HStack { Text(oo) .padding(2) .border(Color.black) Button(Stop) { } Button(Play) { } Button(Jump) { } } .padding(.top, 10) VStack { Slider(value: $volume, in: -10...100) .offset(x: 13,y: 0) .frame(width: 150, height: 40) } } .offset(x: -150, y: 0) } } I did a screenshot of a portion of the original music player controls and the same thing using SwiftUI. Now there is the basis for improving the SwiftUI code to better match that of the original screen. I hope this helps someone else.

I've often used serial-to-USB converters connected to a Mac, and not had reliability problems with them. I like to use the Silabs CP2104. Silicon Labs have drivers for these for various platforms. Your code need to know the /dev name of the serial device, which you can derive by inspection in your case (just plug it in, install the driver, list /dev). To get things going, you can use a terminal emulator like CoolTerm. The Modbus RTU protocol is well described in the documentation you linked. If I were you, I'd make a command line tool written in Python which reads one displacement value from the voltmeter. I'd utilize that tool into my app's bundle and call it from there. Since I don't use Python very often and the problem is simple, I'd ask an LLM to write the program for me. you said although the instrument is displaying 0.000 volts, the data collected changes at each message I send to the instrument, proving me that Modbus RTU set up is not working. but what does the data you collected actually re

I'm having the exact same problem. Keys are created in https://appstoreconnect.apple.com/access/integrations/api with sufficient access permissions. To eliminate all potential misdoings on my side I used altool to generate the JWTs for API requests: JWT=$(xcrun altool --generate-jwt --apiKey ${APP_STORE_CONNECT_KEY_IDENTIFIER} --apiIssuer ${APP_STORE_CONNECT_ISSUER_ID} 2>&1 | tail -1) With the generated JSON Web Token I can successfully access endpoints such as List Apps 10:56:08 priit@marmot ~ curl -H Authorization: Bearer ${JWT} https://api.appstoreconnect.apple.com/v1/apps | jq '.meta' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 10945 100 10945 0 0 15788 0 --:--:-- --:--:-- --:--:-- 15770 { paging: { total: 1, limit: 50 } } and List Users 10:56:35 priit@marmot ~ curl -H Authorization: Bearer ${JWT} https://api.appstoreconnect.apple.com/v1/users | jq '.data[] | .attributes.roles' % Total % Received % Xferd Average Speed Time Time Time Curren

I can confirm this is not reproduced in a virtual machine running 15.6_24G84 (btw cannot find 15.7 (24G222) for download). As previously written to DTS this was not reproduced in 26.0_25A5327h either and the reason was this was also tested in a clean virtual machine. On the installation this is reproduced running 15.7 (24G222) the folder in ~/Library/Group Containers has indeed a .com.apple.containermanagerd.metadata.plist file with faulty, cached MCMMetadataIdentifier key referencing a different team identifier that was used for testing at some point.

A colleague pointed out that I did't quite get the details right here. But, nonetheless the key thing to know is that any app groups created in a previous developer account will not follow an app to a new developer account after an app transfer. Any data stored using an app group created in a previous developer account will not be accessible after an app transfer even if you use the same app group names. Here are the corrected details: App group IDs never start with an App ID prefix. Rather: iOS-style app group IDs start with group. macOS-style app group IDs start with the Team ID. To read more, please see the forums thread App Groups: macOS vs iOS: Working Towards Harmony