“SwiftData inheritance relationship”

It's a little bit complicated, for historical reasons.In Swift a class can be Objective-C compatible, or not Obj-C compatible. The difference is what superclass they inherit from. (Basically, Obj-C classes inherit from NSObject.)Core Data, and the archiving behavior I mentioned, come from the Obj-C past, and so expect Obj-C compatible objects.A Swift struct is never Obj-C compatible. That means, to use a struct with Core Data or archiving, you have use an intermediate conversion to/from an Obj-C that is similar to the struct. That's why there are extra steps involved.

It's not [NSObject init], it's [ValidatedUserInterfaceItem init]. If ValidatedUserInterfaceItem is inheriting its init method from NSObject, the above piece of code doesn't know that, because Obj-C is a dynamic language.In this situation, you should not use a branching control flow where both branches return. Instead, if 'result' is nil, you should crash the app immediately.However, a better approach is to implement 'init' in ValidatedUserInterfaceItem, mark it nonnull, and crash there if the superclass init returns nil. Code like the above that creates ValidatedUserInterfaceItem instances should then simply omit the 'if' test.

Thanks, stfp. Especially for the #keyPath tip. However, #keyPath is not usable with Core Data properties. At least not the way they're declared by codegen. The compiler error is:Argument of '#keyPath' refers to non-'@objc' property 'foo'I tried it with and without the quotes. It does work, however, if you use the form #keyPath(ClassName.property).I see that in Beta 5, the generator spits out OrderedSet which has been renamed to NSOrderedSet, so it won't compile. And if you rename them manually, they'll compile but at runtime the newly generated accessors like addToRelationshipName() will crash with the following internal exception:-[NSSet intersectsSet:]: set argument is not an NSSetIs this a known bug and what's the workaround for the next two weeks? I assume it's to manage your own accessor for any ordered sets, like so:extension Deck { func addCards(_ objects: NSOrderedSet) { let mutable = cards?.mutableCopy() as! NSMutableOrderedSet mutable.union(objects) cards = mutable.copy() as? NSOrderedSet } func rem

There is a known issue (tracked by <rdar://problem/10114310>) where some of the generated accessors do not work correctly when using an ordered to-many relationship that has been open for some time. The OrderedSet vs NSOrderedSet issue is being tracked as <rdar://problem/27689124>.Back on the topic of collection types; while it's tempting to model the relationship with a mutable collection type from the standard library, you wouldn't be able to interact safely with an actual instance of that type because Core Data needs to be notified about mutations so the object can be marked as dirty¹. This can be worked around using a proxy object in Objective-C, but Swift makes this story more complicated since collections are expected to be structs². The current solution of KVC-style methods on the object itself strike a balance that allows space for that magic to happen while minimizing surprise and inconvenience.~~~~¹: This is why data loss is one of the failure modes when mixing and matc

>> by the fact that I am testing result is the analyzer guessing that I think the result could indeed be nil when it otherwise would think it can't be?The analyzer does reason like this.>> Does the analyzer have some smarts in it to assume that new, init, copy, mutableCopy etc are probably not going to be returning nil even though the headers imply that they can and thereby avaoid warnings about such uses?It's unlikely that it reasons about probably. It's more likely to be designed to make assumptions that produce the least number of false warnings, across some large body of sample code, and it may take into account which method or method family is involved, and whether there's a code path that acknowledges the possible nil value.>> I really don't want to have to go through them all unless there is no other wayThe point is that there's a genuine bug in this piece of code, at least in a local sense. If you want to fix such bugs, at least you have the compiler (now) telling you where they are.

Running into the same problem. Did you use the new simplified screenshots tool? For me, all devices that inherit from the higher resolution screenshots aren't showing properly. I don't think it's on our end, could be wrong though.

I figured out my issue. I actually have to have to the Apple Pay Processing Certificate (This is the one that is created from a ECC/256 certificate signing request). I removed it after I had stuff working and it continued to work (must be some inherit delay, which is to be expected when creating and deleting certificates via the development portal). To be clear, Apple Pay for the Web will require that Apple Pay certificate(s) exist as well. I am talking about the section with the verbage:To configure Apple Pay for this Merchant ID, a Certificate that is used by Apple to encrypt transaction data, is required. Each Merchant ID requires its own Certificate. Manage and generate your certificates below.

There's not really anything to explain about transient relationships: the difference between a transient and a non-transient relationship is whether the values are persisted to storage.Because the values aren't peristed, if you reset the context or otherwise fault the managed object, the value you have for the relationship will disappear and not be present the next time the entity is loaded.Otherwise, the use case for a transient relationship is the same as for a transient attribute, the difference being whether the value in question is a pointer to an entity or just a value.

There can be a variety of causes for an illegal instruction crash. In the case of code signing it typically means that the code has requested entitlements that aren’t covered by the provisioning profile, but in your case I suspect that you’re running into another snag, namely, that you’re trying to run sandboxed code from Terminal. That won’t work. The App Sandbox is an app sandbox; it does not support command line tools.Back in your other thread I wrote:Does your app use the sqlite3 tool directly (sublaunching it via NSTask, for example)?The reason I asked this is that, once you add the sandbox inheritance entitlement (com.apple.security.inherit) to a command line tool, the only way to run that tool is by sublaunching it from your sandboxed app. You can’t run it from Terminal because in that context it has no sandbox to inherit. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Everything's marked public now, but the generated accessors still crash if you're using ordered to-many relationships. Hiding the generated source code does not help us figure out what's going on. That code should be visible to your project, just like mogenerator did.

First of all, I would recommend that you separate the concerns into the following objects:- Object Model > where you store your data- Facade object > where you will make the request, parse the JSON data and store the objects in the model- Table View Datasource where you implement the UITableViewDataSource protocol (simple object that inherits from NSObject)- Table View Delegate: where you implement the UITableViewDelegate protocol (simple object that inherits from NSObject)Instead of having:tableView.dataSource = self; tableView.delegate = self;You will have:tableView.dataSource = <instance of your Table View Datasource object>; tableView.delegate = <instance of your Table View Delegate object>;