“SwiftData inheritance relationship”

Quinn, if this feedback is above your pay grade then you need a raise and a promotion, because you've been around long enough to have more influence than that on a team as important as the Swift team.For the expected quality of software in a third-generation project in late Beta, Swift 3 has become a trainwreck of Microsoftian proportions--at least in terms of process and expectation. Many of us devs are spending 90% of our time not developing our app, but babysitting Swift and trying to understand so many unvetted changes. That's fine if you're working on salary but for many of us, time is money.This is made all the more difficult by not having a stable language spec, adequate documentation, code samples or working look-ups in Xcode for two years now. We're being treated like lab monkeys during late Beta as I said above. As others have said, it feels like we're developing in quicksand. The lack of attention to glaring bugs in the editor and the tool chain is deeply concerning.I can't even build without segme

Solution:The same issue had been posted at stack overflow, and here is the discussion and solution of it.http://stackoverflow.com/questions/39016828/how-to-add-target-nsmanagedobject-to-another-one-with-an-inverse-many-to-many-coGenerally, the project needs to create an intermediate (join) entity to keep track of the relationships between recipe and ingredients objects, which follows the guide in Modeling a Relationship Based on Its Semantics section of the document Core Data Programming Guide - Creating Managed Object Relationships:https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/HowManagedObjectsarerelated.html#//apple_ref/doc/uid/TP40001075-CH17-SW1Thank you.

No, I don't think so. What worked reasonably well for us, though, is to use the PHAsset's localIdentifier Property (inherited from PHObject) to look up custom metadata objects that we previously stored in a CoreData-backed dictionary (upon creating the asset). On top of that, we used PHPhotoLibraryChangeObserver to keep the stored metadata in sync with the photo library.

With further debugging, we found that clearing the Safari browsing history fixes the problem.Yeah, this is one of the reasons I was asking about sandboxing and redirects. In a non-sandboxed Mac app, NSURL{Session,Connection} share a lot of state with Safari. This is inherited from the original NSURLConnection architecture, where such state sharing was a desired behaviour (oh how the world has changed since 2002!).If you sandbox your Mac app then all of that state sharing gets disabled.Some of that state sharing—namely the three standard state holders, NSHTTPCookieStorage, NSURLCredentialStorage, and NSURLCache—can be disabled via the NSURLSessionConfiguration, but I’m not sure if that covers all the cases.Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

You didn't mention which platform(s) or even how you plan to distribute your apps.For Mac apps, you can distribute them either via the app store or from your own website.For iOS/TvOS/WatchOS you can only distribute them in-house to staff/employees if you're an enterprise developer member orvia the app store as an individual or company developer. You cannot distribute these apps via your own website.Contracts? With whom? If you mean you intend to develop apps for hire, then you need to consult an attorney and have themdraw up the proper contract types for the work/relationship you'll be working with. If you mean to distribute apps on either theMac or iOS/TvOS stores, you need to be a paid member of the Apple Developer program and sign the contracts Apple providesfor that purpose.Taxes again will depend on what you plan on doing and where your apps will be sold. Apple manages a lot of the sales/vat etc sortsof stuff but, in some cases you have to also pay country specific taxes/fees depending on where

If you've done work in PHP and SQL, then I wonder if you learned the wrong lesson as far as composing data structures that are searchable. 😐 Because I assume that's the part where you're getting stuck modeling your game data structure.The basic rules of Core Data modeling are:0. Never assume your data fits in memory. If your data fits in memory (or you don't care), Core Data is overkill and you're wasting development time.1. Only Core Data entities can reference other Core Data entities. They must do this using relationships.2. Non-Core Data objects (including collections such as dictionaries) cannot reference Core Data entities directly.The first rule is part of the nature of the system. The second rule you can try to fight, but if you try to fight it you punish yourself and work against the design of the system. If you're new to Core Data and you find yourself violating the second rule, you're using the wrong approach.Your game time dictionary violates rule #2, and partially violates rule 0.One of

The point about archiving is that objects might get unarchived before relationships between them (in particular, parent-child relationships) are re-established. In addition, the parts of Xcode that handle UI design are getting smarter at making custom class behavior available at design time, so Xcode itself might have invoked your initializer when you initially added your parent objects.On reflection, this doesn't sound especially likely, but I was trying to direct your attention to the actual initialization sequence, to see if you watch things go wrong. You have to be especially diligent if you have any reason to suspect that the instance that ends up being the child node is not the same instance you created in onInit.If it is, then the next step would to try to watch the physics body property get set back to nil. If you can see it as non-nil at line 9 of your original code fragment, but see it as nil later, you should be able to set a symbolic breakpoint on the setPhysicsBody method to fin

I suspect that none of the following will be news to you. If so, please post some cut down snippets of each of your approaches so that we can see the specific details.Oh, another useful tip in situations like this is to put a breakpoint on your +initialize method, run it in the working case, and look at the backtrace to see how you got initialised. After some more investigation, it appears a class that inherits NSObject and overrides the initialize method was not called.In the above, does “initialize method” mean the initialize() class method (or +initialize in Objective-C)? If so, you do have to be careful here because that method is only called when the class is actually used. For example, this tiny test program prints false unless you uncomment line A. import Foundation var gIsSetUp: Bool = false class Test : NSObject { override class func initialize() { gIsSetUp = true } } // print(Test.self) // line A print(gIsSetUp)For kicks, I got rid of the NSObject inheritance. Then I attempted to s

This happens consistently with the debbuger attached. The debugger doesn't stop and doesn't display any logs. The only logs that could be interesting (but maybe not reated to my iMessage extension) are:Failed to inherit CoreMedia permissions from 20417: (null) subsystem: com.apple.BackBoardServices.fence, category: Observer, enable_level: 1, persist_level: 0, default_ttl: 0, info_ttl: 0, debug_ttl: 0, generate_symptoms: 0, enable_oversize: 0, privacy_setting: 0, enable_private_data: 0 [MC] System group container for systemgroup.com.apple.configurationprofiles path is /Users/patrickbalestra/Library/Developer/CoreSimulator/Devices/2A1F73AA-01C6-45E6-A085-2E1989D88267/data/Containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles [MC] Reading from private effective user settingsNo crash line, no exception, nothing 😟EDIT: I found the issue by trying reach line of my code. The line that was driving iOS crazy in viewDidAppear was:textView.becomeFirstResponder()I just wanted to automaticall