Scenario
A SwiftUI view has an overlay with alignment: .top, the content uses .alignmentGuide(.top) {} to adjust the placement.
Issue
When the content of the overlay is in an if-block, the alignment guide is not adjusted.
Example code
The example shows 2 views.
Not working example, where the content is an if-block.
Working example, where the content is not in an if-block
Screenshot: https://github.com/simonnickel/FB15248296-SwiftUIAlignmentGuideInOverlayConditional/blob/main/screenshot.png
Tested on
- Xcode Version 16.0 RC (16A242) on iOS 18.0
Code
// Not working
.overlay(alignment: .top) {
if true { // This line causes .alignmentGuide() to fail
Text("Test")
.alignmentGuide(.top, computeValue: { dimension in
dimension[.bottom]
})
}
}
// Working
.overlay(alignment: .top) {
Text("Test")
.alignmentGuide(.top, computeValue: { dimension in
dimension[.bottom]
})
}
Also created a Feedback: FB15248296
Example Project is here: https://github.com/simonnickel/FB15248296-SwiftUIAlignmentGuideInOverlayConditional/tree/main
Post
Replies
Boosts
Views
Activity
My current workflow to have a Swift Package with a Demo is like this:
PackageFolder > DemoFolder
I have a package, with a Demo folder inside. I can open the Demo project and Drag&Drop the local PackageFolder to override the remote dependency with the local one. This allows to edit the package while inside the demo project.
With Xcode 16 this does no longer work because Xcode does not allow to drop an ancestor of the file path where the project is located. Xcode does not tell this while you drop, it just does not allow it. But it tells you thats the reason, when you try to add the local package as a dependency to the project: "The selected package cannot be a direct ancestor of the project.".
(Dropping other local packages still works, see: https://forums.developer.apple.com/forums/thread/756824)
What is the expected way to handle a package with a demo project with Xcode 16?
I added a new Core Data model version, introducing a new entity.
Based on the naming of the Entity I get different behaviour:
A: If the entity is alphabetically ordered as last entity: Everything works fine.
B: There entity is ordered before already existing entities: All records of these existing entities get a new CloudKit id. Resulting in duplicated data and broken relations.
In some cases the seem-to-be new insert of these records causes the migration to fail. (Constraint unique violation, reason=constraint violation during attempted migration)
My only workaround so far is to just give the entity a different name, to appear last in the list.
__
Does anyone else experience this issues? I am not sure if my code could be able to trigger this kind of behaviour.
I will try to reproduce it in an empty project, to file a bug report.
What is the expected / best strategy to migrate a synced Core Data model to a new version?
The issue:
A new app version with a new Core Data model introducing new attributes or entities. DeviceA installs the update and edits data with new values and creates new entities.
DeviceB is still used and downloads these changes. The unknown attributes and entities are ignored, but the HistoryTracking gets updated.
A few days later DeviceB gets the update. The missing attributes and entities are not downloaded, as the history is up to date.
__
The issue exists with iOS 13, I hoped for iOS 14 to introduce a strategy. I tried with the first iOS 14 beta, but it is at least not handled automatically.
From the visible API changes I don't see a way to handle this specifically. Not sure if the talks will reveal anything about it.
Will apply for a lab session and would like to get as much input to prepare before that might take place.
Using NSPersistentCloudKitContainer: I have a relation between Item --to-one--> Group. This works fine on device: I can set a Group for an Item and remove the Item from the Group again, everything is persisted locally.
The Problem:
Adding does work, but removing the Group never appears on a different device. As soon as the Item gets edited on the different device, the Group relation re-appears with the new changes (even if manually removed there as well).
What I see in CloudKit dashboard: Group field on Item is of type String.
A fresh Item record, never assigned to a Group, does not have the Group field.
Removing the Group does not remove the Group field in CloudKit.
As soon as it gets a Group field, I can’t get rid of it. Manually emptying the value causes to crash on download.
Reproducible with the example project:
The behaviour can easily be reproduced with the example project (https://developer.apple.com/documentation/coredata/synchronizing_a_local_store_to_the_cloud?language=objc). Just replace deleting an Attachment from a Post with unassigning it instead.
Workarounds
I can think of these 4 workarounds:
Just use To-Many relation and manage to allow only a single assignment.
Not use a relation at all, just manually track assignment.
Add isRemoved flag and filter accordingly.
Create an "Empty-Group" record to assign to instead of removing.
I am not very happy with any of these Workarounds. Does anyone have the same problem and a better solution?