RaceSplitter rejected after three years for using a slider control | Dafacto
Dafacto

The personal website of Matt Henderson.

RaceSplitter rejected after three years for using a slider control

05 November 2014

RaceSplitter is an app that provides “do it yourself” timing of sport events. It’s been on the market for three years and has gone through 13 different Apple-reviewed versions. Yesterday, we were surprised to receive an app-rejection notification related to a minor-maintenance release.

The rejection claims we’re in violation of guideline 8.3:

8.3: Apps that appear confusingly similar to an existing Apple product, interface, or advertising theme will be rejected

My first thought was, “What Apple app is remotely similar to RaceSplitter? The stopwatch? There are hundreds of stopwatch apps in the store!” But then I read the clarification:

The “slide to start the stopwatch” is similar to the “slide to unlock in iOS device”.

In RaceSplitter, we use a slider labeled “Slide to Start Race” as the UI control for starting the race timer. This was introduced three years ago, in response to users inadvertently starting races when the control was a simple button. (Our customers appreciated this change, since, when staring at 500 participants on a start line, it's all too easy to accidentally tap a start button.)

So three years and 13 versions later, Apple are now rejecting the app with the claim that this control could cause user confusion vis-a-vis the UI control that Apple used to use to unlock devices in versions of iOS predating iOS 7.

We followed-up on the rejection, presenting the following arguments:

  • The swipe-to-start control was added to RaceSplitter after version 1.0, in response to people inadvertently starting races by accidentally tapping a start button. The feature has since been present in RaceSplitter for three years, across 13 different Apple-reviewed versions of the app. Our users now depend on this specific feature to safely start their races.

  • It seems difficult to imagine what confusion could possibly happen when the user is preparing to start a RaceSplitter race—that they somehow believe the device is switched off, and accidentally start a race when intending to unlock their device by swiping a control labeled “Slide to Start Race”? Tens of thousands of races have been timed with RaceSplitter, and not once has anyone reported such confusion.

  • The Apple “slide to unlock an iOS device” UI control hasn’t been present in iOS since version 6. In iOS 7 and iOS 8, the control is gone, as the entire screen slides to unlock the device.

Within half an hour, we received the following terse reply. No response to our arguments. No further clarifications. Simply:

Thank you for your message. In order for the app to be reconsidered for the App Store, please remove or revise the Slide To Start feature. Have a good day.

We followed up with a formal appeal, but the Review Board upheld the decision:

Specifically, the Slide to Start Race UI element is not appropriate and not in compliance with the App Store Review Guidelines as it is too similar to the iOS Slide to Unlock UI. While we understand this specific UI element is not present in the current version of iOS, it is still not appropriate to include it in your app.

The Review Board didn’t follow the argumentation for the original rejection, i.e. that our use of a slider could cause user confusion. Rather, they simply state that our slider is inappropriate because it’s too similar to the slider in iOS 6.

This is really frustrating. I wrote up the following to post as a final reply, but I’m worried about potential consequences, and so I haven’t decided whether to send it or not.

Apple’s original justification for rejecting RaceSplitter, based on its use of a slider control to start races, was to avoid user confusion. Three years of in-use experience confirm what common sense already tells us, that users are not confusing the RaceSplitter start race screen with the iOS 6 lock screen.

We appealed the rejection, and Apple’s review board in its response doesn’t even argue for the case of user confusion; rather it simply states, without any justification, that it is “inappropriate” for RaceSplitter to use a slider UI control.

If user confusion isn’t the issue, then it remains unclear to us why using a slider in the UI is inappropriate. Is it because Apple used a slider first? When choosing any UI element that Apple also use, how are we to judge whether it’s appropriate or not? Mail.app, for example, uses a pull-down-to-refresh interface--an interaction that Apple borrowed from the original Twitter app. So we can’t look at Apple’s own behavior as a basis for judging what is an appropriate use of a UI element.

We are not at all questioning Apple’s authority to require us to make a change, because we’ve agreed to the guidelines and Apple’s right to enforce them as it sees fit. But, honestly, it sure feels like we’re just being bullied in this case, because it’s hard to see how anyone benefits here.

Apple’s decision doesn’t benefit Makalu, nor our customers. Makalu will now have to spend time and money making a change to RaceSplitter’s user interface. Our customers will lose the race control they’ve become accustomed to and have expressed appreciation for during the past three years. They will have to spend effort adapting to a new interface.

We suppose that leaves only Apple to benefit from this change, but it’s also hard for us to objectively see where that benefit lies either.

I know that we’ve all agreed to live by these rules, but such seemingly arbitrary, opaque behavior in Apple’s review process is the truly scary part of being an iOS app developer.

Enjoy this article? — You can find similar content via the category and tag links below.

Questions or comments? — Feel free to email me using the contact form below, or reach out on Twitter.