“translate scheme”

Sadly, I don’t read Chinese, so I’m replying here based on a machine translation of your question. Note that you’re not stuck in mmap_locked, but rather dlmmap_locked. This is part of libffi, which is included in the Darwin open source. See here. This is gonna be tricky because, as explained in the comments for that code, its aim is to create a block of memory that’s both executable and writeable. Modern versions of macOS try really hard to prevent that, for obvious security reasons. However, in my experience such problems usually manifest as an error rather than with your app getting stuck. To work out what’s going on there I need a full spin dump. Generate this like so: % sudo spindump PID where PID is the process ID of your app. The spin dump will likely be too large to post here, so upload it to your favourite file sharing service and post a link. See tip 14 in Quinn’s Top Ten DevForums Tips for advice on how to post links. IMPORTANT Make sure the link doesn’t require me to log in. Share and Enjo

I have created a bug report (FB18172172) We want to exchange data between apps without storing data anywhere. This rules out the possibility of AppGroups. If there is any problem when exchanging data and starting the recipient app, the data should simply be gone and not be stored anywhere. The Share extensions are also ruled out because the user should not see a dialog when the other app is started. In addition, the data should only be exchanged with our apps. The whole thing should also work without the Internet. A server is therefore also out of the question. Data exchange using URL schemes has worked wonderfully in recent years. Only with the new versions has something changed without it being documented or it is a bug. If there is an even better way, please let me know.

Ah, adding DYLD_FALLBACK_LIBRARY_PATH to your scheme's executable environment propagates to previews. So this should work great! Let us know if it doesn't work around the issue for you.

I ran into the same problem. Thanks to your work I could find out another workaround: I found in the Scheme options page the setting Queue Debugging / Enable backtrace recording. Switching that off eventually worked for me.

Not sure you can do it on your own. Did you contact support for help ? To avoid such problem, I use a different scheme for build and version. version is the classical x.y.z and for build, I use the date 20250614. I find there is much less risk of confusion.

When the distance filter is set to 5, the time interval between GPS data points while walking can sometimes be quite large, which means that Apple Fitness will not display the training route information. However, when cycling, the speed is higher, resulting in smaller time intervals between two GPS data points, so Apple Fitness will display the training route information. OK, that sound like an issue on the Fitness app then. Thanks for filing the FB17792319. I noticed that your report is mostly in Chinese. It will be even more helpful if you can add English translation so all the Fitness engineers can read. Thanks again. Best, —— Ziqiao Chen  Worldwide Developer Relations.

It seems to be trying to include XCTest, but its no where in the build phases or frameworks? Anyone seen this issue? I agree that's the likely issue here. In addition to looking in places like the Linked Libraries section of build settings, look in your Build Settings if it's been added to a build setting there. And finally, check the organization of your scheme, under the Build tab. Compare the actions in that tab to that of a brand new project, and which are enabled and not enabled for different target types and actions. — Ed Ford,  DTS Engineer

Thank you! I should have noticed that. For the benefit of anyone else reading this, I have just experimented as follows. Create a file called lldbinit containing the single line settings set target.process.thread.step-avoid-regexp ^std::|^string:: Place it in the same directory as my .xcodeproj file In the field you mentioned in Product > Scheme > Info, I set the LLDB Init File field to $(SRCROOT)/lldbinit And indeed, when single-stepping, it now steps over functions in the string namespace instead of stepping into them.

I'd like to answer the second question first. The lldb config file can be selected by editing the Run scheme action. Specifically, use the menu bar, go to Product -> Scheme. Make sure the desired scheme is selected, and click on Edit Scheme.... In the pop up window, select the Run action from the column on the left. Then click on the Info tab. The lldbinit file can be specified through the field in the middle. Going back to the first question. Since we can explicitly specify a path to the lldbinit file, we can place it anywhere in the project. Is this sufficient to get you going? Please let us know and I will follow up. Thanks!

Hi! Most importantly, will the ability to emulate x86_64 containers and binaries in virtual machines persist? I assume thats a question about Running Intel Binaries in Linux VMs with Rosetta . In this instance, the binaries in question are not relying on system frameworks distributed with the operating system. As the page notes, its about Running x86_64 Linux binaries It's not the same use case as the Rosetta Translation Environment which is about running x86_64 macOS binaries. Will Rosetta 2 be blocked only from the App Store? Rosetta usage on macOS is a system capability, generally transparent to applications, regardless of how they are distributed.

I didn’t reply on this thread earlier because Apple had not made any announcements about the future of Rosetta. That’s now changed. Check out the Important box at the top of About the Rosetta translation environment. I realise that you’re not a developer yourself, so this isn’t aimed at you directly. However, it’s something to reference if you decide to discuss this with the various developers involved. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com