The shipping of Apple Watch started on April 24, and the initial reviews have been mostly favorable. There have been some complaints and issues pointed out, however. We have here listed some of these Watch-related usability problems.
The Apple Watch is, expectedly, off to a quick start. Although the first weekend sales figures have not been officially released by Apple, it has been confirmed that more than 2 million units of Watch had been pre-ordered between the April 10 and April 24 window. In the United States, nearly 23% of those who had preordered the smartwatch received it last weekend – and Apple CEO Tim Cook has stated that the general response and feedback to the device have been ‘overwhelmingly positive’. However, the first generation of any smart device is hardly ever free of glitches (even 1st gen iPhone and iPod had their fair share of problems), and Apple Watch also has the following problems:
It is not a standalone device – At least not yet. The over-reliance on a paired iPhone (without a paired iPhone 5 or iPhone 6), Apple Watch is little more than a fashionable wristwatch. What’s more – the smartwatch mostly replicates the things that can be done with the iPhone (although on Watch, things like replying to messages are easier). As long as people viewed Watch as a mini-iPhone, they would not be motivated enough to actually order a piece online. Over time, Apple Watch has to build an identity of its own. Remaining as a mere iPhone-companion won’t cut it.
Unstable wi-fi connectivity – According to a section of early adopters as well as mobile software and app developers, not all is okay with the wi-fi connectivity of Apple’s very first smartwatch. There have been reports of difficulties in connecting to the networks that are already available to the paired iPhone, the signal strength fluctuates, and connection drops are not uncommon either. To be fair, once the wi-fi connection is stable, Watch-users can use a host of features – right from Digital Touch messaging, to interacting with the new and improved Siri.
Users need to ‘Wake Up’ Watch – As a timepiece, Apple Watch is mighty accurate – there are no two ways about it. Tests have revealed that the time displayed on the smartwatch was invariably within 50 milliseconds of the Global Standard Time. The problem lies in another way though – a wearer has to lift his/her wrist up and give a conspicuous jerk to the Watch, to ‘wake up’ the smartwatch. At all other times, the Watch surface remains dark – as a battery-conservation strategy. What’s more, if you remove Watch from your wrist and put it back on after some time – you’ll have to re-enter the Passcode as well.
Scratchgate – Remember the hullabaloo over the ‘iPhone 6 Plus bendgate’ controversy? Well, Apple-haters have been quick to point out that the stainless steel model gets easily scratched (hence the name ‘Scratchgate’). Now, it is fairly easy to remove such accidental scratches with a good polish – but ideally, you would like an expensive gadget like Watch to be scratch-resistant, right? In terms of screen durability though, both Apple Watch and Apple Watch Sport are top-notch.
Quality of third-party apps – On paper, the App Store already has more than 3000 apps for Apple Watch. Most of these apps have not, however, got the thumbs-up from the first set of users of the smartwatch. The general quality of the third-party WatchKit apps is disappointing, and the onus is on mobile app companies across the world to come up with better, more customized applications. Whatever might be the visual charms and technical excellence of Apple Watch, without enough good, compatible apps, it will go nowhere.
Is Apple Watch slow? – Of course it’s not when it comes to displaying the time – but for many other basic functions, the speed of Watch has not been found to be up to the mark by users. Simple tasks like pulling location information from the paired iPhone, or receiving the push-notifications from the built-in Watch apps can be surprisingly time-consuming (particularly when Watch is connected via Bluetooth). The notification system in general is well-conceptualized (thanks to the Taptic Engine), the interfaces are nice, but the slowness of the device sticks out like a sore thumb.
Syncing data with iPhone – Several users have tried, and failed, to sync playlists from their iPhones to the Apple Watch. This is a problem – since on many occasions, a user might want to listen to music without having to tag along his/her iPhone (playing songs while working out, for example). Pairing Watch with a Bluetooth is fairly quick, but when it comes to syncing with songs saved in the iPhone – the process is either too slow, or gets aborted on its own.
Battery life – Prior to the launch of Apple Watch, Tim Cook had assured people that the device would have 18 hours of battery juice – with moderate to heavy use. However, many users as well as mobile software/app development experts have found that the actual battery life of Watch is much lower (at times, as low as 7-8 hours). The problem is further compounded by the fact that the recharging process is fairly slow. Of course, if you are only checking the time and doing little else, the Watch battery can last a day. But then, more and smarter functionality is the reason you got the smartwatch, right?
Getting email notifications – Users expecting to receive real-time email and text notifications from their Apple Watch have been in for a surprise. There have been many instances of such notifications either being significantly delayed, or not showing up at all on the Watch screen. To get around this problem, the Apple Watch app has to be activated, and from ‘Notifications’, ‘Mail’ or ‘Message’ has to be selected (choose ‘custom’ over there). Most of the people who have not done this have reported about time-lags between notifications arriving on their iPhones and the Watch.
Weight – A relatively minor issue, but nevertheless, is worth a mention. As predicted in online iOS software and app development forums, the smartwatch is fairly lightweight – but some users have still noted that it feels ‘sort of heavy’. Watch with the leather loop band (which has been, till now, one of the most popular bands) weighs 2.9 ounces – which is a full one ounce heavier than the Moto 360. Glancing at the Watch for navigation guidance while driving can be slightly distracting. However, if the other problems are ironed out, people won’t mind this little bit of extra weight.
No options to delay the sleep time – Glances and Watch faces, Digital Crown and Force Touch – there are a lot of things to learn about the operations of Apple Watch. Doing so might not be interruption-free though, since the smartwatch goes to sleep (i.e., the screen becomes dark) after every 5 seconds or so. There is no way in which this sleep time of Watch can be delayed. It is being expected that more customization features will be present in the 2nd generation of Watch – if and when it is released.
Affects the iPhone battery – The battery performance of Apple Watch is ho-hum at best (the Pebble smartwatches perform much better in this regard). Many early buyers of Watch have found that it can cause excessive battery drain of the iPhone it is paired with. According to wearable technology experts and iPhone app developers, the Watch companion app is the culprit behind this – and force-quitting it can solve the problem. Even so, this is an issue current users are not very satisfied with.
In comparison with the iPhone 6 and iPhone 6 Plus, the screen real estate of Apple Watch is way smaller – and this makes user-navigation on the latter less intuitive. There are plenty of high points about Tim Cook’s ‘most personal device’ – with making payments via Apple Pay, text messaging, and browsing across the different Watch faces being some of them. However, the price tag of Apple Watch (starts from $549) automatically makes it a niche, premium product – and until the above issues are resolved, not everyone who can afford it will actually go for it.
If you have bought Apple Watch, do share your experience with us.
For retaining the functionality of iOS applications on the latest flagship iPhones, they have to be ported to the iOS 8 platform. In what follows, we have deliberated on some key steps for porting applications to the new mobile platform from Apple.
With more than 4000 new APIs, iOS 8 has been universally acknowledged as the most developer-friendly iteration of Apple’s mobile platform to date. Right from the platform extensions and Swift-compatibility (Swift 1.2 released recently), to device-specific features like the ‘smarter’ Siri and Touch ID – most things have come in for praise by mobile software and app development experts. There is some doubts and concerns about how iOS 7 applications can be ported to the iOS 8 platform though. Over here, we will highlight how this porting of apps has to be done:
Stop relying on ‘Scale Mode’ – You might be tempted into thinking that porting apps to iOS 8 is not necessary, since there is the option of running the applications in ‘Scale Mode’. However, simply scaling up iOS 7 applications is not a smart option – since, on the bigger screens of iPhone 6 and iPhone 6 Plus, the app screens might appear stretched (particularly in ‘fullscreen mode’). There can be issues with the size of the status bar as well. Porting the apps is important, since you want to provide optimal app-usage experience to iOS 8 users, without causing any inconvenience to those who have stayed with iOS 7.
Download and install the latest Xcode version – Which means Xcode 6.3. Contrary to what was initially thought, iPhone app developers have confirmed that there is no need to work through older versions of Xcode as well. The new Xcode framework has all the tools and resources to enable seamless porting of apps from iOS 7 to iOS 8.
Take a complete backup – Chances of losing the source code of an app while porting it is minimal. Even so, it makes sense to take a backup of the entire source code folder, before initiating the process. Make sure that you can access it quickly, if and when necessary. Once this is done, launch the project in Xcode, and select ‘8.0’ as the iOS Development Target version (under Project → Settings).
Check the deprecation warnings – Next up, you will need to prepare a list of the APIs and frameworks that have changed between iOS 7 and iOS 8. After setting the Development Target version, a fairly large number of warnings will be automatically generated. Jot them down, and start changing the deprecated APIs individually. For instance, ‘[NSArray count]’ on iOS 7 has changed to ‘NSArray.count’ on iOS 8. You will have to carefully make these changes.
Boost up the display resolutions – Professional UI/UX designers have a big role to play in the porting of apps to the iOS 8 platform. iPhone 6 Plus comes with high-end 401 PPI Retina HD display (a big move up from the 326 PPI support of iPhone 5). Hence, the images in the apps need to be of higher resolution too. All the new images you include in the app have to be of 3X (thrice the original resolution level) resolution, unlike the 2X images that were being used for iOS 7. Note that @2X app assets are still supported by iOS 8.
Implement the new notifications system in your app – According to iPhone app development experts, this is probably the trickiest part in the porting process. Directly calling registerForRemoteNotificationTypes no longer works – since iOS 8 requires a dual layer of app notification permission (the first for displaying app notifications, and the second for sending these notifications remotely). Developers now have to call ‘registerUserNotificationSettings’, and then pass it in a previously-defined settings object (UIUserNotificationSettings). Once the user-response is received and a new delegate method is called (i.e., after the first layer of permissions is obtained), the registerForRemoteNotifications method has to be used, to request remote viewing of notifications. The earlier callbacks can still be used to get the device token, but no parameters are supported in iOS 8 inside registerForRemoteNotifications.
For large apps, use XIBs – There is a lot to be said in favor of storyboarding, but it is not particularly good for large-scale iPhone apps. Problems can crop up if a team is working simultaneously, and porting from iOS 7 to iOS 8 can also be problematic. Instead, you can switch over to XIB files, which, apart from being optimal for larger applications, benefit from the new ‘Size Classes’ of iOS 8 as well. A mix of storyboards and XIB can also be used, if displaying the core flow of an app is important.
Provide 64-bit support – Apple had issued a notice that, from February 2015, every iOS application will need to have 64-bit support. Hence, this is yet another vital element of the overall app-porting process. In the ARCHS build setting you are using, simply add the arm 64 bit architecture. Check whether this implementation has been done correctly, and then just port the app to the 64-bit level. It should work fine.
Customize the app launch screen in fullscreen mode – We have already mentioned how running apps in ‘Scale Mode’ is not quite the right idea on iOS 8 devices. Instead, iPhone app developers need to activate the ‘Fullscreen Mode’, while porting applications to iPhone 6/6 Plus. According to Apple, a ‘storyboard launch screen file’ (which, ironically, is a XIB file) is auto-generated in Xcode. It serves as the new launch screen of the app. The presence of this file is an implicit indication that the application is compatible with the larger iOS 8 devices. Remember, you will still have to provide 4” images, if you do not want to withdraw support for iOS 7. With the launch image, you can add a UIImageView as well.
Working with asset catalogs – This is, in essence, a continuation of the previous point. Professional iOS coders and app developers who use asset catalogs need to separately choose the right sizes for the launch screen images of the app. For iPhone 6 Plus, launch images have to be 2208×1242 and 1242×2208 (for landscape and portrait views respectively). For iPhone 6, the app only needs the launch image only in portrait mode (size: 750×1334).
Create a Universal Storyboard – This is required for two key purposes. Firstly, a Universal Storyboard is essential to create an smooth and adaptive layout of the app that is being ported to iOS 8. Secondly, and more importantly for mobile app developers, the WatchKit SDK cannot function without it and Auto Layout. Enter the info panel of your project storyboard (press ‘Cmd+Alt+1’), and click on the checkbox next to ‘Use Size Classes’. Next, for the separate size classes (in other words, the screen sizes), you will have to define the Auto Layout Constraints. To ensure that the views are being set up properly, use the ‘Preview’ option (in Assistant Editor) from time to time. The Universal Storyboard thus created will make your app customized for all screen sizes.
Rewrite the rotation methods – iOS 8 comes with all-new rotation methods. This, in turn, implies that the ‘viewWillUnload’ methods used for iOS 7 (or earlier) apps would no longer work. The new methods – like viewWillTransitionToSize:withTransitionCoordinator and viewWillTransitionToTraitcollection:withTransitionCoordinator – have to be manually written. In fact, all the UI rotation methods in the ported app have to be new. The old ones are deprecated in the iOS 8 SDK (many apps created with iOS 7 SDK will still work on iOS 8 though).
Set up the Location Permissions – You are almost done with the iOS 7-to-iOS 8 app porting process. The next thing you have to do is include the two-stage location permission request requirements of iOS 8 (for receiving updates a) when the app is running, and b) when the app is not running). Location updates are no longer automatically shared, and for requesting the permissions – developers have to separately call the requestAlwaysAuthorization on the CLLocationManager. A new key (NSLocationAlwaysUsageDescription) also has to be created in the info.plist of the application. Location/Navigation features are key for the optimal performance of most iOS apps. Make sure it does not get lost after an app is ported.
Use the resources of Swift – It would be a shame if you do not use the powerful resources of Swift after the porting is complete. In the existing .m file(s), you can add Swift classes by importing ProductModuleName-Swift.h. If you wish to work the other way round (i.e., include Obj-C classes in Swift files), use #import for importing all the necessary header files). Make sure that you allow the ‘bridging header’ (the prompt appears when Swift files are added to an Xcode project for the first time) to be created.
UIActionSheet, UIPresentationController and UI AlertView are some of the APIs that have deprecated in iOS 8 (the first and the third have been replaced with UIAlertController). For mobile app graphic designers, two of the biggest #wins of the new platform are UIVibrancyEffectView and UIVisualEffectView. After porting your app from iOS 7 to iOS 8, you can use the WatchKit tool to create an extension for Apple Watch. iPhone applications can be made more functional than ever before on iOS 8 – and it’s high time you ported all your applications on it.
Mobile app development might be an increasingly popular profession – but the fact remains that, only a tiny fraction of the apps released every quarter are successful. In what follows, we will delve through some features that most successful applications share.
A recent study by Gartner revealed a startling statistic: Not even 0.01% of general mobile applications (i.e., consumer apps) manage to make money for their developers. In other words, about 1 in every 100 apps are able to emerge as any type of success. Is there some magic formula that boosts the chances of an application finding favor among final users? Not quite, but to be successful, a mobile app has to be:
Able to address an issue – It might be a mobile game, an educational app for kids, a mobile social networking tool, a news feed app – the point is, an app needs to have a certain, specific purpose. It should be conceptualized and created in a manner that it addresses a precise requirement of users (and yes, passing the time is also a requirement). Generic apps that do not deliver any type of value are invariably flops.
Not a me-too product – Particularly for new mobile app developers, the attractions of making a ‘me-too’ application can be high. After all, the task of cloning an already successful app is way easier than coming up with a new idea from scratch and working on it (hence, the existence of so many lookalikes of Candy Crush Saga at the app store!). If your app is too similar to an already existing one, people might not feel any need to switch over to your product. Its initial downloads will remain low.
Visually appealing – And this is the main reason why coders should not try to dabble in the visual aspects of mobile applications. UI/UX designing is a specialized field, a domain reserved exclusively for expert graphic artists and animators. The creative team has to come up with appropriate, interesting splash screens, icons, buttons, text and other visual elements of an app. Choosing a nice name for an application is also an important task. For making a mobile game, hiring the services of a professional animator is essential. A dull app never works – no matter how useful it might be.
Engaging – If an app is ‘one and done’, its popularity will wane before long. Consider the example of mobile games for kids that are too easy, and can be completed within minutes. These apps have no further ‘use’, and are likely to be uninstalled from devices soon enough. Your app needs to keep users engaged on a continuous basis – i.e., its utility should not diminish over time. Release updates (with app extensions and new features) on a regular basis. Never allow your app to appear static.
Bug-free – This brings to the fore the issue of mobile app testing. The last thing any app company wants is bugs to be detected in its applications by end-users. A flurry of bad reviews and complaints would ensue, and the overall reputation of the company will also take a hit. Prior to release, every app needs to be thoroughly tested – on simulators, as well as on actual devices (the latter might not be possible for Android apps though). In case a bug does remain undetected, a bug-fix update has to be released as soon as possible.
Protective of users’ privacy – Unless a user specifically wants, a mobile app should not reveal his/her name, location, address, or any other personal information. This factor is even more important when we are talking about Android or iPhone apps for kids. People should be able to share as much (or as little) of his/her information as they want to. If an app comes across as too intrusive (always working with the mobile GPS, for instance) – rest assured, people will stay away from it.
Not a bandwidth hog – There is quite a bit of confusion among mobile app developers as to what the ideal average bandwidth requirements of an application should be. Not going into the debate, the rule of thumb should be creating an iPhone/Android app that does not take up too much of the mobile bandwidth/data services – rendering the device slower than usual in the process. There should not be additional network charges either. Such glitches affect the user-experience, and the fallout is never good news for developers!
User-friendly – Most, if not all, apps come with a page/pages of user-instructions. It would be way too naive to assume that everyone will spend (read: waste) time to actually learn how to use the app, by reading through these instructions. Explain the operations, controls and overall functionality of your app quickly to users (use the app description section during submissions judiciously) – so that the latter can start using it right after downloading. The menus, tabs and overall in-app navigation should be uncomplicated and self-explanatory. Custom mobile apps for kids should be operable by children on their own. Never make things too difficult for your targeted users.
Fast – When it comes to any form of mobile technology, speed matters. One of the very first things that users note about an app is how long it takes to load completely. If the splash screen, for instance, remains visible for 10 seconds or more, a person is extremely likely to run out of patience. The user-interaction time with apps was always short – and with the arrival of Apple Watch (WatchKit apps) and other wearables, it is going to get even shorter. A slow, laggy app will simply not cut it.
Regularly upgraded – Ever wondered why mobile app companies release periodic updates to their apps (including the popular, successful ones)? The reason is simple: they do not want their applications to appear as stale/dated to users. Apart from bug fixes (if required), upgrades generally have interesting new features and properties. An app might have generated high initial downloads, but if you have not bothered to release upgraded versions of it for years, it has probably already been crowded out.
Compatible with the latest devices – If an app indeed manages to capture the attention of a user, only for the latter to find that it is not compatible to his/her device – that would be a shame. iOS app developers have it relatively easier in this regard, since they have to test their apps on iPhone 6 and iPhone 6 Plus only (in addition with the older iPhone versions that would be supported). Testing the compatibility of Android applications is much more challenging – owing to the sheer range of vendors and devices. Remember, app testing on simulators only is not enough – they have to be tested on actual devices.
Secure – We have already discussed the importance of the general privacy of app users. With the growing popularity of mobile payment gateways like Apple Pay, the steady user-base of Google Wallet, and the soon-to-release Samsung Pay – data-security has emerged as another must-have factor in mobile shopping apps. Even in general freemium apps (i.e., free-to-download apps with in-app purchase options), you need to explain how the users’ transaction/financial/account data will be securely stored. If the security factor of an application appears suspect, people will run a mile from it!
Completely customizable – Right from adjusting the brightness settings and the layout colors, to changing the notification system and altering the volume controls – users need to have a free reign in the apps they download. Apart from from visual and auditory elements, people should also be able to personalize the app content. For instance, in a news feed app, a user should have the freedom to choose the channels from where (s)he would like to get updates.
Kind on the phone battery – Much like the phone bandwidth issue, a successful app never causes additional battery drain on devices. Most contemporary smart devices allow users to find out how their device battery is being consumed – and if your app is found to be causing the battery to get exhausted too quickly, it will be deleted immediately. Keep in mind, smartphone users want to get that extra bit of battery juice – and your app must not be doing just the opposite.
High on quality and not too expensive – In the world of software and mobile app development, users can take two picks out of three parameters – Quality, Time and Price. Given that you have to finish projects within specified deadlines, it boils down to a direct trade-off between the quality of the app and its cost figure. You need to perform the balancing act of providing top-quality apps, at reasonable prices. Failure on either count (particularly the quality aspect) will put your app on the backfoot.
Never be in a race to finish off each app project as quickly as possible, and move on to the next one. Include some element in your applications that would ‘surprise’ users (top-class animations, additional functionalities, etc.) – which would serve as the app’s wow-factor. Developers generally advise making mobile apps for both the iOS and Android platforms, for maximizing their chances of success. The importance of focused mobile app marketing, via the World Wide Web (Facebook, Twitter, LinkedIn, Behance, app review sites, etc.) cannot be overemphasized either. A perfectly good app can fail, if people are not aware of its existence!
Please note that an app with all the above features is not a guaranteed success. However, app developers who incorporate these points definitely have more chances of tasting success than those who don’t.
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:
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.
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).
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.
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.
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:
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.
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.
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).
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.
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.
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.
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!
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.
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.
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.