“SwiftData inheritance relationship”

Thanks mhatzitaskos,A very good initiative!I've taken a quick look. One initial comment is that I don't use a singleton to implement the listener functions. Instead I register a listener on the GKLocalPlayer when I enter different scenes. Each SKScene inherit GKLocalPlayerListener and can thus have specific listener methods, and some scenes can just ignore some events. Any comments on that?

I dont understand this statement:>>If you’re implementing Per-App VPN, you’ll wantAppProxy instead of PacketTunnel. The documentation states NETunnelProvider has routingMethod property DestinationIP or SourceApplication.Since NEPacketTunnelProvider inherits from NETunnelProvider, the routing method should be SourceApplication when per-app-vpn profile is installed. Please help me understand why per-app-vpn does not work with NEPacketTunnelProvider

How can I learn that remoteservice (pid 22043) was created by System Preferences (pid 22033)?I researched this a while back as part of a DTS incident. The system has a ‘responsibility’ mechanism that it uses to track these relationships. The API for this is not public (r. 14860959).Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

So, you want to do this?var fieldName = backgroundColor mytextfield.setValue(value: UIColor.lightGrayColor(), forKey: fieldName)I'm pretty sure you can do it like that, but only because UITextFields are Obj-C classes and inherit from NSObject. It's not a part of the Swift language. Also, it'll crash if mytextfield doesn't actually have a property with the passed-in name.Incidentally, doing it by passing property names around is quite slow, if that matters for your app.

First of all, please remember my style of coding may not be the best recommended and you can find many points to improve.you prefix classes with @objc When should / need I use @objc ?The classes in Apple's sample codes may be instantiated through nib, so when translating, it's safe to have an Objective-C compatible name included in .xib/.storyboard. As you see, manipulating existing nib files is not an easy thing. Not all @objc annotations are necessary. I rarely use @objc annotations in my original app.Simply saying, it makes translating easier.Many of your var are declared private. Is this for memory management only or does it have other effect ?My main intension to make things `private` is giving a better opportunity of optimizing to compiler. Swift has only properties, no explicit ivars, but `private` properties can easily optimized and Swift generates the best optimized code which has no loss accessing ivars through setters/getters.enum is defined as @objc, as well as its instances ;I did not do so and h

If you override all of the superclass designated initializers, you'll inherit the superclass convenience initializers. (See Swift docs, Initialization -> Automatic Initializer Inheritance -> Rule 2.) I think in this case that means you can define an init(property1:) that just calls through to super and you should able to use init(value1:value2) for subclass initialization.

Doing what you want across *workspace* boundaries is a pain, and if you have two open projects — one for the app, one for the frameworks — then you have two workspaces. That's because if you don't create any workspaces explicitly, Xcode embeds one in the project for you.(This can be a little confusing. If you create a workspace manually, the workspace conceptually contains the project(s) inside it. If you just have a project, the project contains the workspace. But the relationship is conceptually the same in both cases. A workspace contains one or more projects, whether the workspace is implicit or explicit.)So, the easiest approach is to dump all of your targets (app and framework) into the same project. If you don't want to do that (for example, if the frameworks are in a different source control repository), then add the framework *project* into the app project, or create a workspace containing both projects.(Either way, you'll end up with both projects in the same workspace, whether it looks lik

Actually, I was able to get it to work. You just need to implement the pressesBegan, pressesEnded, pressesCancelled routines of your view (at least, in an opengl app where your view inherits from UIView, it works.)

ObjectHub's solution seems like the way to go, but this is an interesting question for other reasons, too.Even if there were an AnyProtocol constraint you could apply, I don't think it would help. Consider:class Foo {} protocol Bar { typealias T: Foo func bar<U: T>(u: U) // Err: Inheritance from non-protocol, non-class type Self.T }The compiler does enforce the kind-of Foo constraint, but only by checking it when a specific type declares conformity to P. When parsing the rest of the protocol, it doesn't seem to make the connection that Ts will always be Foos. The typealias is always going to be treated like an unkown type from the perspective of the protocol itself.(In this particular case, you could just declare u as a T, since that would accept subclasses of T and thereby achieve the same result. But syntactically, the form shown ought to be valid.)