Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for

I suspect this is a build UUID issue. See TN3178 for more details on what the issue is and how to resolve it. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

It seems like with Swift files the compiler flags that are added via the Build Phases pane on a per file basis are simply ignored. If say I add a nonsensical flag to the Swift file in question, everything builds fine. Adding the same nonsensical gibberish to say an Objective-C file in the pane, and then I get the expected Unknown argument: compiler error. Is this expected, is there no way to add specific compiler flags to individual Swift files? In particular, I would like to add the new deprecation warning suppression flags to a specific file in my framework as documented by this Swift Proposal... https://github.com/swiftlang/swift-evolution/blob/main/proposals/0443-warning-control-flags.md

These above put confidence in me that SMJobSubmit can be used in a secure way. I wouldn't have started this project with SMJobSubmit if I hadn't been convinced that it's compatible with the security hardening interfaces macOS provides by its latest SDKs (environment/launch/spawn constraints, XPC connection validation, etc.) To be clear, the biggest issue with SMJobSubmit isn't security, it's that it was deprecated 10 years ago. Said replacement hasn't been provided yet to my knowledge, I checked the XPC framework's functions and objects. Multiple replacements HAVE been introduced, notably SMJobBless and now SMAppService. Note that the libxpc reference is basically an architecture leak, as libxpc is what actually implements most of the job management process (including SMJobBless and SMAppService). To my knowledge SMJobSubmit is the only way other than AuthorizationExecuteWithPrivileges (an even older API) that allows one to get one-time throwaway root permissions to run a single executable. I'm sayin

The App Store categorization will have no effect on what happens to your app on the device when running in the background. So, the issue is likely in your codebase, in how your app is implementing the background activity. I can't comment on what the issue could be as not working as seamlessly as before does not give any hints about what is not working as expected. What I can say, though, is issues usually surface when the app code tries to swim against the flow of how iOS handles background activity. If your app's main background activity is location updates, usually the best way to handle this is to start location updates and let it run, rather than trying to juggle functionalities with an expectation of making how location updates work better. You may also want to look at the new CoreLocation APIs which are more resilient in various cases of app termination. The new API is described at Receive location updates in the background WWDC24 Session What’s new in location authorization explains this new A

@DTS Engineer Following up, have you had a chance to review the feedback report (FB16093992)? The behavior with blocked calls appearing as unanswered is still present in iOS 18.2. Any insights would be appreciated. The short summary is that, yes, there are still edge cases that will end up being labeled as unanswered in iOS 18.2. That behavior is still considered a bug which the engineering team will need to resolve in a future update. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Not using a beta version to clarify. I am using XCode version 16.2 and ios 18.2. Have reinstalled everything from scratch and even tried XCode cloud versions 16.2 and 16.1 and both failing

On iOS, a different MTU can be requested by one of the connecting sides, and it is the accessory that needs to be programmed to do it. As in your solution you have both sides as iOS apps, because there is no API available to an app to change the MTU, this is not possible in your use case. The two devices will, upon connection, negotiate an appropriate MTU (along with other various connection parameters), and that is completely transparent to your app. Argun Tekant /  DTS Engineer / Core Technologies

And I believe you've found the problem: This means, that all gui apps that are part of our application share the same executable (there's separate instances of the file on disk, but they all have the same UUID). This is a bad idea. The issue here is that, in general, the system primary executable identifier is bundle id. So, two apps are the same if the bundle ID and different if they have different bundle IDs. However, the problem here is that there are cases where it cannot/does not use the bundle ID. As a few examples: Crash logs are correlated/identified based on build UUID. Part of this is technical, since the crash collection system can only rely on information that's already in-process and it's possible for a process to crash before it knows it's bundle id (assuming it has one at all). Part of this is also practical, since crash logs need to be tied to specific builds, not just apps. Parts of the TCC system rely on build UUIDs (as well as code signature data), since permissio

+1 w/ Xcode15.4 ios 18.1

You are on the right track that you precompiled a source model (.mlpackage or .mlmodel) to .mlmodelc manually before adding it to Swift Package. Currently SPM doesn't support compiling the source model in .process(:) rule. Let's say, you have a source model named model.mlpackage. The first step is to compile it to .mlmodelc. xcrun coremlcompiler compile model.mlpackage /tmp/ Then, copy the compiled model to your Swift Package. cp -r /tmp/model.mlmodelc /path/to/ModelInSwiftPackage/Sources/ModelInSwiftPackage/ In my test, the resultant directory structure is something like this. . ├── Package.swift ├── Sources │ └── ModelInSwiftPackage │ ├── ModelInSwiftPackage.swift │ └── model.mlmodelc │ ├── analytics │ │ └── coremldata.bin │ ├── coremldata.bin │ └── model.mil └── Tests └── ModelInSwiftPackageTests └── ModelInSwiftPackageTests.swift Now, edit Package.swift as follows, using copy rule. import PackageDescription let package = Package( : targets: [ .target( name: ModelInSwiftPackage, resources: [ .copy(model.ml

Thanks for your post, I'm sorry to hear about the issues you're encountering with your entitlements file and identifiers. It can be frustrating to run into these problems, especially when you've already tried various solutions. Here are a few additional steps you can take to troubleshoot the issue, this will cover a few more areas where common problems can arise: Double-check Entitlements File: Verify File Format: Ensure that your entitlements file is in the correct XML format without any syntax errors. I personally like to delete all files and re-download everything from the server. Confirm Contents: Double-check that all the necessary entitlements are present in the file and that they match the requirements for your app. Compare with Working Projects: If you have other projects that are working fine, try comparing their entitlements files with the one causing issues. Sometimes, spotting differences between working and non-working files can help identify the problem. Inspect Your Provisioning Profiles: Revok