Post not yet marked as solved
Still here on the RC - what gives?
Post not yet marked as solved
Fast Forward one year using Xcode 15 - I got this same error, but the 'Register device' button is gone for me. On the plus side, all I had to do was to open the Signing and Capabilities tab on my app target, and it automatically started the device registration 👍
Seems like this is something that the build could handle, or the error could at least prompt us with the solution.
Post not yet marked as solved
Ok, after reviewing the 'Trips' sample application that accompanied the 'Dive deeper into SwiftData' video from WWDC '23, I see that this is handled between the Trip and both the BucketListItem and LivingAccommodation entities by simply omitting the @Relationship annotation on the 'child' entities. I have a few questions, based on what I see:
If a LivingAccommodation entity is loaded via a @Query, will the trips field be populated by the SwiftData system?
On both child entities, the trip field is an Optional Trip - is this required in this scenario? I would imagine that it doesn't make sense to have a LivingAccommodation object without an associated Trip object, and my own Model is similar
Post not yet marked as solved
I have a similar issue that I identified as being related to the Form. In my case, I had an onSubmit attached to the Form, which basically does the same thing as yours. If I change the Form to a VStack, everything works great, although it loses all of the Form styling, of course.
I've filed a feedback for this: FB9136142
Post not yet marked as solved
I'm getting the same error in one of my projects. A workaround for me is to open a different project, and then File -> Open Recent, so I'm not dead in the water, but this is disconcerting, to say the least.
UPDATE: Fixed mine - upon further inspection, there was a warning for me to upgrade my Xcode configuration. Things look better now!
Post not yet marked as solved
This is still broken in 14.2 GM. Is anyone using this new feature? This feels like a fundamental new feature that is completely broken
Post not yet marked as solved
This entry is a year old, so this may not be helpful at this point, but the "Missing entitlement for API" error most commonly happens when trying to communicate with a device when the app is in the background, which unfortunately is not allowed (I would love it to be allowed, even in some limited way -- Apple, please?). Is this when you're seeing it, or is it happening while the App is in the foreground?
Post not yet marked as solved
Property observers might not work the way you think they should when you have property wrappers. If you have a published property defined as:
@Published
var myProperty: String
The type of that property is not String, it's Published<Self.Output>.Publisher (or something like that) - when you do something like myProperty = "A new value", the property wrapper is effectively intercepting the variable assignment, and updating its' internal representation. In other words, the value of _myProperty.projectedValue changes, but the value of myProperty does not - hence, your didSet observer is never called.
I'd call this expected behavior, but perhaps surprising if you're not familiar with how property wrappers work. You can, of course, subscribe to the publisher (which will give you willSet semantics), or you may be able to create an extension of Published to give you what you want
I was notified last week that background access to HomeKit characteristics was not being considered, due to privacy considerations, so I think they misunderstood your request
Post not yet marked as solved
This one is still an issue in Beta 3
Post not yet marked as solved
Got a response on my feedback - sadly, it’s not a feature that’s likely to come to HomeKit. The reason is to prevent third party apps from being able use this data to profile a users activity in their home. I do understand this, but hope that there’s eventually a way to do this, even if it means other restrictions are applied
Post not yet marked as solved
@LVS8Barrs Developer,
I'm seeing now that my original question may have been confusing -- what I'm looking for is not to have the ability to trigger a HomeKit Scene via a Shortcut automation, but (kind of) the other way around. I want to have a HomeKit trigger (such as motion detected) be able to trigger the Siri Intent of a 3rd party app.
The 'Intruder' scene that I mention above (flashing a light) can be achieved in the Shortcuts app, but this requires the user to program it themselves, which is obviously not the majority of users. I have an app in the AppStore that can be manipulate the HomeKit lights in the home for communication purposes (flash the kids lights with "Hey Siri, Dinner Time", etc), and my #1 most requested feature is to trigger the shortcut on motion detection and button presses, but today (and in iOS 14, currently), it can't be done.
The other aspect with my app is for accessibility purposes. Light manipulation can be used by those with a hearing disability, and a large percentage of this audience is older - I would like to allow this integration to be made as simply as possible, but today, it's not possible. My father is in this audience, and doesn't even know what the Shortcuts app is, much less have the patience to figure out how to flash a light with it.
Post not yet marked as solved
I'm seeing this a lot more in Xcode 12 beta 2 as well
Post not yet marked as solved
I've spent some time on this again, reworking as Apple_Kevin suggests, but the issue still occurs for me. Exists in Beta 2 as well
Post not yet marked as solved
The only functional difference I can see in the code above is to ensure that the enclosing NavigationView (which was not in my example, but is a layer up) has a second View inside it, representing the 'Default' view that is shown, prior to taping one of the NavigationLink. It didn't work.
The observed behavior is still that each time I tap one of the NavigationLinks in the sidebar the sidebar is refreshed twice -- once with the selectedHomeId populated properly, and again with the selectedHomeId set to nil. Visually, everything looks fine -- the second refresh of the side bar does not clear out the detail view.
