Rune's Blog

A blog about code, graphics, UI, marketing and whatever else interests me. Follow me on Twitter: @runmad

Assisted word of mouth: Get users to sell your app

Posted by Rune Madsen on April 18, 2011
Posted in: #idevblogaday, App Store, User Experience, User Interface. 2 comments

You can spend lots of money and time advertising and promoting your app. Advertising your app through social network sites and Admob and the like is pretty well the most wasteful and ineffective way of spending your money, in my opinion.

Spend your money and efforts in developing an amazing and great-looking app that will naturally attract users to your app. Spend the money on hiring a graphic designer or other efforts that goes directly towards making your app better.

Most users find out about your app from friends

In this post, I will detail another great addition you can add to your app, which will help sell more copies, let’s call it: “Assisted word of mouth.”

While everyone strives to reach top App Store ranks and have their app featured on various lists, only a select number of apps reach the top rankings, and mostly only for a somewhat short period of time. The top ranks and featured lists are a great way of attracting new users, but these spots are mostly occupied by the same apps week after week.

Consider how often you have heard “Check out this app I just got!” or “Can I check out what apps are on your iPhone?”… That’s right, lots and lots of iOS users hear about apps from their friends, a reliable source they can rely on for input about the latest and greatest apps. A lot of users also get a kick out of being one of the first users of an app, or the one to discover a new great app. “Check out this app, I have discovered.”

Let’s assume your app is great, your users simply love it and you could potentially sell a lot more, if only more people knew about it.

Gifting

I suggest that you include an easy way for your users to to share the app and their experiences with the app via email, SMS, Twitter, Facebook and most importantly through gifting.

I have a feeling lots of App Store customers do not know about the gifting feature. Imagine if you’ve already convinced one person that your app is awesome, they’ll actually purchase your app again and give it to their friend/family. You’ve just saved yourself having to try and get that person’s attention and convince them why they should buy your – their friend and your current user just did!

While this isn’t factual, I actually think users find it much easier spending another $1.99 (or whatever your app costs) to give a great app to a friend, over buying the app without knowing anything about it. Once the user is hooked and love your app and want to share the experience with their friends, they’re more prone to purchase to app again for a friend.

Sharing options

Following in the footsteps of my previous #idevblogaday post, App support: What’s it worth?, I suggest that you place a simple link in your settings view, or perhaps on your main screen if your app is a game, calling it “Share [APP NAME] with a friend” or just “Share App” if you’re using a smaller button.

When tapping the button, bring up a UIActionSheet with your sharing options. In this example, I am not including Facebook, but add it if you want to. Note: Be sure only to display those options available on the device (so no “Email” option if the device doesn’t have an email account setup, and no “Text Message” option if the device does not support text messaging).

Custom, direct-to-App-Store URL

Create a custom bit.ly (or other) to your app, so it’s easily read and remembered. For example, I created http://bit.ly/NextTTC for my app Next TTC.

Make this link directly to the App Store, not your website. You can only assume that a user will share the link with someone they already know have an iOS device, getting them one step closer to a purchase when they don’t have to visit your website, however great it may be. When they open the link on their iOS device or desktop, it will automatically open the App Store (or iTunes preview site if iTunes isn’t installed).

Use the link in all the sharing options even use it for the gifting option, since it allows you to track clicks. Or use in-app analytics, or create several custom URL links for each option if you want to see stats for each.

Use a short and catchy tagline to use in text messages and Twitter, so it fits within a tweet and text. The users can add/erase text if they want. I use the following: “Get instant, location-based TTC streetcar arrival predictions with Next TTC for iPhone http://bit.ly/NextTTC”.

For the email sharing option, consider creating a nice template instead of just “Hey check out this app {link}”. Mike Piontek (@robotspacer) from June Cloud uses a beautiful template when sharing deliveries (and it’s also a great way to share a link to his app) in his app Delivery Status. MFMailComposeViewController takes HTML and CSS, so you can get pretty creative.

