“SwiftData inheritance relationship”

>> It is weak because if it were strong, a retain cycle would ensueTo reiterate:1. It is a bug to make it weak (because that leads to a crash, which is the horse you rode in on).2. It is a bug to make it strong without a mechanism to nil out the relationship when the window is closing (because that leads to a retain cycle).3. A better design would be to make it neither strong nor weak. I mean, remove knowledge of the window controller from the plugin system. agent.weatherProperties sounds like pure data model to me, so the MVC relationship you want is model.agent.weatherProperties, not controller.agent.weatherProperties.Another way of putting is, instead of the window controller passing self into your plugin system, it should pass self.model, where model is a custom object that has all of the properties needed by plugins that are currently accessed via the window controller.Although controller vs. model may seem like a distinction without a difference, the point is that exposing the wi

#1: It shows dashes when it doesn't have real or placeholder data yet; those are the cases where you get the Complication Asset images for the other variants, but AFAICT there's no place to set an equivalent friendlier large complication default. I'll probably request that in Radar; the dashes annoy me.Customize uses the getPlaceholderTemplateForComplication. Are you returning the same thing for that and the real ones? Is your image marked as being a template image? There's a Render as popup in the IB inspector.- ETA: it only shows the placeholder in the customize screen. If you have data, then you're missing something that tells the watch to show it. But if it really is a case of no data, then to get rid of the dashes, you need to return a start/end date for that complication - I used the earliest/latestTimeTravelDates because I don't want it to ever gray out - and have getCurrentTimelineEntryForComplication return something useful. The before/after callbacks can return nil. You could reuse the placeholder t

Not only is Xcode's code generator garbage, but if you correct your relationship types to NSMutableOrderedSet (and probably also NSMutableSet) —your inverse relationships will no long get updated automatically as you add or remove objects in that set! This is absolutely insane. It literally cripples my app and affects hundreds of lines of code. Not a happy customer tonight... Is anyone at Apple even testing this in a Core Data app?

Hey @sftp, this feature is not usable in Beta 3. It does not work as advertised and is not a viable replacement for mogenerator.Specifically, no matter which codegen option you pick, you'll get a +CoreDataClass.swift file in addition to a +CoreDataProperties.swift file.The +CoreDataClass.swift file is useless because the name isn't simply the name of your class, and if you're migrating to Xcode 8 + Swift 3 you typically already have class files that were generated by mogenerator (which of course no longer works).The files are missing generated string constants like the Attributes and Relationships enums provided by mogenerator. These enums/structures are needed for safer KVC.Worse, sets are not properly typed.Far worse than that, ordered to-many relationships are not generated properly. There are no accessor methods like in mogenerator. These relationships are spit out as OrderedSet—which are not mutable. They need to be NSMutableOrderedSet or somesuch. If something gets dumped into

Thank you for your feedback.There is a known issue in the seed where navigating away from the model file causes changes to be discarded. This is especially confusing when making changes in the inspector, and is the most common cause of a class file continuing to be generated after changing the code generation type to `Category/Extension`. An explicit ⌘S (and ⌘B) immediately after changing the codegen type should work around the issue until it is fixed.The string enums mogenerator produces are convenient, but it is not possible for the compiler to reason about them. I've filed <rdar://problem/27554613> on your behalf on the topic of emitting something like this in Objective-C, but Swift code should use the #keypath() expression, a more general solution which is always checked for validity at compile-time.The types that are generated by Xcode for relationships were not chosen arbitrarily. Manually changing the types is not supported. There are serious performance implications for types that seem

1) We try to use this code for set the VPN configuration…How must be the server address format ?That address is interpreted by your code (the NEPacketTunnelProvider subclass in your extension). As such, it’s up to you how to format it. Most folks use a DNS name or IP address, but I don’t think there’s anything in the system that requires it to be formatted that way when you’re creating a custom VPN transport.I recently wrote up a discussion of how settings flow through the system when you’re creating a custom VPN transport as part of a DTS incident (s. 644618748). I’ve pasted it in below because I think you’ll find it useful.2) How exactly use the NEPacketTunnelProvider extension added in our App ?…But how can we use the class declared in the app extensions ?When you start the VPN connection (by calling methods on the NETunnelProviderSession instance you get via the connection property of the NETunnelProviderManager), the system starts your extension process, instantiates your NEPacketTunnelProvider subclass

You’re not using NSStream correctly. NSStream supports two modes of operation:async, via the -stream:handleEvent: callback scheduled on a run loop (-scheduleInRunLoop:forMode:) or a dispatch queue (CF{Read,Write}StreamSetDispatchQueue)sync, the defaultMost folks use it async but it’s OK to use it sync under specific circumstances (more on this below). I’m going to assume that’s true in your case and take things from there.Which brings us to this code:var readByte :UInt8 = 0 while inputStream.hasBytesAvailable { inputStream.read(&readByte, maxLength: 1) }This is definitely wrong. You’re mixing up the notion of whether bytes are available (hasBytesAvailable) with the notion of whether the stream has hit EOF (that is, no more bytes can become available). These are different things. The correct approach depends on how your data is structured on the ‘wire’:If the remote peer sends you data and then closes its end of the TCP connection, you can use EOF to denote the end of your data.If not, then the data stream

Now is there any way we can disable NSStream read/space callbacks and enable it again as this is possible with CFSocket.Not really. You could try unscheduling the stream but that’d put you well off the beaten path.I tried to get the underlying socket of the NSStream … and tried to call CFSocketDisableCallbacks on it but it did not disable the bytes/space available callbacks. CFSocketStream does not necessarily use CFSocket. There used to be a direct relationship back in the day but things have moved on a lot since then.The reason behing this is I do not want to keep buffer for storing the read bytes from NSInputStream and the consumer for those bytes is asynchronous.I’m not sure I understand your requirements, but it sounds like you can simply stop responding to .HasBytesAvailable messages. When you use NSStream in async mode, I/O is based on an ‘interlock’ mechanism: you get a .HasBytesAvailable eventyou make a read(_:maxLength:) callyou get another .HasBytesAvailable eventSimilarly for .HasSpaceAva

Does your app use the sqlite3 tool directly (sublaunching it via NSTask, for example)? If so, you should sandbox the tool and set the com.apple.security.inherit entitlement. That will cause the tool to inherit its entitlements from your app, which is probably what the want and will make App Review happy. The only fly in that ointment is if you also want the user to be able to run the sqlite3 tool from Terminal. In that case com.apple.security.inherit causes problems because there’s no app sandbox to inherit from. If that’s the case, please post back explaining the expected use cases for this sqlite3 tool. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

In my case crashes seem to be caused by to-one relationships.