Best way to deal with customer support issues

Former Member over 5 years ago

When receiving complaints about apps not working on the same watch you've extensively tested on, what is the best course of action? Is it to have them 'contact the developer' in the CIQ store and then follow up to beg for log files/walk user through side-loading the app? Is there a better way?

Along those lines... is there a list of common things to watch out for here? These issues seem to happen more they should. I have multiple, different devices that work fine for me. I don't get a sense that these are common issues, but the bad reviews from one or two can be very impactful to a new app. I'm considering changing my business model from being a premium to a trial app, but I feel like that shouldn't be necessary.

Top Replies

All Replies

0 Former Member over 5 years ago

I have found the ERA feature. While I'm not having great luck getting it to work for me ( it worked the first time and subsequent tries yield nothing ), I did see one error in it that gave me a lead. That's helpful.. but it doesn't seem to work now.

0 jim_m_58 over 5 years ago in reply to Former Member

See my post in the thread about ERA. If you fix a problem and upload a new version to the store, the crash logs are cleared as it's a new version. It's best to try and fix everything before uploading a new version.

when it comes to testing, one thing you want to do is check for options you yourself may not use. For example, what if you have activity tracking (24/7) turned off?

0 Former Member over 5 years ago in reply to jim_m_58

Are you aware of any settings related to activity recording via a manually created activity session? I'm not seeing any ERA reports for these issues. I'm tempted to think they may be firmware issues on the watches at this point, but it's hard to tell.

0 jim_m_58 over 5 years ago in reply to Former Member

what are example of things you're hearing/seeing?

0 Former Member over 5 years ago in reply to jim_m_58

My app creates an activity and then saves or discards an activity when you exit. People have been reported crashes during logging fit data, creating, and saving. The people who have run into it seem to indicate it happens every time. I have never once had it happen to me and in some cases we have the same physical device. All of the crashes happen in-app so I would expect to see an ERA log.

It's impossible to tell if this is a common issue or not because as you are aware, not everyone gives feedback.

0 jim_m_58 over 5 years ago in reply to Former Member

When you do have a user reporting a crash, ask them to send you theior ciq_log file along with whatever steps they use when it happens.

0 Former Member over 5 years ago in reply to jim_m_58

That's what I've been trying but it's an uphill battle. Do you know if the firmware crashes themselves make their way into the ERA viewer? Also is it possible another app is interrupting my app and crashing? Is there an easy way to simulate something like that?

I'm starting to firmly believe that there are bugs in the firmware that are causing some of my issues. Either that or there is a very big thing I'm missing because I have tested on some of the devices having issues.

Based on the overall stability of the sim environment and various packaged tools this wouldn't surprise me...

0 jim_m_58 over 5 years ago in reply to Former Member

Device crashes don't show in ERA - that's only for an app crash for one one your apps. Device crashes get sent to the specif platform group automatically I think, but if a user sends you one (err_log) you can post it here in a bug report if your app is involved.

A couple of things - if your app is having an issue on a specific device, you may want to check the forum for that device and see if users are seeing the same with other CIQ apps. Every once in a while there is a FW issue that impacts a bunch of apps, but many times, it's something in my specific app. An example would be that I had users that had set their floors goal to 0, but I'd assumed that the minimum was 1, so I was doing a divide by zero and crashing. Just something I'd never tested or considered. The same can happen using settings you normally don't use yourself.

There have been a few very rare cases where someone elses app has a problem and it would impact any app run after that, but in 4 years, I can only recall a handful of times that occurred.

And lastly, the simulator is just that.. It's not really an emulator, and there can be differences. When doing something that uses simulated data or playing back a .fit, where things can happen, such as data in Acitivity.Info being null when you don't expect it (always null check things there!)

0 Former Member over 5 years ago in reply to jim_m_58

Thank you so much for the insight. If the ERA function works then it seems to point to device crashes. After some research it seems like different regions of the world have different firmware and this seems to be consistent with what I'm seeing. The region I'm in doesn't seem to report the same problems with my app.

This is very unfortunate for me. It's very difficult getting people to respond with log files, and just a few bad reviews tarnish a new app's reputation. I've spent hours with two different devices and every setting known to man and haven't gotten it to crash one time.

Regardless, I've been beefing up robustness, particularly surrounding 'touchy' APIs in the SDK like timers and fitContribution. Both of those seem to be areas that could cause device crashes if something is even slightly misused. I also have a line on a couple other devices to try the app on, though I suspect it will work because I'm in the US.

Ultimately this experience has taught me not to become too vested in this. Device compatibility is only as good as the testing and I can't afford to buy every device in every region of the world. The simulator is not at all reflective of reality. It has a few valid use cases for speed of development and catches a few things but on the whole it's not reliable enough for what I'm trying to use it for.