How To Minimize Rejection Risks Of WatchKit Apps?

By | April 7, 2015

Apple has shared certain submission guidelines that have to be followed by all developers who are creating WatchKit apps. In what follows, we have deliberated on these guidelines in detail.

It has been a week since Apple announced that third-party developers could start submitting their apps for Watch. WatchKit, the tool for Watch app development, was released in November – while the device itself would start shipping from 24 April. Understandably, developers are in a rush to get their apps approved at the store before their rivals. This, in turn, is leading to mistakes (and consequent rejections) too – simply because the developers, in their hurry, had not carefully gone through the submission guidelines of Watch apps. Over here, we reiterate the things that you need to consider before submitting a WatchKit app:


  1. Compatible SDK version – Create your app for Apple Watch with the latest final version of Xcode (6.3 is still in beta). The specified deployment target for WatchKit is iOS 8.2, and the iPhone that will be paired with the Watch should also be upgraded to this version. In case your WatchKit extension requires an additional framework, make sure that its target platform is iOS 8.0 or higher. WatchKit apps are not compatible with older iOS versions.
  2. Placement of app screenshots – Do not make the folly of overlapping the screenshots of your WatchKit app with those of your iPhone app (same app; different versions). WatchKit app developers have also been advised to not include the frame of the device in the screenshots. Every snap has to be of 312×390 px, and a total of five app screenshots can be uploaded (in addition to the 5 allowed for iPhone apps).
  3. Capitalization Norms – Be very particular while using the term ‘Apple Watch’ in your app description. The first letters of the two words (i.e., ‘A’ and ‘W’) have to be in uppercase, and you need to use appropriate Apple trademark symbols in your communications. Remember, the words ‘Apple Watch’ have to be written in English always – irrespective of what the language of an app might be.
  4. Matching Build Number & Version Count – Before app development experts upload Watch applications in the binary, they have to check one thing: whether the build number AND the version of the WatchKit app, the WatchKit extension and the iPhone application are identical. If not, your app submission would probably be rejected forthwith.
  5. Using Swift for the app – Apple’s Swift programming language is being deployed for making iPhone/Watch apps by many developers. If you too wish to do this, you will have to: a) set ‘Embedded Content Contains Swift’ to ‘Yes’ in the paired iPhone app target, b) set the same build setting to ‘No’, for all the app development frameworks you use. For starters, do not use openParentApplication:reply: in the app. There has already been a few cases of app rejection due to faulty implementation of openParentApplication:reply:
  6. Use the same name and app description – An iPhone app and its corresponding WatchKit app must have the same name and description. Reports from online iOS app development forums confirm that the words ‘Apple Watch’ are not to be used in the description (since that would count as spamming). In the common description, write about the WatchKit app version in the first or second paragraph. Mention it once again in the ‘What’s New’ section. DO NOT submit two separate descriptions or duplicate descriptions.
  7. App icon guidelines – Just like the descriptions, the icons of the iPhone app and its related app for Apple Watch have to be the same. UI/UX designers of app companies need to create icons of size 1024×1024 px, and make sure that scalability is not a problem (since the system would automatically scale down the icon). In case a white background is used, a hairbrush effect will be added to the icon, for clearer depiction. The background of the icon of a Watch app should never be black.
  8. Non-inclusion of alpha channels – This is an absolute must. Already, a few cases have been reported where the app icons had alpha channels – and they were promptly rejected during the validation stage. Moreover, a lengthy error message was also generated by the system. Keep in mind that asset catalogs cannot be shared across iPhone and Watch apps. The icons of the latter have to be present in the corresponding Apple Watch targets (not the iPhone app targets).
  9. Maximum size limit – Early reports from iOS and WatchKit developers suggest that the maximum size for Watch apps is 50 MB. Heavier apps are likely to be rejected, and in any case, they would lag in terms of performance. The user-interaction time will be minimal, and small, fast apps would be best-suited for the smartwatch.
  10. Emphasis on responsiveness – During the app testing phase, be very careful about this factor. Find out whether the Watch app you have created appears to be properly responsive on the different device simulators. If not, work with your app designers to do the necessary corrections. Unless your app for Watch ranks high on the responsiveness and fluidity of design, there are hardly any chance of it being approved by Apple.
  11. Using the bundle identifier in WatchKit extension – This one is another important naming convention for WatchKit apps. Before submission, check whether the prefix of the bundle identifier in the WatchKit extension is the same as the bundle identifier of the paired iPhone application. If there are any discrepancies regarding this, your app will be rejected.
  12. Submitting keywords – You have a total space of 100 characters, to add keywords for your app. Remember, keywords for both the Watch application as well as the iPhone app have to be included in this space. Avoid using words like ‘watch’ or ‘app’, which would unnecessarily take up space. You are not supposed to write ‘Apple Watch’ in the keywords section either – after all, the name of the device cannot be a keyword!
  13. Do not create apps that include clock faces – Apps that are supposed to run on Apple Watch must not, in any way, simulate the movements of clock hands – or show the time in any way. Third-party developers were, rather surprisingly, not cautioned against the inclusion of clock faces in their apps in the initial HIG. However, this is a confirmed guideline, and would soon be specified by the Cupertino company.
  14. Be wary of Xcode 6.3 – If possible, do not open your Watch app in a Xcode 6.3 environment. Doing so often causes the set Deployment Target to change automatically to iOS 8.3. You will have to manually change it again, to ensure glitch-free approval of the app.
  15. Custom builds and app ID provisioning – Instead of Xcode, you can use other custom build scripts to code an WatchKit application. In such cases, however, you will have to follow certain conventions while managing the zipped IPA. There has to be a discrete provisioning profile and App ID for the WatchKit extension as well. Check whether the ID you enter is correct.

Most iOS/WatchKit app developers are in favor of manually setting the release date of their Watch apps, and upgrading them on April 24 (or later). However, if your app gets approved before that, you can make it available for the few people who already have Apple Watch. Users would get real-time updates, as soon as a WatchKit version of an app gets approved and published at the App Store. The icon and screenshots become visible only after the first WatchKit build has been uploaded in iTunes Connect. Making customized Watch apps is a new form of challenge for iOS developers – and the above tips should pave the way for quick, hassle-free approval at the store.