For Twitter either use have the user select their preferred app, or just link to Twitter (twitter://post?message=TEXT) or another app like Tweetbot (tweetbot://screenname/post/TEXT) or just the Twitter website (http://twitter.com/?status=TEXT).

Lastly, the gifting option. As I mentioned earlier, this feature is somewhat unknown to lots iOS users, so if the user selects this option, a brief description in a UIAlertView is probably a good idea.

Once all this is done, you should be all setup and hopefully see some additional sales without a lot of additional effort!

A few points from this post:

  • Traditional marketing and advertising efforts can be expensive and exhaustive
  • Word of mouth is the most effective advertising you can find!
  • Give the user several options/ways to share a link with their friends: Twitter, Text Message, Email, Facebook and App Store Gifting
  • Use a custom URL which links directly to the App Store, so you don’t create an extra step to your website where you potentially loose their interest
  • Consider tracking effectiveness of each option. If gifting is pretty effective, maybe place it in its own option right on your About/Main/Settings screen
  • If you got the time and skill, create a nice email template
  • For the gifting option, briefly explain to the user what will happen and what steps are required to gift your app, since gifting isn’t a widely known feature of the App Store

Hope you enjoyed this post! By the way, I’ll be at WWDC again. If you’ll be there too let me know. Follow me on Twitter (@runmad) and let’s meet up!

App support: What’s it worth?

Posted by Rune Madsen on April 4, 2011
Posted in: #idevblogaday, App Store, User Experience. 4 comments

Hello again! I previously wrote a number of entries for #idevblogday last year and am happy to be back (especially with the new bi-weekly format). Since I last posted I’ve released a new app, Next TTC, a location-based arrival prediction app for Toronto’s streetcars (soon buses). Check it out if you live in Toronto and ride the TTC :)

In this post, I’ll be talking about customer support/service and what it may mean to you, your customers and your sales. I had been drawing blanks for a subject, so it’s based on a suggestion after discussing this with a friend. Skip to the end if you’re pressed for time for a important-points-summary of today’s post.

In-App Support Emailer
I always add an in-app email feature to my apps, where my customers can easily and painlessly email me on a support email address I have set up for this purpose. When the user taps the feedback/support button, I display the following alert:

This generally help establish a purpose and set some general expectations for the feature. I also take the chance the automatically add some variables that may be of use if I need to debug a problem the user has, saving me and the user time emailing back and forth to establish which device the have, what version of the app and OS they run, etc.

While this feature is great for all apps, you may want to leave it out in a free app, depending on it’s features or purpose. If you have IAP, go for it, but if the app makes you no money whatsoever, perhaps reconsider adding the in-app emailer – because you will have to do some support work!

The reason for this is that you will get more emails than if you made it harder for the user to contact you (via support link in the iTunes App Store, etc.). However, in my experience, they’re often just short emails, asking for a specific feature, asking for help on something, and it often takes me very little time to answer them. Most of the time, I am able to copy a previously sent answer, since a user may have had the exact same question or issue. For example, in my app Next TTC, I’ve had more than 20 customers email and ask me why they cannot get arrival predictions for the streetcars that run at night. While this is stated in the App Store description, it is perhaps annoying to answer the same question over and over, but it’s easy if you can copy previously used answers, and I’ve had a lot of great feedback from customers who are genuinely happy about my prompt replies, even if it wasn’t exactly what they were hoping for (unfortunately data isn’t provided for the nightly streetcars at this time, if you were wondering).

In-App FAQ/Help article
Another quite helpful and fairly painless feature to add to an app is an “FAQ” or “Help” section. I won’t discuss the technical part of integrating this, but a solution could be local plist (or server-side) or through a UIWebView using jQTouch to make it look somewhat native.

While an FAQ or Help section is great and useful for anyone in the beginning, my suggestion is to not spend a lot of time on this feature (or the content) until you actually have an idea of the most frequently asked questions. If you combine it with the above in-app support email feature, you will quickly get an idea of what your users ask the most from the emails you receive.

This way you won’t be spending time on FAQ content that nobody will read anyway. I’ve seen apps with help sections that explain the most basic parts of the apps UI, such as how to go back in a UINavigationController stack (obviously without the technical terms), and other completely standard things that almost all iOS apps that use UIKit have. Even if you’re using custom UI or gesture-based UI interactions, consider whether it’s completely necessary to spend your time writing all that content. Besides, your UI and interaction with it should be intuitive and require no explanation at all, but come naturally at least after a few uses ;)

Once you have an idea of the most asked questions, comments, etc. through the in-app support email feature, put together some articles that your customers can read. If you still receive emails about a questions answered in an FAQ article, simply refer to the article in your app in a friendly manner and let them know they can email you back if they still have any questions or concerns.

Games should usually include a tutorial or guide, which does the job of Help articles. You can always add an in-app support emailer or help articles as well, of course.

How much support does $0.99 buy a customer?
Well, technically you only get 70 cents. Or 70% of however much your app costs.

It’s up to you to decide how much support you want to provide for your customers. If you’re finding you’re receiving a lot of emails regarding bugs or issues with your app, you’re definitely doing something wrong and you need to address the issue with your app. If your UI or a feature isn’t self-explanatory and easy to use and confuses your customers more than it helps them, remove it or change it.

In my experience, answering support emails can be done fairly quickly (for most devs, unless you have a best-selling app with huge amount of users). I usually take a small portion out of my day and answer all emails (if any, I may add) quickly and painlessly. If I only get one a day or so, I’ll just do it whenever I get a chance, on the streetcar, on the couch or during my lunch.

Be careful answering your support emails from your iPhone. Depending on the length and answer, answering it on your iPhone really does show in your language. Sitting down at your computer to type out a proper answer is always a better idea, and it also makes it possible to use signatures as a quick way to answer a frequently asked question.

What does great customer support buy you?
While support requires a bit of work on your behalf, one might wonder if it’s worth it. Basically you’re offering free support to customers who have already paid for your app. Your time spent developing the app is already more than what $0.99 should buy and I think many will agree.

From personal experience, a number of my support communication emails have lead to some great word of mouth and some great reviews from highly satisfied customers. I have even had customers where I have simply not been able to help them (it’s been an issue with the data, their device specifically or something else completely out of my hands), but because I have been honest, friendly and prompt, my customers have responded extremely positively and are generally always happy with my support, regardless of whether I was able to solve the issue immediately, or bring them good news about upcoming features.

I’ve also taken the opportunity a few times to tell the user they’re more than welcome to add a quick rating/review in the App Store. You’ll have to judge the situation and please don’t add it in your first response. If you’ve been emailing back and forth and the customer seems happy, go ahead and ask. Otherwise let the user judge and review/rate if they find it’s worth it.

A few points from this post:

  • You might be a developer, but you’re also expected to provide some level of support.
  • Remember, these people (usually) paid for your app. Regardless of the cost, you have their money and they deserve some support – especially if your app isn’t working as expected.
  • Don’t get cocky or disrespectful, no matter what the customer writes. If their email is hurtful and you cannot say anything nice, don’t reply. It’s not worth it, and you’ll piss them off even more and waste your time (the user can threat you with a bad reviews, or get upset and just do it anyway). I know you’ve spend weeks if not months and many long nights coding your app, but do not take it personally. Unfortunately the most happy customers and users are usually the least vocal majority. Move on and focus on all the positive things people are saying about your app!
  • Add an easy way for your customers to contact your for support within the app, and remember to add anything to the email body that may be useful for your debugging (without being intrusive and adding sensitive user data).
  • Based on FAQ through your in-app support emailer, add a FAQ/Help section.
  • Take your time to reply back to your support emails. Preferably use a computer (or an iPad with a bigger screen), because it may show in your writing style if you reply on your iPhone. Don’t let support emails sit for days. The longer you wait, the more time you give that user to submit a negative review as a way to report the bug, and they may not remove it even if you reply and resolve their issue.
  • In-app support email and FAQ section will increase your app’s rating score. If your customers cannot contact you easily to complain about bugs or issues with your app, they will definitely do it with a one star review, which can really hurt your App Store ratings!
  • On the other hand, if you provide great support, customers will return the favour (even if you don’t ask them to) and submit a positive review for your app and help spread the word to their friends on Twitter/Facebook.

