“translate scheme”

At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for Apple Intelligence. Can I integrate writing tools in my own text editor? UITextView, NSTextView, and SwiftUI TextEditor automatically get Writing Tools on devices that support Apple Intelligence. For custom text editors, check out Enhancing your custom text engine with Writing Tools. Given that Foundation Models are on-device, how will Apple update the models over time? And how should we test our app against the model updates? Model updates are in sync with OS updates. As for testing with updated models, watch our WWDC session about prompt engineering and safety, and read the Human Interface Guidelines to understand best practices in prompting the on-device model. What

Since many users like me use Apple Music on Android, the app is almost as feature-rich as iOS. It would be fantastic if the developers could add the new iOS 26 features to the Android app, along with a minor UI change. I know it’s challenging to implement liquid glass on Android hardware or design, but features like auto-mix, pronunciation, and translation could be added. kindly consider this request !!!!

Is there an API to query for OS Name based on major OS Version number or otherwise ?? For example : 15.5 translates to Sequoia

Hi everyone! I've considered this — what if Apple added a native system-wide feature in all of iOS, iPadOS, and macOS called “CrossRun” where you can natively execute non-App Store software like Windows or Linux apps natively on your device? But not in a sluggish emulator—this would use intelligent Apple-signed Just-In-Time (JIT) compilation inside the virtual containers, and the experience would actually perform fast and feel natural. This is my vision for CrossRun: Every developer, student, creative professional, and enterprise user who relies on specialized software—whether it’s legacy Windows tools, Linux-only applications, or vintage DOS and Classic Mac utilities—feels the pain of platform lock‑in. Artists can’t run niche Linux‑based graphics programs on their iPads. Engineers can’t test x64‑only binaries on Apple Silicon without juggling emulators. Retro‑gaming fans miss their favorite DOS titles. Even enterprises struggle to standardize on Apple hardware because critical Windows‑only applications won’t

Hi ! I'm currently stuck with an issue on Xcode, I'll try explain to the best I can :-) I have a workspace (that I need to keep that way, I can't split projects) that contains multiple projects. I have 2 frameworks : Core and Draw. Draw depends on Core. So far so good. I needed to create a test application that can be modular and link my framewok, but also other drawing frameworks. To that extend, I created a CardLIbrary framewok, and a CardAdapter framewok, and I linked them into the test application. Test App └── DrawCardAdapter │ └── CardAdapter │ └── CardLibrary │ └── Core │ └── TCA (SPM) │ └── Draw │ └── Core Here, all dependencies are local ones if not stated otherwise (for the SPM). CardLibrary is a framework that generates only UI (linked to Core for logging purposes, nothing fancy). I also added TCA which is a SPM dependency, it may generate some issues after. CardAdapter is an abstraction for CardLibrary. Basically, it acts as an interface between CardLibrary and Test Application. DrawCardAdapter is

In creating a sequenced gesture combining a LongPressGesture and a DragGesture, I found that the combined gesture exhibits two problems: The @GestureState does not properly update as the gesture progresses through its phases. Specifically, the updating(_:body:) closure (documented here) is only ever executed during the drag interaction. Long presses and drag-releases do not call the updating(_:body:) closure. Upon completing the long press gesture and activating the drag gesture, the drag gesture remains empty until the finger or cursor has moved. The expected behavior is for the drag gesture to begin even when its translation is of size .zero. This second problem – the nonexistence of a drag gesture once the long press has completed – prevents access to the location of the long-press-then-drag. Access to this location is critical for displaying to the user that the drag interaction has commenced. The below code is based on Apple's example presented here. I've highlighted the failure points in the co

When navigated to another view with a NavigationStack or NavigationView, the .navigationTitle modifying a List or Form containing a Map() gets quirky when trying to show the title. The back button is displayed correctly, but the title does not follow the same color scheme as the List of Form, rather it is white with a divider underneath it. It's like it is confusing the .inline with the .large navigation display modes. This doesn't just show up in the simulator, but on actual devices too. This is a test main view... import SwiftUI struct ContentView: View { var body: some View { NavigationStack { NavigationLink(destination: MapErrorView()) { Text(Map View) } } } } This is a test navigated view... import SwiftUI import MapKit struct MapErrorView: View { var body: some View { NavigationStack { Form { Section(header: Text(Map of the US States)) { Text(Map Error) Map() .frame(height: 220) } } .navigationTitle(Map Error) .navigationBarTitleDisplayMode(.large) } } } Attached is an image showing this error

At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for visionOS. I saw that there is a new way to add SwiftUI View attachments in my RealityView, what advantages does this have over the old way? Attachments can now be added directly to your entities with ViewAttachmentComponent. The removes the need to declare your attachments upfront in your RealityView initializer and then add those attachments as child entities. The new approach provides greater flexibility. Canyon Crosser and Petite Asteroids both utilize the new approach. ManipulationComponent looks really cool! Right now my app has a series of complicated custom gestures. What gestures does it handle for me exactly, and are there any situations where I should prefer m