It has been over three months since Apple started accepting third-party WatchKit applications for its smartwatch – the Apple Watch. By now, well over 4000 Watch apps are present at the store. However, most of these first-generation apps for Apple Watch have been of mediocre quality, and the general consensus amongst developers worldwide is that, the quality of the applications would improve when they would be built natively for the smartwatch, and have access to the native features of the device (for instance, the Digital Crown). As we wait for the final release of watchOS 2 (expected to be in the third quarter of this year), let’s take stock about what we have learnt about WatchKit app development till now:
- Xcode bugs can affect WatchKit – If the segue(s) are not working even though apparently everything looks correct, a bug in Xcode is most probably the reason. For an application being made with WatchKit, a random segue ID number might get generated due to the bug – which keeps the segue from firing up. Under such circumstances, app developers have to remove the faulty ID from the storyboard, wipe out the previous details, and start building again from scratch. Finding out whether an Xcode bug is affecting a segue is fairly easy – all that the coder has to do is include the ‘println(segueidentifier)’ inside the methods.
- Using big fonts is vital – No one likes to squint while trying to read off text from the Watch face. Many iOS and WatchKit app developers made the mistake of using medium sized fonts in Watch apps (in a bid to save on screen real estate). That, in turn, forced wearers to bring their wrists very close to their eyes – to find out what is written on the app screens. The problem was particularly prominent for apps being used in ‘Glances’ view. The ideal font size that should be used for a Watch application should be around 42-44 pts. Things have to be made easy for final users, you see?
- Downloading is easier with NSURLSessionDownloadTask – Many times so. Downloading images within an app might take several seconds, during which users might simply navigate away. Those who are into making apps for Apple Watch need to remember that the average app-interaction time on the smartwatch is very low – and no one is likely to wait as a resource takes its own sweet time to download. This is where the NSURLSessionDownloadTask *downloadtask command comes in handy. It ensures that background task(s) do not get timed out as pictures or other stuff gets downloaded in an application. Adding a provision for AFNetworking (AFURLSessionManager *manager) makes things even more stable.
- iOS applications cannot be opened by sending messages from Watch – This is a very common source of confusion among professional Watch and iPhone app development experts. A message from Watch can wake up the background processes of an iOS application, but it DOES NOT OPEN the actual app (the message is sent by calling the WKInterfaceController class). The misconception, in most cases, stems from the fact that iOS apps could be directly opened by sending messages with the WatchKit API in the simulator. On the actual device though, it only activates the application in the background.
- Shared data container is required – For both the app as well as its extension. Unlike what was initially thought, WatchKit app data do not get saved in the Apple Watch (i.e., there is no local storage and caching). To access this data, developers need to move to the ‘Capabilities’ section in Xcode, and set up app groups for the iOS application and its WatchKit extension. To rule out unauthorized access of confidential data stored in the apps, the ‘Data Protection’ option should be turned on. The ID for the data container should be the same for the app and the WatchKit extension.
- Using margins is unnecessary – There is little scope to get very creative while designing an app for Apple Watch. As per the company’s Human Interface Guidelines, developers can only use different shades of black, to enhance the illumination of the applications. The one thing that isn’t required though, is putting margins around the view area on the Watch screen (a departure from the usual norms of iOS app development). The display area should seamlessly merge with the bezel of Watch. Margins make the display unnecessarily smaller, and the UI of apps become more compressed. Navigation becomes an issue too.
- The parent application can crash – Which makes the inclusion of exception breakpoints absolutely vital. WatchKit developers have to attach the breakpoints to the parent – to ensure that the latter does not get lost in the event of an app crash. This can be done by navigating to Xcode → Debug → Attach To Process, and adding the name of the process of the app. Attaching the parent app lets developers use the debugging methods they are familiar with. The process itself gets displayed only after the +openParentApplication:reply: has been called.
- The image picker can be a memory hog – Many first-generation mobile app developers faced problems while using image picker for adding photos to Watch apps. Apart from taking up too much of memory space, image picker caused the WatchKit extension to frequently crash as well (in any case, the loading speed was painfully slow). The way around this problem is to ditch the UIImage objects, and use data instead. A thumbnail of each picture to be added to the app has to be created, and then compressed into either PNG or JPEG format. For adding animations, using the +[UIImage animatedImageWithImages:duration:] is advisable. The animated pictures can be moved to the application after NSKeyedArchiver encoding.
- Alpha layers cannot be used in Watch app icons – Neither should the images used as icons have transparency. At the app store, icon images that have either of these two properties generate the dreaded “Invalid Binary” error in iTunes Connect (this happens even when submit your app through TestFlight). App developers who use Pixelmator need to go to Sharing → Export For Web, and remove the transparency option (which is generally checked by default).
- Replicating an iOS app for Watch is a no-go – This one is probably a no-brainer. The screen of the smartwatch is way smaller than that of the latest iPhones, and if you simply replicate the graphical elements of an iOS application on a Watch app, the latter would look seriously cluttered. Instead, UI/UX designers need to chalk up the layouts and designs of Watch apps from scratch. Only the most important components of the original app interface can remain, and the focus should be on providing enough space for the text to be displayed. This includes doing very subtle changes, like replacing a square checkbox with a circular dot in the center. It’s a challenge to make apps properly viewable on the tiny screen of Apple Watch – but with smarter designing, it can definitely be done.
- Card layouts do not work well on Watch – According to experts from the field of general mobile app development, Card layouts enhance the viewability of applications. This does not hold true for WatchKit applications though. An app in Card layout appears weird when the card comes in touch with the edges of the display area, since the screen does not seamlessly merge with the edges. To put it in another way, Card layouts do not let the screen and the bezel of Apple Watch remain visually in sync. That, in turn, results in a poor app-using experience of wearers.
- Views cannot be updated too frequently – Yet another difference from iOS apps, on which views can be changed pretty much whenever the developer feels like. On WatchKit, however, Bluetooth services are used for making screen updates – and updates that are made after calling the didActivate function generally do not get approved. Since neither WKView nor WKInterfaceController has any provision to let developers keep track of the screen update data, it is a good idea to use a caching controller subclass, which would record the values of the main views. Any update that is deemed by WatchKit as a duplicate is removed, and Apple is making a conscious endeavor to minimize the number of updates sent via Bluetooth.
- Xcode does not auto-create all the provisioning profiles – Three different provisioning profiles are required for each target in an app for Watch – yourAppID, yourAppID.watchkitapp, and yourAppIDwatchkitextension. The Xcode tool creates only two of these provisioning profiles, and developers need to manually create the third from the dev portal. The three profiles need to have separate, unique App IDs. If you are working with app groups, double check whether the entitlements of the main application and the WatchKit extension have been correctly set.
- BTLE connections can be unreliable – Responses from Watch apps are sent via Bluetooth Low Energy (BTLE), and the connectivity can often be downright slow. Since testing apps on iOS simulators do not involve BTLE, developers can overlook this – and end up making apps that do not ‘reply’ fast enough. To tackle this problem, app-makers should ideally create cached copies of the API responses that are used most frequently. In case you feel that there will be a delay, add an animation which the wearer would see (just like a splash screen). The focus has to be on minimizing response times as much as possible.
In WatchKit, delegations can still be used – but the method of passing ‘self’ has changed, while a protocol has to be predefined on it. All updates have to be done within willActivate(), since only the ‘set’ methods can be updated with the WatchKit UI controls. For creating Watch interfaces, Storyboards have to be used – so if you do not use Interface Builder, it’s time to learn how to work with it. Also, do not forget that Watch apps have to be compatible with iOS 8 AND iOS 7 (many developers forget about the older platform). During the app testing phase, the Watch should be plugged on to its charger (to prevent the screen dying quickly). watchOS 2 will surely make things easier for developers – with native access to many features of Apple Watch. The over-reliance on paired iPhones will go down as well. The quality, usability and value of Watch apps should also improve over time.
Hussain Fakhruddin
CEO at Teknowledge Software
Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Latest posts by Hussain Fakhruddin (see all)
- How do mobile apps help small businesses? - October 10, 2019
- Top 15 Mobile App Ideas For 2020 - October 1, 2019
- Top 15 Software Development Trends To Watch Out For In 2020 - September 18, 2019