“translate scheme”

@dev24984 I do have same issue. floor.walls are not in same order, and there are inner walls. floor.polygonCorners is not oriented the same way (transform.eulerAngles.z and .y is 0) I attempted algoritm to calculate the distance of each wall, and between each polygonCorners , to try to match them If I find the matching wall, I get the angle to apply. I still use the floor.transform.position to position the floor correctly. -> distances are not exactly the same, so I have to do several pass to find the matching wall, with a difference increasing (0.01) -> it works as along as the walls are not identical else orientation can be 180 degres wrong and sometimes it fail entirely (round room) So unsure this is the way, unless I attempt to match inner walls as well. Else another idea could be to figure out the outer walls of the rooms, gather each translated end point, and make a surface out of it. if only apple has properly filled its transform for the floor :(

Is there a way to package the Java code to work on iOS and mani macOS without having to complicate the project to the point where it would be easier to rewrite the Java code in Swift and have to work harder to update the app on each platform separately? No, there is not. Perhaps this would be an opportunity to try an AI solution to translate from Java to Swift.

Proposal: Unify Native Utility Apps into One Modular, AI-Enhanced App – Apple Assist Hello Apple Developer Community, I’m an independent developer and researcher, and I’d like to share a proposal that could enhance usability, accessibility, and UI/UX cohesion across iOS, iPadOS, and watchOS. 🎯 Core Idea Unify Apple’s native utility apps into a single modular and intelligent experience, provisionally titled Apple Assist. This includes: Calculator Compass Voice Memos Magnifier Measure Weather Translate Apple News 💡 Why Apple Assist? Today, these apps are distributed separately and accessed individually. While functional, this segmentation may be unintuitive for multitasking, accessibility workflows, and contextual usage. Apple Assist would act as a central hub, using a modular interface powered by Apple Intelligence, allowing: Seamless access to key tools in a single space Smart suggestions based on time, location, or context (e.g., auto-open Magnifier in low light) Enhanced accessibility for elderly

For me the option 2 is not working (and option 1 is not really an option as we need to support older iOS versions). I followed the instructions, added the DYLD_FALLBACK_LIBRARY_PATH argument to the Run configuration of my scheme like this: DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Cryptexes/OS/usr/lib/swift But the app still crashed, and when it logs the dyld config, it prints this: DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/ So it seems my value for DYLD_FALLBACK_LIBRARY_PATH is just ignored. I checked it a thousand times and don't understand what I'm doing wrong. Is this working for other people too? Edit Found the solution, see comments if you run into the same problem.

Hello, You are right that LocalizedStringResource is the preferred way to pass around a localized string. In your Array example, it really depends on where you intend to use the array. For example, making the type an Array of LocalizedStringResource is valid and each string would get extracted to the String Catalog. However, this may impact the way you use the string in your SwiftUI code. If these are static options, an alternative could be to use an enum: enum Gender: Hashable, Identifiable, CaseIterable { case male case female case notDisclosed var displayName: LocalizedStringResource { switch self { case .male: Male … } } } … Picker(Gender, selection: $selectedGender) { ForEach(Gender.allCases) { gender in Text(gender.displayName) } } OR it may be that you have a dynamic list that the user is able to change, and these are just the default options. If that is the case, it may be easier to simply use String(localized:), which returns a plain String that is pre-localized. For example: @State private var gende

This issue is tracked in WebKit's bug tracker: https://bugs.webkit.org/show_bug.cgi?id=293831 Copying two workarounds listed there: At this time, there are some workarounds that developers can use for testing and debugging in iOS 18.5 simulator: Option 1: Change your app's deployment target to iOS 18.4 or later. Set IPHONEOS_DEPLOYMENT_TARGET = 18.4 in build settings, or use Xcode's UI: Select the app's target in a xcodeproj file, then go to General > Minimum Deployments > iOS and set it to 18.4. Rebuild the app. Option 2: Set DYLD_FALLBACK_LIBRARY_PATH in the app's run action. This will allow you to test in iOS 18.5 simulator while continuing to deploy to older OS versions. Find the simulator runtime's path using xcrun simctl list runtimes -v. It will be a path like /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime. Add Contents/Resources/RuntimeRoot/System/Cryptexes/OS/usr/lib/swift to this path. In Xcode, navigate to the launch ar

One other suggestion on all this. If you're starting on macOS, the other approach here would be to actually start by using the IOUSBHost Framework (instead of a DEXT) to sort out the basic control/command process, then porting that code into a DEXT. The framework says it: Create host-mode user space drivers for USB devices. ...but that's a very wordy way of saying lets an app directly talk to USB devices. The IOUSB Framework has the same API structure as USBDriverKit and IOKit, so it's relatively straightforward to translate the framework code you write into a DEXT. However, using the framework means: You're code is running in a standard app which you can directly debug. This also removes all DEXT loading issues/friction. Some of the code you'll be writing is code you'll end up writing anyway. For example, the IOKit code used to find the USB device you want to work with is exactly the same code you'd using on iPadOS to find and open your own user client. And, just like I discussed earlier, this code

I tried to make a new post but the forum doesn't allow it. let's try here..... I'm working on adding a card to Apple Wallet using push provisioning and facing a challenge during the final step. Here’s the overall flow I’m following: I initialize PKAddPaymentPassViewController using a properly configured PKAddPaymentPassRequestConfiguration, including properties such as: encryption scheme payment network cardholder name localized description primary account suffix style I receive the required input parameters and pass them through a service, which returns three base64-encoded strings: activation data, ephemeral public key, and encrypted data. I decode these strings into Data objects and use them to populate a PKAddPaymentPassRequest, then call the handler like this: swift let request = PKAddPaymentPassRequest() request.activationData = ... request.ephemeralPublicKey = ... request.encryptedPassData = ... handler(request) However, instead of completing the process, the user is presented with a message s

Confirmed on Xcode 16.4 (16F6). Bug symptoms are the same as previously mentioned: Xcode frequently launches duplicate processes when schema Run action is performed on a macOS command line tool executable that creates UI windows. It is a bug in Xcode due to following: The bug occurs when Debug executable is set under the Scheme -> Run -> Info tab. When Debug executable is unset, no duplicate processes are launched. No duplicate processes are launched when the executable is launched on terminal. Also confirmed that adding 350 ms delay in program main() is a workaround. For example, using SDL2 add SDL_Delay(350) at the top of the main() function. To Xcode team, let me know if you want a test app for this. Cheers.

Hi, I’ve encountered the exact same crash in my project when calling: CIContext().render(...) Just like the original post, I'm getting: Thread 4: EXC_BAD_ACCESS (code=1, address=...) What I’ve noticed is that the crash completely disappears when I uncheck Debug Executable in the scheme settings. With it disabled, the app runs smoothly without any EXC_BAD_ACCESS at that line. This suggests the crash might be related to debug-mode memory checks or internal CIContext rendering behavior. I’ve double-checked that the CVPixelBuffer, CIImage, and CGColorSpace are all valid before rendering. Would appreciate any insights or explanations from Apple engineers or anyone who has managed to resolve this. Thank you!