“SwiftData inheritance relationship”

Yes, you are looking for:- (NSPersistentStore *)migratePersistentStore:(NSPersistentStore *)store toURL:(NSURL *)URL options:(NSDictionary *)options withType:(NSString *)storeType error:(NSError **)errorMake sure that you don't have the ubiquity options in the options dictionary when you make the call, otherwise we'll attempt to ubiquitize the migrated store.Be aware that certain features of you managed object model may be incompatible with CloudKit (required relationships for example), your mechanism of syncing changes with CloudKit should take this in to account when it builds your CKRecord graph.

Swift doesn't have covariance for return types (yet?), and that's what would let you override rootNode in a subclass to return a SubNode. That aside, the problem is, of course, that an instance of SubNode can't be sure that it's returning a SubNode root, because it doesn't control the type of the stored properties that have nodes for values.You can work around the problem, clumsily, by giving SubNode a subRootNode property, if you don't want to force clients of the class to do a cast.A better approach, in the Swift philosopy, is to not use class inheritance at all. Instead, you'd declare a NodeProtocol that defines the shared behavior of all nodes, and put the base class behavior in a protocol extension that implements default behavior. You can still have a Node base class if you want, but ideally you don't need it, and your (no-longer-sub-)classes would just implement their versions of the protocol behavior.This is known as protocol oriented programming, and you should find a lot of discussion of it

That would make very much Android programming... frankly I do not see so much the need to create so many layers in an object oriented environment but rather have in my full view the full piece of code I am working with. But of course this is a matter of taste. Somone like it horizontal, some othe ones like it vertical :-) It mins me of the bias, also being enforced in the WWDC, towards the have relationoship, oppsotie to the is one (property verus inheritance). OO theory has weel gaounded criteria to decide the relationships bwtween classes o to better model reality and I hold any attempt to steer somewhere for this make for not so easily maintanable code. But again this is a matter of taste.

In WWDC 2016 they said there is a parent property in CKRecord to use in order to establish hierarchical dependencies, so my question is: what about CKReference? and how to use, if the purpose is not a parent-child relationship... Anywhay, CKReference are useful to just link two records and setting the action to .deleteSelf or .none is just a part of that link.

I sympathize. Stupid question: if you're converting code, why are you keeping Obj-C source? Could you rewrite the AKContext class hierarchy in Swift instead? I suspect your problem is some conflict across the super-/sub-class relationships. Rewriting in Swift might reveal a problem that slides under the radar in Obj-C source.

Clearly you can write your code any way you’re comfortable with but the C idiom, which Swift inherits, is that:if statements are used when you want a statement?: is a shortcut to avoid temporaries when you want a valueI realise that the example in your first post is just an example, but that specific case would be much better served by filter(isIncluded:). For example, to find the even numbers in an array. let a = [1, 2, 3, 4] let b = a.filter { (i: Int) -> Bool in return i % 2 == 0 } print(b) // prints [2, 4]If you really want to get concise you can crunch this down quite dramatically.let b = a.filter { $0 % 2 == 0 }Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Also, I cannot export to an ADHOC build from xcode for the same reason. It fails on the comiling from bitcode step.Here are some snippets, anyone know how to fix these? I checked that my runtime search paths include executable_path/frameworks, loader_path/frameworks, inherited etc... all of those were already there Debug: Search Path: ['/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.0.0/lib/darwin', '/Applications/Xcode.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS3.0.sdk/usr/lib', '/Applications/Xcode.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS3.0.sdk/System/Library/Frameworks'] error: libswiftCore.dylib not found in dylib search path2016-09-14 15:33:40 +0000 /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool exited with 1 2016-09-14 15:33:40 +0000 ipatool JSON: { alerts = ( { code = 2554; description = Configuration issue: platform AppleTVSimulator.platform doesn't have any non-sim

And where are the subclass relationships?

I agree the documentation is not super clear and the Ice Cream Builder code not compiling does not help.So far, I have been able to create a new message by executing the code below in a UIViewController which inherits from MSMessagesAppViewController. I have yet to figure out a way to get the activeConversation thread to insert into, as calling this on the controller returns nil. In regards to your other questions, you do not create a send button, this exists in iMessage. Creating a message simply places it into the input field for the user to send. This makes sense, as some developers would have surely abused auto-sending capability. As far as passing your game-variables and state, the URL would be a great way to do it. You could add the key-value pairs into the URL as necessary and parse on the recipents end. MSConversation *conversation = [MSConversation new]; if (conversation) { MSMessageTemplateLayout *layout = [[MSMessageTemplateLayout alloc] init]; layout.caption = @Caption; layout.subcaption