Hope you enjoyed the post. Feel free to add your comments from your experiences dealing with your customers and app support. If you’ve got some great tips, even better!

Social game marketing

Posted by Rune Madsen on November 29, 2010
Posted in: #idevblogaday, App Store, Gaming, iPad, iPhone, iPhone 4, User Experience. Tagged: facebook, game center, game saves, games, iPhone, loyalty, loyalty programs, marketing, openfient, sharing, social, twitter, user experience, ux. 5 comments

I’m not a game developer and was actually not planning on doing a game-related post for #idevblogaday, but I’m currently reading Game-Based Marketing about how marketers can use game mechanics to create and foster long term customer loyalty. Basically think frequent flyer programs, points cards and any other type of loyalty program out there.

As a marketer, the premise of the book is quite interesting, and today almost any major chain will have some sort of loyalty program – even in smaller businesses you will find sorts of loyalty program through which you can earn points, loyalty and status amongst peers (much like achievements, leaderboards, etc. that you’ll find in games).

It got me thinking a bit about how game developers should try and utilize the same kind of systems that are in place for loyalty programs. For example, a big part of loyalty programs is earning points, achievements and essentially status within a certain program. People love showing off and they love earning points and higher statuses – even if it doesn’t really get them anything in return.

So in this week’s post I’ll discuss various ways game developers can implement different strategies that are found in loyalty marketing. I’ll discuss features that are well known and quite common in most top 25 App Store games, but at the same time, I hope to bring to light some aspects of these features.

Leaderboards
If you’re currently reading this and have a game in which you do not have a leaderboard, stop right now and start integrating one immediately.

A great part of the fun of playing games are being able to share with your friends your scores, points, etc. Also, being able to compare yourself directly with other players or friends playing the game is an important part of the fun.

The best way to do this is through an integrated leaderboard system. This allows the player to easily keep track of their score and abilities and compare them with their previous scores and how they rank amongst their friends and other players worldwide (or perhaps even cities, states, countries, etc.).

Game Center, OpenFeint, etc. provide easy-to-implement and solid foundations for leaderboards. These are also awesome (and free) marketing tools. For example, I have found myself looking through my GC friends games lists to find new games to play. It has also kept me coming back to certain games because GC has provided an opportunity to indirectly challenge me to continue playing the game to beat certain friends scores. This in return provides you as a game developer to cross-advertise your new game releases or sales for your other games.

Although competition is great, I wish more developers would integrate GC or OF (which also offer built-in GC integration), instead of trying to roll their own or using a less popular social game network. For example, when GC was released, I found myself revisiting old games to beat my friends’ scores or earn achievements. Those games that still do not offer a widely-used system just doesn’t draw enough attention, and I cannot be bothered to find out my friends’ usernames on the not-so-well-known social game networks.

Achievements
Achievements are also a great way to provide a leaderboard-type system in your game. It also helps prolong the experience and fun with your game.

A few examples of use of achievements in games:
• Achievements provide an opportunity to easily reward the player throughout the game. Levels, new upgrades, etc. This helps create a path for your game and a path for completion.
• Think of achievements that would require more practice or more time playing, basically ones that would prolong the game for players for after they’ve finished all levels. For example, Cut the Rope could use a timer and an achievement for finishing certain levels in certain amount of time, instead of just the three stars. You do earn more points for finishing a level fast, however this isn’t apparent, and after finishing the levels I cannot see how much faster I should have been in order to earn more points. Another example of achievements is Trainyard, which could give an achievement for finishing all stations in one city by using only X amount of tracks. These two examples provide a way to challenge the more hardcore players since they’re considerable more difficult than pure completion of a level, and it also does not hinder the completion of the game for the more casual players.
• Be careful not to make achievement nearly impossible to obtain. For example don’t make an achievement for “Played 100 hours” if your game basically takes an hour or two to finish all levels. Unless there’s a lot more to your game after having finished it, you can’t expect anyone to want to spend so much time playing it – even if they love going for those achievements.

Again, Game Center and OpenFeint provide great frameworks for integrating achievements as well as achievement leaderboards and friending systems. Use one or both of the solutions and think of ways to achievements into your game to make it more fun and challenging. They’re completely free and helps save you a ton of work instead of trying to roll your own.

Small side-note to leaderboards and achievements: Add a button somewhere in your games’ menus that let’s the user see their scores and/or achievements. Both GC and OF offer modal views for these. This way the user doesn’t have to leave the game to check an achievement or whether they’ve now trumped their friend’s top score, and you also help bring them right to the information they’re seeking – not leaving them to go to GC via the app itself, for example, and drill through the view hierarchy in order to find what they’re looking for.

Social Sharing
Sharing high scores, achievements, etc. is great opportunity to advertise your game and something that players love to do!

However, instead of just providing a Facebook and Twitter button for sharing a score or achievement, why not go a littler further and help the player out with deciding when it’s appropriate to do so? For example, what might seem like a low score to one player, may turn out to be in the top 5% of the leaderboards. After completion of a level or game, the developer could integrate a system that looks up the score and based on various factors it may say something like “Holy shit, your score was super high, you’ve just entered the top 10%, you should totally brag about it on Twitter and/or Facebook!” – or something like that. This helps the player realize the worth of their skill and score and may actually be more effective than just having a button that enables sharing of a score on social networks.

Also, don’t just tweet a score plus a link. Players will look through this as a pathetic attempt from you to get some free advertising out of them. They already paid you money, why should they help you out more, even your game is the most awesome one ever made?

