“SwiftData inheritance relationship”

It might be a trivial issue, but I am not able to solve it. I have the following function in an objective-c superclass:+(instancetype) lineWithNumber: (NSString*)number;and I am trying to inherit in a swift subclass with:class func lineWithNumber(number:NSString)->LineYet if I put the override in front I get error:Method does not override any method from its superclassif on the other hand I omit the override keyword it reports:Method 'lineWithNumber' with Objective-C selector 'lineWithNumber:' conflicts with method 'lineWithNumber' from superclass 'Line' with the same Objective-C selectorI also tried replacing instancetype with Line as in the inheited function with no change.Calls in other classe would regularly access the Swift function if it were not for the error. What might be the problem, and is there a way to check how Xcode translates Objective-c signatures when they are imported in Swift?

I have a couple of days off, so I thought I would try my hand at the Protocol Oriented Programming.One of the first projects I built in Swift was a set of protocols and classes representing expressions. I had 3 types of expressions: MathExpression, StringExpression, and BooleanExpression. These were protocols which inherited from a common Expression protocol. I then had classes representing various operations, etc....This worked fine, but there was A LOT of repeated code. Basically every type of expression had nearly identical code except for the types (e.g. String vs Bool). I am trying to take advantage of the swift 2.0 features to improve this (and potentially move everything to value types at the same time). The biggest problem I am running into is that protocols with self/associated types can't be used as types themselves. I am finally starting to understand why this is the way it is, but working around it requires a lot of thought.I would like to have a single Expression protocol which can be us

I sent a email asking this question before, but I have not gotten a response. Anyway in the app submission guidlines there is a line that states Apps portraying realistic images of people or animals being killed or maimed, shot, stabbed, tortured or injured will be rejected. I work for a company and most of what we are creating, VOD systems and websites are geared toward outdoorsman, being hunting and fishing content. I have published a channel for our content on Roku's channel store and I am in the middle of developing my first swift app for tvOS with the same content. However, one of my superviser's told me that another company we have a relationship with tried to submit similar content and was rejected. So before I can move forward with my project I have to see if the app will be rejected because of our content. It has been a blast learning Swift 2.0 and finally getting the chance to work with tvOS/iOS. Our plan was to submit a tvOS and iOS app, with different layouts.

Hi all,I just bought a new IPhone 6s and used Siri. I've dictated to call my sister, the relationship was saved according to Siri and when i asked to call again i had to do the whole process again. It doesn't seem to remember the relationship. The Software is IOS 9.2. Any information on this issue?Thank you!

While trying to convert an older Objective-C program to Swift, I've run into a hitch.So, let's say we've got a base class with a required initializer:class Base { required init(foo: Foo) { … } }and then we have a subclass, but the subclass includes a new parameter in the init, specific to the subclass, and satisfies the requirement via a convenience initializer:class Subclass: Base { required init(foo: Foo, bar: Bar) { ... super.init(foo: foo) ... } required convenience init(foo: Foo) { // Do some calculation to determine a default value for ‘bar’ from the input of ‘foo’. // Perhaps this calculation is quite a few lines of code. let bar = ... self.init(foo: foo, bar: bar) } }Now, that subclass gets subclassed once again:class SubSubclass: Subclass { required init(foo: Foo, bar: Bar) { … super.init(foo: Foo, bar: Bar) ... } required convenience init(foo: Foo) { // Uh oh. } }The trouble here is that we’re required to implement init(foo:) per the base class’s interface, but we cannot use Subclass’s perfectly ser