0

I am using transferUserInfo to send stats data to the watch.

When the watch is asleep or idling (showing clock), and the phone app is running, there will be many infos being transferred (triggered by a repeating timer).

How many "userinfo" queues can the app send? Is there a limit?

GeneCode
  • 7,545
  • 8
  • 50
  • 85

1 Answers1

2

There is only one queue (provided by the system).

I'm not aware of any limit to the number of transferUserInfo messages that you can add to the queue.

However, you should take two things into account:

  • While iOS will send messages and be able to drain its queue, those sent (yet unprocessed) messages will be held by watchOS until your app can receive them. At some point, the watch may not be able to hold any more messages for your app.

    While I don't know exactly how Apple handles that condition, you should plan that transfers may fail, or worse, be discarded.

    Do not design your app around trying to skirt the limits of a particular system, as it will be fragile and break, especially if you don't have a contingency for handling possible situations that may arise.

  • If you expect to constantly send (a high number of) messages over a (short) period of time, this will definitely not be efficient in terms of memory or energy use.

    You should follow Apple's performance tips to create a positive user experience. If it turns out that your app is responsible for poor phone and/or watch battery life, users will stop using it.

Better approaches

Here are a few alternative approaches to avoid chatty communication between the phone and the watch:

  • Use a different method such as updateApplicationContext so the phone and watch would only have to deal with a single context, instead of a long queue of messages that would have to be individually processed.

  • Maintain the stats on your phone; avoid transferring the current stats until the watch requests/needs them. (This is an excellent approach for watchOS 3, since your app can be updated in the background, before the user launches it).

  • Batch your data to send fewer updates over time.

    • If you're not updating a complication, don't plan to update an inactive app more than once per hour.
    • If you're updating a complication, definitely don't plan to update more than 4 times per hour (but preferably no more than once per hour).

Again, don't aim for any particular number. The less often you can update, the better, in general.

Whichever methods you choose, make sure your app is robust, and can handle any type of failure, including up to being terminated by the system (such as for excessive memory use, or excessive background CPU use).

For more information

These two watchOS sessions specifically cover when, why, and how to update your watch, and mention scheduling updates around particular usage. E.g., don't update transit information throughout the night, if transit isn't running.