I realize you don’t have a lot of characters to work with on Twitter, but including more than just the score is important. If I see “John just scored 13,453 in [some game]!”, I don’t really know whether it’s a good score and it doesn’t provide me with a way of relating this score to my own skills (unless I have played it). However, if I see something like “John just placed in the top 5% in [some game] with 13,453 points!” I would be more interested and perhaps more inclined to try out the game and beat John’s score if I know we have similar skill and scores in most games. It also gives both John and his friends a better understanding of just how awesome getting 13,453 points is. Without relating the points to anything, no one can see whether it’s actually a good score if they don’t know the premise of the game and the value of those points. John might actually be tweeting a super low score (compared to his friends’ scores), so helping John decide when it’s an appropriate time to share his score helps him save the embarrassment of tweeting a humiliatingly low score.

Basically, adding more substance to your sharing feature gives you more respect from your user (surprise and delight) and also makes them more likely to actually indirectly want to help you advertise (which you have to admit; you’re adding this feature more for yourself to advertise than actually just scoring some random score).

Another great way of sharing content from your game is something like Matt Rix‘s Trainyard solution sharing system. It works both as a way for players to show off their skills, but also helps more casual players progress through the game. Hardcore players love showing off and it also provides a way to prolong the game for hardcore players as they may try and find new solutions that haven’t yet been done. Linking this with the previous paragraph, one thing the game could do was to provide a small notification if a solution is 100% unique by saying “You have created a unique solution not yet available on Trainyard.ca, would you like to share with the community?” This helps the player realize their skill compared to others and again provides the more hardcore gamers with replay value, as they may go back to some levels in order to make new solutions, not yet seen by the community. That in itself could create a separate leaderboard for players which shows the top 50 players who have come up with and shared unique solutions, again improving the experience and loyalty further for those committed to the game and the community that surrounds it.

Game save syncing
This is as much of an idea as it is a request to all game developers out there.

Universal games are starting to become more common, now with iPhones, iPods touches and of course iPads selling like crazy. I own both an iPhone and an iPad and love when developers take a bit of extra time to release their game as a Universal game – even if the iPad is pretty much the same as the iPhone game, just larger. Of course, not all games scale as easily from iPhone to iPad in terms of the experience with the extra space, but for games that I play both on my iPhone and iPad, I would love to see server-based game save syncing or whatever you want to call it. However, this doesn’t just go for Universal apps, since many people have several devices. If they have the same game installed on both their iPhone and iPod, why not make the game experience more fluid?

The premise of this idea is dead simple: I play a game on my iPhone on the subway home from work. When I get home and hit the couch later that night, I want to reach for my iPad on the coffee table and play the exact same game, from the exact point I left off. I don’t want to start over from level one. I don’t want to have to earn the exact same achievements I just unlocked four hours ago (especially since they’ll appear as unlocked just fine if I head into Game Center).

Again it might be something 80% of users wouldn’t need. You may never have had to bring your game saves on your Wii controller to your friend’s place or transfer your PS3 game saves to your buddies PS3 so you can show of your collection of sweet cars in GT5. But it’s something we have now seen in console games for well over a decade now. As much as it may be a less used feature, it’s something I just don’t understand why is missing on such a portable platform.

It could be somewhat simple, depending on what your game exists of. When you start adding stuff like specific amounts of bullet ammo left, percentage of health left, points in each cleared level, etc. we’re getting a bit more advanced, but it’s definitely possible, regardless.

Game saves could be saved on a server and retrieved using an email and password. I don’t know the exact workings of GameKit, but maybe a successful login to Game Center could prompt a “It appears you have a game save available in the cloud based on your GC username, would you like to sync this device and keep your progression in sync?”. (If anyone at Apple is reading this or if you know someone working on GameKit, please let them know to consider adding game save-syncing to Game Center :))

Or even something like bluetooth sharing of game save states, bumping devices, or sharing via a unique code displayed on one device and entering the code on the other device would retrieve whatever was just uploaded to the server.

Just a few ideas of how you may be able to work it out, but seriously, this is such a great feature that would really set your game apart from others (apart from being a unique experience in itself, of course) and your users will love it.

I have yet to come across a single iOS game that does this, so if you know of one, please do share it in the comments, so other developers can check out and perhaps get some ideas for their own game.

Wrapping up
I hope I have sparked some ideas into your head as to what you can do to enhance the experience with your game and creating some loyalty amongst your customers. Some of the above ideas definitely will enhance and prolong the game experience, adding value to your game from what is actually very little work in most cases, implementing GC or OF or enhancing score-sharing on social networks.

Thanks for reading and please do leave a comment!

Random tips

Posted by Rune Madsen on November 22, 2010
Posted in: #idevblogaday, Code, Objective-C, User Experience, User Interface, Xcode. Tagged: #idevblogaday, shadowcolor, shadowOffset, ui, uilabel, uinavigationcontroller, uitoolbar, url, Xcode. 2 comments

I was expecting this blog post to be about something completely different, but I’m still out of the country and have come down with a bad cold, so it’ll be a bit of a short and simple.

I’ve decided just to a few coding tips, I have come across and though might be useful for other devs, especially if you haven’t worked much with UIKit before in your development, or perhaps just these areas below. (At the bottom of this post is an Xcode project file which includes examples of the tips below).

Tip #1: Check for URL scheme and open correct app from your own
You’ll probably run into having to link to another app, for example your company’s Twitter account. Instead of just linking to the Twitter website, you can do a quick check in code and open the Twitter app instead. You can also do it with other Twitter client apps as well, however, not all have URL schemes setup (that I could find), and most users will probably be using the official one anyway. Regardless, the code is good to do the same check for other apps, or if Twitter.app doesn’t exists on the user’s device, you can try another Twitter client app, or use a UIAlertView to ask the user what else they’d like to use (depending on which ones are possible to open using the URL scheme).

Basically, all you have to do is ask whether UIApplication responds to the URL:

BOOL twitter = [[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"twitter://user?screen_name=runmad"]];
if (!twitter) {
	[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"http://www.twitter.com/runmad"]];
} else {
	[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"twitter://user?screen_name=runmad"]];
}

List of URL Schemes: http://wiki.akosma.com/IPhone_URL_Schemes

Tip #2: Getting a free UINavigationController in your UIViewController
I have seen some apps that use a UIToolbar as a navigation bar, and this just doesn’t work. If you compare the two, they’re actually a bit different, and this really shows when put in the wrong place.

