Is there a bug with simulator when we trying to make a timer with timeInterval < 0.1 second?

Question

I'm making a new stopwatch Application with Watchkit, first my application is very simple like this:

first of all i tried to make a playButtonPressed to start a timer:

@IBAction func playButtonPressed() {
    println("playButton pressed")
    timer = NSTimer.scheduledTimerWithTimeInterval(0.01, target: self, selector: Selector("updateTimer"), userInfo: nil, repeats: true)
        startTime = NSDate()


}

with my updateTimer function like this:

func updateTimer() {

 duration = NSDate().timeIntervalSinceDate(startTime)
    println("updateTimer: \(dateStringFromTimeInterval(duration))")

    timeLabel.setText(dateStringFromTimeInterval(duration))

}

the dateStringFromTimeInterval function can help me make a dateString with duration is TimeInterval variable.

every thing is ok with my output on Debug area, i can see the dateString at printOut. But my label is lagging for setting the timeLabel as you can see here:

I don't know why, can any one can help me fix that or may be it is a bug of apple watchkit right now? i don't know it'll be lag on real device or not. Thanks

Answer 1

You have several good questions in here. Unfortunately I have nothing but bad news for you. I have been working extensively with WKInterfaceTimers over the past couple of weeks and they have severe limitations and bugs associated with them. I have a couple responses broken down here in detail.

Issue 1 - Using a WKInterfaceDate as a Timer

This is going to be really frowned upon by Apple and I wouldn't doubt this would be possible grounds for rejection. As @mattt mentions, you don't want to use an NSTimer to flip the date value. Each time you try to switch the date label, Apple lumps all those changes together and pushes them from the Extension on the iPhone to the Watch over WiFi or Bluetooth. It does this to try to optimize battery life.

Because of this, you will never be able to accurately display the time on the Watch in the way that you are currently doing. The proper way to do this is to use a WKInterfaceTimer.

Issue 2 - Using a WKInterfaceTimer

While WKInterfaceTimers are built to do exactly what you want, they have some limitations. The major one for your use case is that it only does up to second precision, not millisecond. Secondly, the timers are extremely inaccurate. I've seen them anywhere from 50ms to 950ms off. I've followed this radar to bring the issue to Apple's attention.

In summary, your current implementation is not going to be super accurate and will be frowned upon by Apple, and the WKInterfaceTimer is extremely inaccurate and can only perform second precision.

Sorry for the downer answer. :-(