“SwiftData inheritance relationship”

First, I don't know why the SDK makes 'init?(coder:)' required — presumably there's a good reason, which means you just have to live with it.Second, you shouldn't need to implement either 'init' in BaseViewController, if all you're doing is calling super. According to the Swift rules, if BaseViewController doesn't declare any designated initializers, it inherits all of them from its superclass (UIViewController).Third, by the same rule, your custom 'init' in PlayerViewController prevents inheritance of designated controllers from its ancestor classes. This is what you want for 'init(nibName:bundle)', because you don't want that to be available for PlayerViewController. It's also what you apparently want for 'init?(coder:)', but unfortunately there's that 'required' … um … requirement. See above under live with it. Think of it as a legacy from the bad old Objective-C days.

If I want to take some user input from a text field, such as a name or a location, and then display that input in another view controller, how would I go about doing it?The basic strategy here is:when you set up your first view controller, give it a connection to the relevant model objectshave your first view controller store its data therewhen you set up your second view controller, give it a connection to those same model objectshave your second view controller get its data thereIf there’s a parent/child relationship between the first and second view controllers, you can accomplish step 3 in the first view controller’s prepareForSegue(_:sender:) method. If both view controllers can be on screen at the same time, you’ll need some sort of notification mechanism so that the view controller hear about the model has been updated. The usual suspects here are NSNotification and KVO. If you’re just getting started, I’d probably shoot for NSNotification.You can use Core Data for your model, but it’s not req

I have a plan to deploy via Developer ID without Mac App Store.Good. Doing this in a Mac App Store app would be tricky.What is official method to get a variety of data about other processes?There isn’t a recommended way of doing this. My recommendation is that you not create this app. It’s impossible to create such an app without it being tightly bound to the underlying implementation details of the OS. That means that every time we release a new version of the OS you will have to revise your app to account for those changes. This is not a good way to live.And when I say impossible I mean fundamentally impossible. The issue isn’t that specific APIs are broken or missing (although there’s plenty of that, as I’ll discuss below) but that the system can change in ways that cause your app to start showing meaningless data.For a concrete example, consider compressed virtual memory. In 10.9 we added support for compressed virtual memory. This is an entirely new concept, so there’s no way that an app showing virtual

I tried making a connection and sending a message, my thought was I'll get an invalid connection and if so, install the server and then try again.That’s the approach I recommend. I’ve used it before and didn’t have a problem with it. Alas, it’s hard to say what’s going on in your specific case without knowing more details. I recommend that you try re-creating the problem with a minimal test project to see if it happens there.PS I determined empirically that the error event block is executed in a thread created by the os but the reply block appears to alwats execute in the thread I send the message from. Did I miss the part in the docs where this is described?Are you talking about the reply block you pass to xpc_connection_send_message_with_reply? If so, the reply block runs on the queue that you pass to it’s replyq. IMPORTANT You have to be careful when looking at threads in an XPC world because XPC uses GCD’s thread pool, so there’s no strict relationship between threads and queues [1].Share and Enj

Is it possible to distribute a command line application to the Mac App Store?No. It’s call the Mac App Store for a reason (-Is it possible to bundle a Command Line Tool in along with a regular Cocoa Application and submit that to the Mac App Store …You can include a common line tool within a Mac App Store app, and lots of apps use this technique for helper tools, but things get tricky if you want to expose that tool to users. The specific gotcha is sandboxing. Command line tools within a Mac App Store app must use an inherited sandbox (com.apple.security.inherit). However, such tools cannot be executed from Terminal because there’s no sandbox to inherit. You can work around this by bundling your command line tool into a helper app and applying app-style sandboxing to that. The problem here is that your code will then run inside an app sandbox, which can cause all sorts of problems (for example, if the user supplies a path as a command line argument, the sandbox might block your access to tha

Did you try this?From Storyboard -> drag from the tab bar controller to the view controller you want and holding down the Control key. Select Relationship Segue > view controllers from the menu that appears.

You've got way too much sample code, so it's hard to pull out what's relevant. However, I believe your problem starts with you assuming that '[NSDictionary dictionaryWithContentsOfFile:]' returns a mutable dictionary. It doesn't, because you've sent the message to the immutable class. If you use '[NSMutableDictionary dictionaryWithContentsOfFile:]' instead, you will get a mutable dictionary, but it's collection elements will be immutable. This is documented in the NSDictionary class reference.Similarly, if you create a mutable copy of an immutable dictionary, it's a shallow copy. The copy will be mutable, but its elements won't be copied or made mutable.So, the array in your 'marr2' variable will be an immutable array after re-reading, even though you've used Obj-C language dynamism to get the NSArray object into a NSMutableArray variable. What you need to do is make your own deep mutable copy after reading the dictionary back in.The other thing that's causing confusion is that there's no actually NSMutableAr

Regarding Instruments:It may not be an error, but the options for the top level summary may (in effect) be different from those for your detail view. The top level might be including all objects ever created and/or destroyed, while the detail might only be show objects still in existence at a certain time.If you can't find an explanation, or if there might be an explanation but you think it's too confusing, then submit a bug report and attach your Instruments document.Regarding dSYMs:>> if lldb can do it, you can too!Actually, it's always lldb, not Xcode. Xcode uses lldb as its interface to debugging generally.As to missing debug information, it's a bit complicated. In a release build, all debugging information has been moved to a dSYM, and the executable contains nothing to help debugging, except module names and global symbols.In a debug build, the debug information (last I heard) can be spread around multiple locations, according to the technical needs of various binary format standards. In addition,

I wound up burning a Code-Level Support ticket on this, and an Apple engineer confirmed that there is a bug. As a workaround, it was recommended to write my own merge policy that calls super and then manually makes sure the relationship is set on both ends.

Further research on the issue has shown that in some cases Core Data can't infer complex source data models. In our case we had a merged data model and then relationships added to the merged model programatically. For whatever reason, most devices handled the complexity but some did not. We added a fallback that processes all model version combinations to determine which combination was used for the previous store.

You should probably look in the init inheritance rules: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Initialization.htmlIt says:Rule 2If your subclass provides an implementation of all of its superclass designated initializers—either by inheriting them as per rule 1, or by providing a custom implementation as part of its definition—then it automatically inherits all of the superclass convenience initializers.These rules apply even if your subclass adds further convenience initializers.NOTEA subclass can implement a superclass designated initializer as a subclass convenience initializer as part of satisfying rule 2.Your override of 'init(name:)' means that you've overridden all of the superclass's designated initializers. In that case, you inherit the superclass's convenience initializers, just 'init()' in this case, even though you've added further convenience initialzers.