If you’ve got a UIViewController, turning it into a UINavigationController is really easy:

RootViewController *rootViewController = [[RootViewController alloc] init];
UINavigationController *navigationController = [[UINavigationController alloc] initWithRootViewController:rootViewController];
[self.navigationController presentModalViewController:navigationController animated:YES];
[rootViewController release];
[navigationController release];

Tip #3: Getting a free UIToolbar in your UINavigationController
This one I only just recently found out (thanks to @auibrian)
. UINavigationController actually comes with a UIToolbar. It’s property is set to hidden:YES by default, so all you have to do is override this property when you load the view.

[self.navigationController setToolbarHidden:NO];

Note: I have seen some weird behaviour when pushing view controllers onto the screen (buttons not getting a pushing animation, just appearing in the toolbar in place). Also, you will need to hide the toolbar if you’re popping or pushing to a view controller that you do not want to show the toolbar (because with pushing you’re reusing the same navigation controller). In my opinion it’s not a very good way, I wish the view controllers were more separate for this.

Tip #4: Use shadowColor and shadowOffset appropriately when faking text indention
One thing that bugs me are improper use of a UILabel’s shadowColor and shadowOffset. When using these, one has to pay attention to the colour of the background as well as the text colour. In the below example (when we’re going for the look where text looks carved into the display, used by Apple across the entire UI), we’ll see that when using darker text, use a lighter colour for the shadow and a positive value for the offset.

When displaying lighter coloured text, use a darker shadow colour and a negative value for the offset, which in both cases create the proper indented or “carved” effect.

Using the wrong combination doesn’t create this effect and makes the text appear raised from the rest of your UI, which is most likely not what you should be going for in most cases ;)

I’ve made a small Xcode project you can download here, which has the code examples from tips 1, 2 and 3 and I suppose #4 as well, since navigationItem.title is using text indention.

Again, apologies for a bit of a short and simple post due to being under the weather and traveling.

How updating apps could multiply sales

Posted by Rune Madsen on November 15, 2010
Posted in: #idevblogaday, App Store, User Experience. Tagged: #idevblogaday, App Store, developer, iOS, marketing. 12 comments

This will be my first #idevblogaday post, so I’ll just briefly introduce myself and then get on with my post. Follow me on Twitter: @runmad, by the way :)

I’m writing this on a flight from Toronto to Copenhagen on an iPad so hopefully it’ll turn out alright. I was afraid my turn for #idevblogaday was going to be exactly when I was going away on vacation, and sure enough @mysterycoconut tweeted @ me the day I was leaving that I’m up, so here we go.

I’ve done development for about 1.5 years now, Objective-C is the only programming language I know. I have a degree in marketing and management communication and years of experience in graphic design. I love experience marketing and sensory branding. I got into iOS development because I loved how (then) iPhone OS brought to life an amazing UX through great hardware, UI and functionality. A great iPhone app is a mix of marketing, design, experiences, sensory triggers and of course, code. So I started learning the coding part and have found that knowing all the rest really does help and benefit you!

I work for online retailer and I have built an iPhone app that allows you to browse our products, purchase them, check orders, etc. You can check it out here.

They’re not “users,” they’re your customers
In developing apps (games included) for iOS devices there’s always a question of doing updates. You’ve released a rock solid 1.0 and then comes the mandatory point update(s) with nasty bug fixes.

Your app sold a few hundred copies (or thousands, congrats) after first releasing it and has since then steadily not sold very well. Should you care to do actively pursue further development and thereby bring more features and goodness to your customers who already paid for your app? Let me try and convince you to do just that.

I’ve read a bunch of posts on IAP and how this has revitalized sales for a game. Noel Llopis’ (@snappytouch) Games From Within blog to read a few posts on his experiences with using IAP to boost sales for his game Flower Garden. IAPs are definitely awesome, and I guess this post will be more of a idea that would compliment IAP in certain instances (depending on what kind of app you have).

I had no Internet connection while writing this, so I have no links for facts and figures but go by general knowledge and my perception of scenarios. Trust me, it’ll be awesome anyway, facts are hugely overrated, right?! You might not agree with me, but feel free to leave a comment and we’ll talk ;)

Joking aside, let’s have a look at why I think you should create and submit meaningful app updates, somewhat regularly.

We all know that App Store customers are greedy. You give them a free app, they want an arm. You sell your game for less than a buck and they complain about there only being 150 levels which meant they finished it in a day because it’s so good (telling you they’ll reward the last, fifth star when you release an update with a billion levels).

Let’s stick with that dollar. How much are you as a developer, as the seller, willing to put into your work after it’s out of the door and the first point updates are released to fix those nasty bugs? I know developers generally hate when customers complain about a one dollar app in a review, but look it this way: They paid you money. They bought something from with their money. They feel entitled as your customers. I bet many indie developers didn’t expect to have to deal with customers when they started iOS development, and are unfortunately surprised by it. It might just be a buck, but this dollar can lead to much more money if you take care of your customers. Give them more than what they came for and they’ll help your sales grow by spreading the love through word of mouth.

The dilemma you have is whether, once a customer has paid for an app, should they receive more? Sure, you can sell level bundles or other objects related to a game with IAP, but perhaps you could also just give this to your customers for free… Or if you have a non-game app, it’s not easy to sell app features as IAP, and I’ve never personally been a fan of apps that have a “Pro” version.

Spreading the love
When was the last time you told your friends not to miss out on a dinner at that restaurant where the waiter treated you like shit? And how many times have you been back to that awesome bar where they tend to free-pour rather generously?

Let’s look at free-pouring. Angry Birds. I would say it’s probably the most popular app ever. It rival sales numbers (not profits mind you) of major console franchises and why wouldn’t it, it’s a buck! Buying this game is a no-brainer for most people, even the greedy ones. You get so many levels it’ll take you days if not weeks to finish. Once you’ve finished they throw more free levels at you in a free update for that one dollar you spent two months ago. They’re clearly insane, right?!

