Producing a Demo Video for your iOS app

February 25, 2013 by · Leave a Comment
Filed under: iOS 

My new iOS app GameTimer is getting closer to a release. The app has been submitted to Apple, so I’m now working on generating some interest on review sites. I’ve read the helpful “Pitch Perfect” by Erica Sadun and Steven Sande from TUAW. They make it clear that it’s important to stand out from the tens and hundreds of pitches that are submitted on a regular basis. A short demo video helps in standing out – it shows that you’re willing to put in the work and it makes the reviewers job easier (“quickest way to initially assess your app”). It takes some work and time, but it wasn’t too tricky. In case you’re interested, the final video is embedded on the GameTimer Details page

This blog post sums up the steps and tools in order to produce the video – so you can do the same for your app. Please let me know if I missed something or didn’t explain things well.

Tools

Here are the tools I used to produce my demo video and their associated costs:

  • iShowU HD (30$, used to record the app – similar products available, but this was the cheapest “professional” app I found)
  • QuickTimePlayer (free, used to record audio)
  • iMovie (I used iMovie09 that came with my Mac, the newer iMovie11 is 15$ on the Mac App Store)
  • Pixelmator (optional for designing titles, 15$ on the Mac App Store – this is my preferred graphics app so I already had it installed)
The short version is that you probably have almost all the required tools available and there is not much money you have to spend. All the apps are relatively easy to use, it took me just a few hours from “what’s iMovie” to finished video. Let’s have a closer look at what I was doing with these apps.

Shoot the Video

The first part is to shoot a few segments showing your app. The simplest way is to record the Simulator. A couple of pointers:

  • The final video should have a duration of about one minute. You probably don’t need more that 60-90 seconds of “raw” footage.
  • Create a few short segments. You probably need a few tries to get each segment right. (I used three demo segments.) Also, you may want to “re-shoot” some segments based on the voice over you want to add (see next section).
  • iShowU HD has an option to just record a segment of your screen (so setup to record just the Simulator window). Another feature is to highlight “taps” (they call it “Blob” on Left Click). There are fancier ways of achieving this, but I found this works okay. (There were a lot of mentions of SimFinger by Loren Brichter, but didn’t really see too much of added value.)

Here’s a look at the iShowU HD main window:

iShowUHD

Add VoiceOver

You can record your voice using iShowU when recording the video, but you’re more flexible doing video and audio separately:

  • As for the video, you should record your audio in small segments. 
  • In addition to the video segments, also record opening and closing segments.
  • You can spend a good chunk of change on good microphones (or even a professional speaker), but a USB headset that I also use for Skype worked fine.
  • Rather than ad-lib, you should have some notes or a even fully written narration.
  • You’ll probably need a few iterations to have your video and audio come out at about the same length. Edit the copy you are reading or shorten/lengthen the video.

Put it all together

Once you have the basic parts, you can edit the video using iMovie:

  • Properly align the video and audio segments. (You can adjust the length a little bit by accelerating or slowing the video so it matches the audio).
  • Add a title and closing screen. You can use the built in iMovie Titles, but they seemed quite limited (and not really intuitive to use). Instead, I just put together two PNGs in Pixelmator, also allowing me to use my app background as the background for the screens.
  • Add transitions between the video segments. iMovie has some nice animations for this.
  • Use the preview to check if things are looking and sounding good.

Here’s a look at iMovie with the title screen, some transitions, and the video and audio segments lined up:

iMovie

Embed video on your website

Once you have a finished video in iMovie, you can export it to youtube. (You need a youtube account for that.) Once the video is on youtube, add some meta information using the youtube site. You can then use the ‘Share’ tab (‘Teilen’ in German) to get embedding HTML for your website:

EmbeddingYouTubeVideo

All that’s left to do is to add this code to your own website. Done!

Using imageNamed to pick the right image file

February 5, 2013 by · Leave a Comment
Filed under: iOS 

When designing an iOS app for different devices in the iOS family, there are a lot of different sizes (and corresponding image files). Rather than having to code all the different cases, UIKit’s UIImage imageNamed can take care of it. This is achieved by using naming conventions, so that UIImage can choose the “right” image file depending on the device the app is running on.

