I get the following error in Xcode Cloud when attempting to prepare a build for App Store: "ITMS-90334: Invalid Code Signature Identifier. The identifier "SwiftCharts-555549449cfa473253483215b74c174849d2ec9c" in your code signature for "SwiftCharts" must match its Bundle Identifier "SwiftCharts". This is an iOS app and Swift Charts is swift package dependency which the app depends on. Since it is a dynamic library, it is included via the "Embed & Sign" option. This was reported on SO by another user. They worked around it by making changes to the source package, I believe. That workaround may be difficult in my case as I do not control the source package. It's a 3rd party dependency that I'd prefer not to maintain a fork of. Any ideas of why Xcode cloud is hitting this issue or any other workarounds? I've confirmed via a codesign check that the Identifier is resolving to that special hash when doing this from Xcode Cloud. It does not have that hash when I attempt to build/archive/upload locally. $ codesign -d -v SwiftCharts.framework/SwiftCharts  Identifier=SwiftCharts-555549449cfa473253483215b74c174849d2ec9c Format=bundle with Mach-O thin (arm64) CodeDirectory v=20400 size=6872 flags=0x0(none) hashes=205+5 location=embedded Signature size=4765 Signed Time=Oct 30, 2022 at 8:33:59 AM Info.plist entries=22 TeamIdentifier=<redacted> Sealed Resources version=2 rules=10 files=0 Internal requirements count=1 size=220

When a Picker is showing, if you tap on a button outside the Picker view that shows a Sheet, the sheet fails to show and subsequently showing any sheet will fail until you restart the app. This only happens when the button that shows the sheet is too close to the bottom of the screen. If you provide some space between the bottom of the button and the screen (i.e. 50 Points), there is no longer an issue. I reproduced this with Xcode 14.2 on an iPhone Xs (iOS 16.1.1) and the iPhone 14 Sim (iOS 16.2). It does not occur when testing with Playgrounds. The error: [Presentation] Attempt to present <TtGC7SwiftUI29PresentationHostingControllerVS_7AnyView: 0x7fae7585de00> on <TtGC7SwiftUI19UIHostingControllerGVS_15ModifiedContentVS_7AnyViewVS_12RootModifier_: 0x7fae76011800> (from <TtGC7SwiftUI19UIHostingControllerGVS_15ModifiedContentVS_7AnyViewVS_12RootModifier_: 0x7fae76011800>) which is already presenting <_UIDatePickerContainerViewController: 0x7fae756b0f00>. struct ContentView: View { @State private var showSheet = false @State var selectedDate: Date = Date() var body: some View { VStack { DatePicker(selection: $selectedDate) { Text("Select Date") } Spacer() HStack { Button { showSheet = true } label: { Text("Show Sheet Working") .background(Color.green) } .offset(.init(width: 10.0, height: -45.0)) Button { showSheet = true } label: { Text("Show Sheet Broken") .background(Color.red) } .offset(.init(width: 10.0, height: -35.0)) } } .sheet(isPresented: $showSheet) { Text("Hello World") } } } To reproduce, run the above code and tap the Date picker at the top. Tapping the green button which has more space from the bottom does not pose the issue. Tapping the red button causes the bug.

I have an iPhone app the uses CloudKit for Core Data syncing. I also have a companion Apple Watch app that syncs to the same CloudKit records. The watch can be used without the iPhone app as well but they both independently sync to the same CloudKit database. This works reasonably well. As soon as either app is opened, the CloudKit will pull down the latest records. I'd like to add a watch complication that shows the state of the CloudKit records. I supported this by adding a Widget extension, embedded in my watch app. The Core Data database in the watch app is part of an app group, so the complication is able to query the same database. So far so good. I'm running into problems with the complication updating after remote records are changed from the iPhone. Here is what is happening: When records are changed on the iPhone, the data syncs to CloudKit but the watch app is not updated when in the background. This is noticed when you open the app and it takes a second for the view to show the new records. Since Core Data database on the watch is not being updated while in the background, the complication is not being updated at all. Part of my confusion is I assumed CloudKit was meant to make this more seamless with silent push notifications? I have the "Remote Notifications" capability enabled on my WatchApp. It seems that only works while the app is in the foreground though. This seems very limiting when you have a complication that depends on the Watch app's Core Data state. I have a few things to work around this with mixed success: "Wake" the watch app explicitly when records are changed on the iPhone app using WatchConnectivityManager. The hope is that by waking the watch app, it will sync with iCloud. This either isn't working or intermittenly works. It is also not clear to me that by activating the watch app, that it will trigger records to sync. I wish there were a way to ask Core Data to sync explicitly. Whenever the Apple watch app wakes in the last step, ask it to WidgetCenter to reload the widget. This process feels convoluted and seems to negate some of the the benefits of CloudKit to synchronize data which I thought would be baked into this process. Any thoughts on a better approach to all this?