In my opinion (even if this isn’t their intention) it’s a quite clever marketing move. Every single time Rovio releases an update to Angry Birds you’ll tap open that game while riding the subway with hundreds of other people seeing you play this game. You’ll remember how much you love that game and be sure to tell your friends with iPhones (and now other platforms) to download it. You haven’t left a review yet, but feel that now is the time to do so. You’ve had so much fun playing this game – and still do with new levels! – that they deserve that quick 5 star review.

App update sales multiplier
Let’s say Angry Birds has sold 1,000,000 copies (it’s sold a lot more but let’s stick with a nice, huge, round number). Of this 1m downloads, 95% still have it installed and have played it within the last two months. (It’s my belief that a paid app actually stays on a users home screen way more permanently than a free app. It’s like throwing out a dollar and it doesn’t take up any physical space in your life even if you don’t use it. Apps that stay on the device (not just iTunes) are way more likely to receive attention when updated in the App Store.) Angry Birds gets an update with fixes but, more importantly, a new world and 30 new levels or so. Of these 950,000 active customers, let’s say most will update at some point. 10% of these people will tell their friends. On average these 10% tell two friends about the game. Of these 190k people who now know about Angry Birds, just over half will go to the App Store and download Angry Birds for a dollar (it’s a no-brainer price).

So now, from a free update, Angry Birds just made another $100,000 (before a 30% cut) on top of that 1 million copies already sold. Of course I was using the highest grossing game, but I still believe it this ripple effect holds true for your apps. If you reward your customers and exceed their expectations, trust me, they will reward you back by word of mouth, which lead to more sales.

You’ll always have those vocal, annoying customers with horrible reviews and ridiculous expectations, but don’t forget the people who often are the least vocal to you are often really vocal about your app/game to their friends. Who do you trust most for advice on awesome apps, people who are clearly idiots from app reviews or your real life friends or people you follow on Twitter? My guess is the latter two. Just like the restaurant example earlier. You’re probably more likely to visit a restaurant based on a great review from a friend who recently went there compared to a review in a newspaper.

Active development
You may not be selling millions of copies of your app like above, but it doesn’t mean you shouldn’t pursue active development if your app has something going for it. Updates will remind your customers about your app. They’ll revisit the app and it’ll be first in their mind been their friends asks what new stuff they’re using on their iPhone, or which apps they should get within X category.

I know this comparison may sound insane, but it’s rather valid: Coca-Cola technically doesn’t need to advertise. It’s not like we don’t know what it is, where to buy, how it tastes and how it makes you feel, right? True, but when Coca-Cola spends millions and millions of dollars to advertise, they’re reminding you of the brand over and over and over. If you hadn’t just read the first part of this paragraph, I would bet money that you would have said “Coca-Cola” if I asked you to name a soda brand. This is because you have seen so many Coca-Cola advertisements and heard the brand name so many times over the years that it’s imprinted in your brain!

Same goes for your app. Remind customers about your app and be the first thing to come to mind when they think of awesome apps within your apps category/core functionality.

With all this said, don’t just release meaningless “bug fix” updates. People will see straight through this after several of seemingly pointless updates and only get annoyed that your app apparently is full of bugs. As @Jury said in a tweet the other day:

“… Compiled software is not the web. Don’t push every minor issue you fix immediately to your users. Plan discrete releases.”

Obviously, if you have a severe bug in your app, get it fixed asap, so your customers won’t grow resentful of the fact your app doesn’t work as expected.

So in review:
- Free updates help increase awareness about app.
- Awareness leads to re-discovery which helps keep your app “immediate” for users.
- Think of users as customers. You’re not doing them a favour by releasing an app. They’re doing you one by giving you money in return.
- Give your customers more than they expect and they’ll return the favour with a review or other kinds of word of mouth.
- Updates help provide value and helps your app exceed your customers expectations, regardless of the cost of your app.

Note:
- “Bug fixes” are not directly seen as value for your customers. Sure you fixed bugs, but what value does this bring other than just fix something that should have been working in the first place?
- In my opinion, too many “bug fix”-only updates that talk about “improvements,” etc. just become annoying and doesn’t show customers that you (the developer; or seller) is focused on building new features.

I hope you enjoyed my first #idevblogaday post. I hope it was insightful and invoked some thoughts as to what you could do with your app, even if I didn’t provide a single line of code :)

I do hope I surprised some people with how marketing blends in with being an iOS developer and provided some insight into what kind of relationship you have with the users of your apps.

Thanks for reading, sharing and please do leave a comment!

Have a wonderful Monday!

Quick guide to updating your app’s UI for iPhone 4

Posted by Rune Madsen on June 12, 2010
Posted in: Code, iPhone, iPhone 4, User Interface, Xcode. Tagged: display, experience, interface, iPhone, programming, retina, ui, user, ux, Xcode. 4 comments

iPhone 4 will make your UI look stunning. Everything in UIKit has been scaled up already so it will require only a bit of work on your end to make the rest of your app look amazing on iPhone 4. If you only code and don’t touch Photoshop, you’re in luck. However, if you’re a UI designer or have the skills to do your own UI, hopefully you did your original artwork in a nice high resolution – if not, you have a bit of work cut out for you with updating all the UI elements to 2x the resolution.

Updating your app’s UI to be compatible with iPhone 4′s Retina Display is amazingly simple. Since the scale works in points, not pixels, you will have to do very little work on the layout itself. Apple Engineers have made it really simple to use new graphics for all your UI on iPhone 4, at the same time as being compatible (and not using 2x memory) on older, lower resolution, lower memory devices.

All you have to do is add the same image file at 2x the pixels to your app’s resources and name it the same it’s lower resolutions sibling with the following suffix: “@2x”.

For example, in your Resources folder, you will now need to have two image files, one for older devices called myImage.png and one for iPhone 4 called myImage@2x.png, which is twice the resolution.

This way, when you call [UIImage imageNamed:@"myImage.png"]; (or contentsOfFile:) iPhone 4 will automatically grab the filename with a @2x suffix, and lower resolution images will grab the lower resolution copy. You don’t have to check for the device loading the image and write any additional code to grab the correct image. Genius!