Elements of the “imageNamed” Naming Convention

In order to have a call to

[UIImage imageNamed: <base name>];

return the right image, the full name of the image files (and the corresponding elements in Xcode’s Project Navigator) should be constructed like this:

<base name><iPhone5 element><Retina element><iPad element>.<image type>

Here are the elements used to construct the complete file names:

  • iPhone5 images get a “-568h”
  • Retina resolution images get a “@2x”
  • iPad images get a “~ipad” (case dependent)
Some additional points:
  • I found that this works for .PNG images, I couldn’t get it to reliably work for JPG images.
  • I’ve heard conflicting information whether you can drop the retina element for an iPhone5 image. Some posts are reasoning that it’s not needed as there is no non-retina iPhone with a 568px height. However, I found it only worked consistently with the “@2x” element.
  • This convention does not differentiate between landscape and portrait images. If you want to use different images, you have to use different base names, detect the current orientation and choose the right “class” of images.

Complete File Names for different Devices

Putting these elements together, we get the following file names for the base name AppBg (short for App background):

Device Naming Convention Example
iPhone (Non-Retina) <base name>.png AppBg.png
iPhone (Retina) <base name>@2x.png AppBg@2x.png
iPhone5 <base name>-568h@2x.png AppBg-568h@2x.png
iPad (Non-Retina) <base_name>~ipad.png AppBg~ipad.png
iPad (Retina) <base_name>@2x~ipad.png AppBg@2x~ipad.png

Usage

So when you are using the method call

[UIImage imageNamed: @”AppBg”]

the result will automatically contain the right image for the device your app is running on.

In addition to using the right image in your code (e.g. for the background image), this name convention also applies to the “Default” image that is used as the “splash screen” when an application starts.

“Free Initial Release” discussed on CoreIntution

February 4, 2013 by · Leave a Comment
Filed under: iOS 

One of my favorite tech/developer podcasts, CoreIntuition by Daniel Jalkut and Manton Reece,  discussed the “Free Initial Release” strategy on their Episode 75. As fas was I understood them, the episode title “Please Don’t Make The Same Mistake” does not refer to “FIRST” – even though they were quite critical of the idea. As I’m not really productive after staying up till 5am to watch the SuperBowl, I just wanted to give a summary of their discussion. (Main points are from Daniel and Manton, some of the words are mine.)

CoreIntuition’s View of “FIRST”

Daniel thought that FIRST would be “too obviously scheme-y” and could project the wrong image. Initial users (who got the app when it was still free) would look bad if they recommended “this great free app” to their friends, only to find out it wasn’t free any more. At a minimum, you have to make it very clear that the app is only free for a limited time (and even then some will miss that statement).

Manton suggested that it is undervaluing your work – “free app = not worth anything”. Trying to work in the “bargain basement” works for some apps (and he probably meant that you don’t want to be in that market as an Indie Developer).

Basically, they both suggested not to over think things and do the simple thing: Make something that’s worth buying, call it 1.0 and charge for it from day one. (They also mentioned Gus Muellers answer to “Why doesn’t my app sell?”: “Maybe it just sucks.“) Both believe that useful software does finds a way of getting sold.

Their Suggestions

They also suggested alternatives :

  • Release a free “technology preview” or beta, but make sure that you have a way of contacting these users so you can “convert” them to paying users later. (This is probably impossible in the iOS AppStore but may work when developing Mac software.)
  • Create a “freemium product”: A basic free product, which serves as a platform of selling a “Pro” version or additional features (possibly through InApp-Sales).

My Take on their Discussion

All they had to base their discussion on was a short tweet about the basic idea of “FIRST”, so they discussed FIRST in a scenario that is a little different than my situation. (That’s totally normal and certainly no criticism on their views.) Overall, I found the discussion very interesting and I am re-thinking my pricing strategy. I especially found the “don’t over think it” sentiment very compelling. Thank you very much, Manton and Daniel!