“translate scheme”

Hello. Yes. When I download my app from the App Store, an error appears. It worked only for 2-3 days and then it stopped working. I asked my friends to check it by downloading my app from App Store and they have the same problem. The language pairs are different: English to German, German to Russian, Spanish to German, etc. My app stops working after 1-2 days of use. I had to remove it from sale. Our devices are connected to the internet the error appears. Also my app shows the dialog to download language pairs as Translation Framework offers it.

I am reaching out to inquire about the implementation of an energy monitoring solution similar to Xcode's Energy Impact tool for iOS apps. So, as one note here, keep in mind the the energy impact tool is only intended to provide a quick and straightforward metric of an apps impact, particularly relative to itself, not to act as a truly accurate guide the exact impact an app actually has. In more concrete terms, it provides a quick way to compare the impact across different parts of your app and act as a simple check of expected overall usage. However, that data does not directly translate to specific impact, particularly not when all of the additional complexity of real world usage is involved. How can we achieve monitoring and calculation of CPU, GPU, and network usage over a period of time within an app? MetricKit is the best API option for this by FAR. It's straightforward to use and will basically just hand this this data in a format you can easily collect and process yourself. If you dig around

I recommend that you raise this via the support channel for the third-party tools you’re using. I can explain this error, but the way that you fix that depends on how those tools work. The error is coming back from the dynamic linker. Your app is referencing a symbol, __ZTINSt3__13pmr15memory_resourceE [1], that the dynamic linker is unable to find. The worrying bit is this: /System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk. It indicates that your tools have managed to import Apple’s internal version of this library, which is bad. IMPORTANT Apple platform’s use a two-level namespace, so a Mach-O image records both the name and the expected location of each imported symbol. I talk about this more in Understanding Mach-O Symbols. You might also wanna have a read of An Apple Library Primer, which explains a whole bunch of the backstory. The normal way to fix problems like this is to have your tools build there own copy of the library and then embed it in your product. However, I don’t know enoug

@DTS Engineer I ran some tests here that I think maybe highlights what's going on: I set a symbolic breakpoint on -[BGTaskScheduler registerForTaskWithIdentifier:usingQueue:launchHandler:] I edited my app scheme to Wait for the executable to be launched I run the app from Xcode. I trigger the app to be launched from a home screen widget (AudioPlaybackIntent) Here, on iOS 18.3 and earlier, at the time the app is launched, the symbolic breakpoint is triggered. On 18.4 beta, the symbolic breakpoint is not triggered. Now, foreground the app. On iOS 18.4 beta the symbolic breakpoint is triggered now, but because the app was already launched (in the background) the assert kicks in. I hope you guys are already on track to fix this issue (but it's worrying that we've now seen 4 betas without a fix). I don't think widgets are the only way to trigger this issue. I've seen it happen on the first launch right after installing a new build from TestFlight. Maybe app pre-warming could be another path to trigger the

Xcode has an Other DocC Flags build setting—for additional flags to pass to DocC—that you can specify either in the build settings of your Xcode project or on the command line (as OTHER_DOCC_FLAGS). On the command line you can either override a build setting by directly specifying it as a key-value pair: xcodebuild docbuild -scheme NameOfYourScheme -destination 'platform=macOS' OTHER_DOCC_FLAGS='--warnings-as-errors' or you can specify any number of build settings in an xcconfig file and pass that file for the -xcconfig command line option: # create a 'xcconfig' file echo OTHER_DOCC_FLAGS = --warnings-as-errors > MyBuildSettings.xcconfig # pass it to xcodebuild xcodebuild docbuild -scheme NameOfYourScheme -destination 'platform=macOS' -xcconfig MyBuildSettings.xcconfig

Hello, Does the Game Controller framework provide access to the Home button on your JoyCon? If so, it seems like remapping the Home button in your app's control scheme to another action would suffice i.e. override the default value/action in your app. This way your app responds as expected even when the Home button is pressed.