If you have seen an iPhone app on the iPad in 2x scale, that’s pretty much how your app is going to look on the iPhone 4. Perhaps not so drastic, but there will be a noticeable difference from app not optimized for iPhone 4 and “Retina Apps” as Apple calls them.

Thoughts on @2x on iPad…
I didn’t hear anything at WWDC regarding this, but my thought is that they’ll integrate this into the iPad for the next major OS release. Basically, it will be able to do the same and grab the higher resolution image appropriately for iPhone apps running at 2x scale.

Happy Photoshopping to UI designers and happy relaxing programmers!

UPDATE JULY 7, 2010:

I have discovered a bug in Apple’s code that deals with grabbing the correct image on iPhone 4. If you are using imageWithContentsOfFile: the code will in fact not automatically grab the @2x if running on iPhone 4. I have submitted a bug report to Apple, and they’ve informed me they are now aware of the issue and the Engineers are currently working to fix the bug. So for now, stick with imageNamed: for all your images.

Debugging Executables for Push Notifications

Posted by Rune Madsen on June 3, 2010
Posted in: Code, iPhone, Objective-C, Xcode. Tagged: debugging, executable, iPhone, push notifications, Xcode. Leave a Comment

I am implementing Push Notifications in one of my apps. Doing so may be a bit tricky in terms of debugging since you cannot actually debug incoming Push Notifications appropriately while the app is running, so I wanted to share this tip. Also, I am writing this post on my iPad on an airplane, so pretty excited about that :)

Xcode allows you to debug applications that are running locally on your device. You can even set breakpoints in your code and print out any information you may need from the console in order to debug your app and fix whatever issue you’re experiencing, should you not be able to fix it via “live” debugging.

This feature is especially useful if you’re doing Push Notifications (a great way to easily communicate information to your user with their permission, such as notifications, reminders, marketing (be careful with this one), etc.).

With Push Notifications, your app receives data from Apple Push Notification servers in a dictionary in the UIApplication delegate application:didFinishLaunchingWithOptions: that you’ll need to parse and do in your app whatever is appropriate for the implementation you’ve chosen (launching with specific views in front, etc.). Since your app cannot be running while receiving Push Notifications (it actually does receive notifications while running, but you’re required to deal with that through another delegate method), you’ll need to use the “debug executables” with “Wait for next launch/push notifications” ticked. Once you run the debugger and launch your app (for example directly via a Push Notifications UIAlertView) you can set breakpoints anywhere in your code and use the console to print out (po) any objects you may wish to inspect.

As your app launches immediately when you debug, it’s a problem if you’re debugging Push Notification (which, by the way, does not work in Simulator). So here’s the hidden treasure in Xcode: In the Groups & Folder pane, find Executables, expand and select your app executable. Hit command+option+i to “Get Info” and select the Debugging tab. From here, tick “Wait for next launch/push notification”.

Now, when you Run & Debug your app it will not launch, but instead wait until you tap the app icon to launch it or the app is launched via a Push Notification UIAlertView (this of course requires you have not set the “action-loc-key” to null in your Push Notification JSON dictionary).

Once your app launches via a Push Notification, it will stop at the breakpoint you set and you can now print out any information you need to debug your app, such as the NSDictionary your app receives, whether the appropriate view will be displayed and any other issue you may have.

Some notes on UIView animation

Posted by Rune Madsen on May 17, 2010
Posted in: Code, iPad, iPhone, Objective-C, Xcode. Tagged: animation, iPad, iPhone, ui, uibarbutton, uiview, user experience, user interface design, ux. 2 comments

UIView animation is a simple and nice way to add to your user experience. I just wanted to point out a few suggestions when using UIView animations.

Duration (speed):
If you choose to use animation to compliment some of the stuff already happening in UIKit, either at the same time or before/after, it makes a big difference how fast your animations are. Pretty much all the UIKit animations I have come across have a duration of 0.3f and so should yours. Of course, it’s doesn’t always work 100% but for the most part, 0.3f is what you should aim for. It’s quick so your user don’t wait for something to finish animating before continuing with the next input action, and it’s not too fast so that the user doesn’t have a chance to see where the object came from or what happened.

If you have an animation happening while the keyboard animates up or down, use an animationDuration of 0.3f. Same with pushing and popping the navigationController. Annotations in MKMapView also drop at a duration of 0.3f.

0.3f is the way to go.

A simple UIView animation can be added with the following code:

[UIView beginAnimations:nil context:nil];
[UIView setAnimationDuration:0.3f];
self.segmentControl.alpha = 1.0f;
[UIView commitAnimations];

The above example is from an app I’m doing, where the segmentControl is enabled and I increase its visibility in the toolBar at the same rate as a pin drops in the map within the same screen.

When to use animation:
A few objects come with free animation (also at a duration of 0.3f, of course). For example, when adding a UIBarButton to your UINavigationBar, consider setting these with animation. If you replace a UIBarButton with another, they’ll even animate in and out nicely during the change. When adding a pin to a map, why not drop it onto the map with an animation, instead of it suddenly appearing on a map from nowhere?

Another good advice is to do animation (whether your own or with objects that include animations) to bring attention to an object. For example, if you have a pushed view, consider what you can “add” after the view has appeared through animating your objects in viewDidAppear.

Create a better UX with animation
Consider all the ways you can use UIView animation blocks in your app to enhance the user experience. It’s a great way to create a more fluid and pleasant experience for your users. A user’s inputs and actions will feel less rough and more smooth and soft to the touch. Don’t go overboard with animations. Too many will become annoying and it’s important to use animations only where appropriate.

The best advice is probably to have a look at many of the built in apps designed by Apple as well as the many free animations that a part of UIKit objects (how UIBarButtons animate in and out when you push a UIViewController stack, how a modal view appears from the bottom, etc.).

Why the whole world can’t have iPad now

Posted by Rune Madsen on May 11, 2010
Posted in: iPad, iPhone. Tagged: iPad, iPhone, manufacturing, release, supply and demand. Leave a Comment

