“translate scheme”

Thank you @benjfromlondon for showing me the way! I had the same issue while building using the Xcode@5 in Azure Pipelines although the project was otherwise configured as it should and as many StackOverflow threads indicated it should. I will add below more information about how I fixed the issue and troubleshooting. The fix The Xcode@5 Azure Pipelines task does not sign the archive by default: # Signing & provisioning #signingOption: 'nosign' # 'nosign' | 'default' | 'manual' | 'auto'. Signing style. Default: nosign. #signingIdentity: # string. Optional. Use when signingOption = manual. Signing identity. So I added the following to my Yaml pipeline: (signingOption, signingIdentity and provisioningProfileName) - task: Xcode@5 displayName: 'Build IPA' inputs: actions: 'clean build' configuration: 'Release' sdk: 'iphoneos' xcWorkspacePath: 'ios/MyApp.xcworkspace' workingDirectory: '$(Build.SourcesDirectory)' scheme: 'MyApp' packageApp: true signingOption: 'manual' signingIdentity: 'iPhone Distrib

[quote='777577021, coolaj86, /thread/777577, /profile/coolaj86'] I'm not a Swift coder, but I'd like to be [/quote] Well, you’ve chosen a hard place to start |-: I have a lot to say about this but I want to start by addressing two specific comments: [quote='777577021, coolaj86, /thread/777577, /profile/coolaj86'] I did change Sandbox App to NO in MyApp.entitlements [/quote] Don’t do that. If you don’t want to be sandboxed, remove the App Sandbox capability in the Signing & Capabilities editor. Setting the value to false can cause weird problems (although that’s unlikely to be causing problems for you here). [quote='830567022, coolaj86, /thread/777577?answerId=830567022#830567022, /profile/coolaj86'] using a uri to open system preferences [/quote] That URL scheme changed recently. I have links to docs for it in Supported URL Schemes. [quote='777577021, coolaj86, /thread/777577, /profile/coolaj86'] I always get permission errno 13 (permission denied). [/quote] macOS has multiple layers of

BAD_REQUEST typically means that the CloudKit server receives an invalid request. That can happen when, for example, your request has a CloudKit record or field that doesn't exist in the CloudKit schema. You mentioned your development scheme had been fully deployed to production, but that doesn't completely rule out the possibility of having invalid requests. For example, if you are using Core Data / SwiftData + CloudKit (NSPersistentCloudKitContainer), and the Core Data / SwiftData model in your app isn't completely mapped to the CloudKit schema, a bad request may happen. What CloudKit API are you using? For Core Data / SwiftData + CloudKit and the CloudKit framework, you might consider capturing and analyzing a sysdiagnose to hopefully find detailed messages that indicate the concrete reason of a bad request. If you are only using NSUbiquitousKeyValueStore, or using file system APIs to access iCloud Drive, you don't directly get involved to CloudKit requests, and so I’d suggest that you file a feed

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