In this simple Hello World app (Xcode 14.3, iOS 14.4.1), adding a Toolbar item above the keyboard leads to constraints errors in the log when you tap the TextField. It does not seem to lead to any obvious errors in the UI. Anyone have ideas on how to work around this? struct ContentView: View { @State private var foodName: String = "" var body: some View { VStack { TextField("test", text: $foodName) } .padding() .toolbar { ToolbarItem(placement: .keyboard) { Text("Test") } } } } [LayoutConstraints] Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) ( "<NSAutoresizingMaskLayoutConstraint:0x28137d2c0 h=--& v=--& _UIToolbarContentView:0x143609e30.width == 0 (active)>", "<NSLayoutConstraint:0x2813708c0 H:|-(16)-[_UIButtonBarStackView:0x143608ab0] (active, names: '|':_UIToolbarContentView:0x143609e30 )>", "<NSLayoutConstraint:0x281370910 H:[_UIButtonBarStackView:0x143608ab0]-(16)-| (active, names: '|':_UIToolbarContentView:0x143609e30 )>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x281370910 H:[_UIButtonBarStackView:0x143608ab0]-(16)-| (active, names: '|':_UIToolbarContentView:0x143609e30 )> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful.

I'd like to use the Clang AST tools for iOS/Mac projects. I want to write C++ programs that link to the Clang libraries. I will use that to analyze the AST from my IOS/Mac projects. I understand you can generate an AST dump from Apple's Clang but I instead want the full capabilities of the Clang libraries, not just the AST output. I believe I need to build compilation databases in order for many Clang libraries to be used. For instance, l'd like to use the CommonOptionsParser which requires arguments for the compilation database. Building these compilation databases is where I'm running to challenges. Its my understanding I will need to use the same LLVM version I'm using for the tooling (open source 17.x) to also build my compilation database. I already tried to use Apple's build-in LLVM to build the database but that led to build arguments such as -index-store-path being included in the JSON, which I don't think Open source LLVM can understand (failing to build). I instead attempted to use the Open Source LLVM installation with my iOS/Mac project. I got it kind of working but am not quite there. My question is whether this approach is worth pursuing? I'm dealing a lot of build errors doing this, particularly in nested swift packages that build fine with Apple Clang. Before I try to fix all these errors, I just wanted to ask whether using Open Source LLVM to build compilation databases for iOS/Mac projects is the right high-level approach for my goals mentioned initially? Is anyone doing this for complicated projects? Another option I thought of is maybe I can "clean up" the compilation database that is generated from Apple's Clang to remove the -index-store-path arguments. Then I could use that as an input to Open Source Clang.

I have a Watch companion app. The SwiftUI previews fail to build for the watch app. The errors indicate it is trying to build Swift package targets that are meant for iOS only, not the watch. The watch does not include these dependencies so it is perplexing it will try to build them. Digging into the scheme for the watch app, it includes the iOS target as you can see the screenshot. This seems to be the default when you create a new watch target. If I uncheck the boxes for the iOS target, previews will build fine. But I think this means that each time I build my Watch target, it will not simultaneously build my iOS target. I'm not sure of the impact of that. Is this a known limitation with Previews? Is there another workaround?

We’ve been encountering build failures when switching Git branches in Xcode (15 & 16), where the project fails to build due to missing symbols. Typically, running an Xcode clean resolves the issue, but this is disruptive—especially on large projects where a full rebuild after cleaning can be time-consuming. We’ve managed to reproduce this issue in a minimal setup: Create a new Xcode project. Include a local Swift Package in the project. The main project depends on the package. Add a new Objective-C class to the package. Use that new class in the main project. Build (FAILS). Clean the project. Build (SUCCEEDS). This issue tends to arise when switching Git branches that introduce new files, such as Objective-C files that don’t exist on the main branch. If a new file is introduced in a feature branch, switching between main and feature requires a clean before the project will build successfully again. We plan to file a feedback report, but in the meantime, we’re wondering if anyone has found effective workarounds for this problem when switching branches. The only reasonable work-around we have found is to create an umbrella header manually and include the new header. It would be nice to not have to resort to maintaining umbrella headers in packages but this is ok.