I was chatting with a friend today regarding the possible release of iPhone HD on the day of this year’s WWDC June 7th keynote. This lead us to talk about previous year’s release dates and whether the iPhone HD will be available worldwide on the same day (or at least not a US-only release).

We all know the first iPhone was released a full year before becoming available anywhere else and that recently, the iPad was released in the US prior to becoming available in other countries, including Canada. The iPad’s international premiere was even pushed back another month due to the incredibly high sales in the US.

You may already know the reasoning behind the spread in release dates or perhaps you never thought of it, but just felt annoyed by not being able to buy awesome product at the same time as the Americans. Here are my three thoughts on why iPhone and iPad have been released with spread-out released dates.

1. Test the waters
The first iPhone was a huge step for Apple. Last time they released a similar product it flopped. Diving face first into a packed market place with so much competition and going head-to-head with companies such as RIM, Motorola and Nokia was a huge step. You can argue that Apple was more fit this time around, but it’s still a big step, even for a company like Apple. It’s simply too risky to go ahead and release a new product in an entirely new product category (one can argue that Apple extended the mobile computing category and/or mobile phone category with the iPhone) without knowing how the product will be received in reality (one thing is hype (read: geeks) another thing is public reception).

Obviously the iPhone was a huge success and there was a big demand from international markets as well. Following the first iPhone, new models have generally been released more or less at the same time.

Remember the first PlayStation? Yeah, same thing… It was an entirely (though less saturated) market for Sony, which meant a late ’94 release in Japan and late ’95 release for the rest of the world. With the PlayStation 2 and PlayStation 3, release dates have been considerably less time apart (6 months and 6 days, respectively) from Japan to US/Europe.

iPad is perhaps not an entirely product for Apple (Mac + iPhone = iPad), but the spread out release dates still gives Apple a chance to test the waters and adjust their strategy for the worldwide market as needed.

2. Supply and demand
Why was the iPad delayed internationally? Well, Apple actually said so themselves. The US demand has simply been too high to keep up with production. Nintendo saw the same issue with the Wii being sold out consistently for years (however, it was simply getting ridiculous after two years. That should be enough time to sort out the manufacturing bottleneck).

From previous experiences, Apple was wise enough to contain the release to one market first and once they can keep up with demand in that market, open up for more markets, doubling the possible demand for iPads. Some people would argue that it’s great for buzz and hype if there’s so much demand for your product you can’t keep up with production. This was maybe true for Nintendo (I can’t imagine how stressful some parents must have been, trying to find their kids a Wii for Christmas), but Apple has a pretty clean history of being able to keep up with demand. Both the iPhone and iPad have been easily available since launch. Sure, there have been a few times and a few places where it has been hard to obtain one, but generally, anyone, not only hardcore release-day-campers or those who pre-order a month in advance, have been able to get their hands on an iPhone or iPad. The iPad has already found it’s way into the hands of a diverse group of consumers – not only the early adapters.

3. Manufacturing strength
With any new product comes new manufacturing methods and requirements. This was true for the iPhone and is true for the iPad as well. Over the years, Apple has expanded it’s manufacturing facilities and collection of suppliers to accommodate high sales volumes.

I can’t imagine the cost of setting up a new facility to output an unproven piece of hardware and at the same time making sure enough products are initially manufactured to keep up with an expected high demand. Just the fact that they’ve been able to produce enough iPads to sell 1 million iPads in 28 days is incredible considering they’re also starting production on iPads for other markets.

The next iPad will probably be released in all the markets where the current iPad is already available (at that time), because Apple will simply have been able to ramp up their manufacturing to accommodate the demand.

That’s my take on why the whole world can’t have iPad at the same time as the US. Feel free to add anything in the comments below :)

UITabBarController and UIActionSheet – 65% less hit point!

Posted by Rune Madsen on April 1, 2010
Posted in: Code, iPhone, Objective-C, Xcode. Tagged: uiactionsheet, uiapplication, uitabbarcontroller. 7 comments

Ever noticed an app where the UIActionSheet’s bottom button doesn’t want to respond to your taps, unless you hit exactly in the top of the button? If you have a UITabBarController and want to display a UIActionSheet, you have to be careful with what view you show the UIActionSheet in.

If a UIActionSheet is shown in “self” or “self.view” and you got a UITabBarController behind it less than half of the last button will respond to taps:

UIActionSheet *actionSheet = [[UIActionSheet alloc] initWithTitle:@"UIActionSheet Title" delegate:nil cancelButtonTitle:@"Cancel" destructiveButtonTitle:nil otherButtonTitles:@"Option 1", @"Option 2", nil];
actionSheet.actionSheetStyle = UIActionSheetStyleBlackTranslucent;
[actionSheet showInView:self];
[actionSheet release];

Here’s how much of the button will actually respond to taps:

Here’s what you need to do to fix it:

[actionSheet showInView:[[[UIApplication sharedApplication] windows] objectAtIndex:0]];

And what it does:

Posts navigation

← Older Entries
Newer Entries →
  • Recent Posts

    • Making Rounded Rectangles Look Great (with CSS)
    • Final #idevblogaday post for this round
    • Accessibility on iOS: Working with VoiceOver support
    • Core Location presentation at TACOW
    • Next TTC follow-up + TACOW Meet-up tomorrow
    • Next TTC: Behind the scenes
    • WWDC in Pictures
    • Introducing GiftKit – gifting made easy
    • ColorKit: A Color Assessment Utility App
    • Faking depth and textures in your app
  • Recent Comments

    • Rune Madsen on Next TTC: Behind the scenes
    • Merch Visoiu on Next TTC: Behind the scenes
    • EeKay on UITabBarController and UIActionSheet – 65% less hit point!
    • vipul on Accessibility on iOS: Working with VoiceOver support
    • Tung Do on Colouring fun with moreNavigationController
  • Meta

    • Log in
    • Entries RSS
    • Comments RSS
    • WordPress.org
Proudly powered by WordPress Theme: Parament by Automattic.