Posts tagged ‘app

Designing for the Apple Watch

Since the release of the Apple Watch, we have already had discussions with clients about how they were interested in releasing a watch app. As the Apple Watch is such a small and personal device, development of apps need to be approached in a completely different way to mobile.

We now have a very limited number of interactions:

  • Force Touch (bring up menu options)
  • Tap (tap an menu option or button)
  • Scroll (scroll with the digital crown or using the touch display)

With the Apple Watch being on the wrist, the attention required of the user should be as short as possible. The user has to raise their wrist to use the interface and holding out an arm can get tiring very quickly.

What is being displayed should be exactly what the user needs right now and should cut out any form of fancy images or overlays that do not contribute to the information being conveyed.

As a quick example, a few weeks ago I built an Apple Watch app for Sprinter. Sprinter for iOS allows the user to see which tasks are assigned to whom, and which tasks are being worked on, completed or are yet to be started. It also allows the user to add items, view and reply to comments and view attachments.

Trying to copy as much functionality into a Watch app would have been crazy and borderline impossible technically. Right away I knew exactly what I could change to show only the information that is required by the user:

  • Only show what is assigned to me
  • Only show what is in-progress
  • Option to switch project (using a Force Touch interaction)

These made sure that the app showed only what the user cared about. There was no need to scroll through tons of tasks that weren’t assigned to the user, and basically allowed the user to say “So that’s what I’m working on today”.

It’s quick and shortens the attention required of the user. There’s no way to create new tasks, or make and read comments. The user can do that on their phone or desktop if they want to read through lots of text and options.

Overall, Apple Watch apps are designed for short glances and not to consume content. They should be limited to display only what the user needs to see right now, nothing more. That’s not a slight on the device; in fact, the simplified interaction is vital to its usefulness sitting pride of place on your wrist.

HSM App Featured By Apple

We’re excited to announce that the app we’ve been working on with Hello Sunday Morning was released last week! On top of that, Apple was kind enough to feature it as App of the Week in Australia.

The app suggests challenges you can do as an alterantive to drinking and provides useful stats on how your health is improving as a result.

You can leave comments and tips on your favourite challenges, share what you are doing on your profile and check in each week with how things have been going.

We’re really proud of how it turned out and hope that it will help thousands of people improve their relationship with alcohol!

Interested in taking on some fun challenges and tracking your health? Try it out today.

Deploying to the App Store

When you or your team has finished developing their new iOS App, the focus then moves over to making sure it is ready for the App Store. This blog post will go over some fundamentals that you and your team will need to think about when submitting an app to the App Store.


I can’t stress enough how important testing is when getting your app ready for the App Store. Unlike the web, you can’t release small bug fixes every couple of days. Whilst some may say that this is a huge flaw with Apple having to review apps before they go live, I think it gives you a chance to think about the importance of what the first or latest release of an app will contain.

Apple provides us with two main ways of getting apps onto devices for testing:

Xcode & Provisioning Profiles

I’m not going to go into much detail about this as it’s mainly aimed towards developers. The quickest way for an app to go into the developers hands is via Xcode itself. This is the tool that is used to write, debug and package iOS Apps.

It is fine for a small handful of developers who only need to look after their own devices, but when you want to start testing apps with more users who are not tech savvy, you’ll need to look at TestFlight.


TestFlight is a service provided by Apple that allows you to give out new builds of an app to users so they can use the app before it’s released on the App Store. Unfortunately there are still some hurdles that need to be looked at before your app can be installed.

There are two types of user that can use TestFlight. These are Internal Testers and External Testers.

  • Internal Testing
    • Limited to users who are counted as part of the organisation
    • Must have an Admin or Technical role on iTunes Connect
    • Limited to 25 members by default
    • Does not require Apple to review the build
  • External Testing
    • Can be given to anyone with an email address
    • Must have iOS 8 installed for it to work
    • Limited to 1,000 testers
    • Requires Apple to review the build

When building for TestFlight, you must try to make sure you get a build reviewed by Apple as early as possible if you want any external testers trying out your application. In our past experience the review time for external testing was around 2 days.


I’ve seen it happen time and time again, people will spend all their time working on an app and be super excited for it to be submitted to the App Store, only to realise that they’ve forgotten that not everyone speaks English.

Apple allows you to create localised App Store descriptions when submitting, so make sure that if you want the marketing material to be in the users local language, you actually get people to translate the material well before you want to submit the application.

Secondly, don’t forget that it has been localised, if you change major features of the app, make sure you also update the localised versions of the material to keep in line with how the primary language reads. Remember that you will also have to update your screenshots on all localisations.


When submitting an App for the App Store, you’ll be required to add a large App Icon as well as some screenshots. These are the face of your application, they are as important, if not more, as your app name. The only way users can see if your app is the one they want to download is by browsing through the content they can see on the App Store.

To prevent any hiccups you’ll need icons and screenshots to be of a certain size and quality. Thankfully Apple provides a list of exactly how you should export your images on their iTunes Connect Developer Guide.

Review Times

Almost all clients ask Terracoding how long it will take from the app to be submitted until it’s actually live on the App Store. All I can say is that it varies. It can also depend on a lot of factors that may include:

  • New iOS device being released
    • Usually when a new device with a different screen size comes out, developers will be pushing out lots of updates to make sure their app looks good on the new device
  • New major iOS version released
    • As with any major release, Apple usually brings out new features that can be utilised in apps. Companies love adding in the new popular features into there apps, and with that comes a big spike of new apps or updates being submitted to Apple for review

Other than that, we can tell you that we’ve had new apps or updates accepted anywhere between 1 day and 1.5 months. Most often it’s between 1-2 weeks for a first app to be reviewed and accepted.


So you’ve followed all the advice above and your app has been rejected. Don’t panic! Rejections can happen for a long list of reasons, and most of them being from a small bug or a slight complaint about the meta data provided for the application.

Some common rejections could be:

  • Link to a site that contains a payment form
    • If you’re app costs money, and you’re also linking to a site that has a payment form on it, you’ll probably get rejected.
  • No demo account provided
    • If you’re app has any form of user accounts, you’ll need to provide Apple with a demo username and password for the app. Without this they will just reject your application
  • UI Bugs
    • Make sure you test your application on the iOS Simulator without an onscreen keyboard. Developers can often forget that some users will and do use an external keyboard with their iOS device, and if apps break because of it, you will get rejected.
  • Crashes
    • If your app crashes whilst Apple is reviewing the app, they will reject it. Make sure you have tested the app as if you were a brand new user, as well as someone who is logging in with an existing account.

A really good site to look at when making sure your app is App Store ready, is by having a good read through of Apple’s iOS Human Interface Guidelines (or HIG for short). These contain all kinds of default behaviours for key components of iOS.

Post Archive