Tap Swipe Pinch

Attending WWDC for the first time?  Here are five things you need to know:

1. It’s summer in California.  Don’t waste valuable luggage space on anything other than shorts and tank tops.
2. Moscone is pronounced just like it’s spelled:  Moss-Cone
3. If you want to blend in with the locals, refer to San Francisco as “Frisco”
4. The keynote starts at 10:00am on Monday.  Be sure to get there early, say 9:30am, so you can have plenty of time to grab your badge and get a good seat.
5. Take your computer and all your iDevices to the keynote and every session.  You never know what you might need.

* - Actually, do the opposite of all this.  For a real first-timers guide, go here.  For a list of WWDC after-parties/events, this app is great.

The gyroscope in the iPhone 4 and the new iPod Touch are great sensors for accurately detecting the device’s motion.  When combined with the accelerometer data, the Core Motion framework can return a measurement called ‘Attitude’ which is a set of numbers that describe how the device has moved from a frame of reference.  Attitude can be difficult to accurately explain in text, but completing this tutorial will give you an app that displays the Attitude measurements as the device moves making it easy to visualize and understand.

The first thing you need to do to get started with Core Motion is add the Core Motion framework into your project and include it in HelloWorldLayer.h

Next, we’ll add variables for both a label (which we’ll update with the Core Motion data points) and a reference to a CMMotionManager object.  The CMMotionManager is what allows us to access the motion data points. 

You initialize the CMMotionManager and the label in your HelloWorldLayer’s init method:

We set the deviceMotionUpdateInterval to our ideal refresh rate (60 Hz) since we’ll be pulling in motion data at every frame.  Then we check to make sure motion data is available (it won’t be on devices without a gyroscope) and we start the updates. 

We can now access the latest motion data in our update method by accessing the motionManager’s deviceMotion property.  There’s a lot of data encompassed in the CMDeviceMotion object we get back including rotation rate and the direction of gravity, but we’ll look at the Attitude property and it’s three measurements so we can see how the device has rotated along it’s three axes.  We’ll then rotate the the label with the yaw so that it’s always in the same orientation as the device is rotated around:

Since Cocos2D accepts rotation in degrees, we convert the yaw measurement using CC_RADIANS_TO_DEGREES.  Also, note that the CMAttitude is the change in device rotation from a frame of reference.  That frame of reference is the orientation of the device when we called [motionManager startDeviceMotionUpdates].  We can alter the frame of reference by multiplying the current attitude by the inverse of the attitude which we want to use as the frame of reference.  Let’s assume we want to change the frame of reference whenever the user touches the screen.  I will add [self registerWithTouchDispatcher]; to the HelloWorldLayer’s init method, and also add a referenceFrame CMAttitude variable to the header file.  Then we can add the code below to handle touches which will store a frame of reference:

To display the roll, pitch, and yaw according to the new reference frame, we add a couple lines of code to check for a referenceFrame and then multiply by it’s inverse:

Now, when you tap the screen, you will be effectively resetting the reference frame which moves the label back to it’s original position and changes roll, pitch, and yaw to zero.

The devil’s in the details.  I can’t think of many disciplines in which this statement is more true than in that of UI design where attention to subtle detail can mean the difference between an ok-looking design and a great one.  If you’re interested in learning how to create a good UI, or at least understand one, studying great designs is key.  And inspecting each carefully placed pixel to see how those designs were made can be challenging using only the naked eye.

I had my face pressed against my Mac’s screen for a long time before I found out that Apple actually gives you a great tool to allow you to do this for free.  If you have the developer tools installed, go to Finder and launch the Pixie app.

Pixie opens a window that zooms-in to the pixel level, the screen area around your cursor.  This can help you pick up those crucial subtleties.  I also like to look at the color values for the pixels (which can be turned on in the Preferences) to see exactly how a feature was created.  For example, in inspecting this number field, I can see that it’s made up of a linear gradient ranging from (240,240,240) down to (174,174,174). 

I can also see that the border of the field and the background have subtle gradients.

If you’re serious about inspecting an iOS app’s UI, I recommend using actual screenshots taken on your iPhone as opposed to using those on The App Store inside of iTunes.  When inspecting apps, I’ve noticed small artifacts on iTunes App Store screenshots that don’t appear on actual device screenshots that I take.

And if you’re on the hunt for some solid UI designs to inspect, here are a few of my favorite sites:

http://tappgala.com
http://tapfancy.com
http://wellplacedpixels.com

If know of any other great iOS design sites, leave a comment and let everyone know.

Game: “Would you like to share your high score on Facebook/Twitter?”
User: “OK”
Game: “Great. Just login here.”
User: “Oh…No Thanks.  See, I’m really lazy.  I don’t feel like typing in my username and password on this tiny little keyboard.  The iPhone’s auto-correct always messes up my username and I have chubby fingers so I never really know if I’m hitting the right keys for my password.  Additionally, I’m going to have to wait for you to log me in and then wait for the tweet to be sent afterwards.  On top of that, I’ve read all sorts of articles about 3rd party applications and information privacy, and I really don’t know if I trust you with my info.  Where’s the cancel button?”

I wish sharing iPhone app snippets on social networks was easier for users.  I suspect that the login wall stops many users from tweeting/posting what they would if things only took one tap.  Users shouldn’t have to enter their password into every single app just to tweet/post.  There should be an easier way, and right now there is… sort of:

You can currently tweet from your app using the Twitter for iPhone app via their custom URL scheme.  You simply detect if the user has the Twitter for iPhone app by seeing if it’s possible to open the URL “twitter://”:

And if you detect that the user does indeed have the Twitter app, you can tweet by executing a URL request to the tune of twitter://post?message=I%20Love%20This%20Game

This will open the Twitter iPhone app to the New Tweet screen with the text “I Love This Game” already filled in.  At first, that sounds great.  The user doesn’t have to login to Twitter and they can tweet their message with just two taps:  one in your app, and one in Twitter to post the tweet.  But there’s one problem.  I just kicked the user out of my app and into the Twitter app with no way to get back!  Here they were having a great time.  They just achieved something noteworthy that they wanted to tell their friends about, and now I’m making it harder for them to go back to the game.  Using this custom URL scheme, I’ve made it easier for the user to tweet, but kicking them out of the game probably isn’t worth it.  There should be a better way.  And there can be.  To make sharing easier for users and still viable for developers, I suggest an improvement to the URL schemes social networking apps use:

If social networking apps accepted callback URLs in their custom URL parameters, the social networking apps could then include a way to return to the original apps.  For example, Twitter would be launched by the following URL:

twitter://post?message=I%20Love%20This%20Game&callback=myapp%3a%2f%2flastscreen&appname=MyCoolApp

This would allow the Twitter app to display a button directing users back to “MyCoolApp” because “MyCoolApp” can be launched with the custom URL myapp://lastscreen.  There was a genius who did this long ago with an app called Duo which accepted callback URLs and an app name in the custom URL scheme allowing users to return to the original app by pressing a button which called the original app’s URL:



I’d wager to guess that the users of the official Twitter and Facebook iPhone apps far eclipse the users of Duo.  So it would be nice if the major players would implement something similar.  The method could even be greatly improved upon by automatically sending users back to the original app once the tweet has been sent.  Or even automatically sending the tweet upon launch and then automatically sending the user back, effectively only requiring one tap in order for the user to tweet/share from any app.  Furthermore, it doesn’t have to stop at tweeting.  It could extend to following a Twitter user and Liking a Facebook fan page.

This is much simpler for users.  As a developer it’s also a lot simpler for me to use these custom URL schemes than having to implement OAuth or a third party SDK.  And as a social network, you get more engagement.  Wouldn’t that be nice for everyone?

The embossed text effect is a subtle, but key detail in creating the ‘iPhone look’ for your app’s UI.  In fact, you will see this effect in every single one of Apple’s apps that ships with the iPhone.

If you’re not familiar with the term ‘embossed text’ open the Clock app and tap the Alarm button.  Notice how the word ‘Alarm’ appears to be embedded in the Navigation Bar so that if you could somehow reach inside the screen and run your finger over this word, your fingers would feel the outline of the letters.  If you have an alarm set, you can also see the same effect on the outline of the alarm time.  The effect is the same in each case, but the execution is different.  Where the effect on the word ‘Alarm’ is a dark shadow positioned slightly above the letters, the effect on the numbers is produced by a glare outline on the lower edges of the outline of each number.

This effect can be simple to achieve in Photoshop or your favorite image editor when designing your app UI.  But creating it in Interface Builder gives you several advantages:  flexibility to easily change this part of the app design without having to involve a designer, a smaller app package (in some cases), the ability for the code to change the text anytime during runtime, and you get the added benefit of high-res rendering on Retina displays without having to worry about @2x versions of textual images.

The effect is also easy to apply in Interface Builder.  Fire up IB and add a dark text label to a non-white background. 



Select the label and change the shadow to a white color.  Then change the V. Offset setting to positive 1.  This will position a white “shadow” one pixel below the text making it appear as though light is glaring off the lower edges of the text border and creating the illusion that the text is embedded into the background. 

You can take the illusion one step further by reducing the opacity of the text.  This will produce a subtle black shadow at the top of the characters due to the white “shadow” behind the text brightening the opaque letters everywhere except top 1 pixel.



And there you have it.  The effect can similarly be produced with white or light-colored letters.  To do this, instead of using a white shadow with a vertical offset of +1, you would use a black shadow with a vertical offset of -1.  Is this effect subtle?  Yes. Very.  But attention to a subtle detail like this is extremely important in crafting the perfect UI for your app.

When indie iPhone developer Ethan Nicholas made headlines with the $600K he made in one month selling his iShoot app, he cited the game’s lite version as his sole marketing effort.  Soon afterwards, free/lite versions became the de facto marketing technique for the indie dev to push their paid apps up the charts.  That was two years ago and the free/lite version promotion technique has been discussed again and again since then.  Is this technique still effective?  How many developers are successfully using it to push their apps up the charts?  I decided to look for answers in the Top 100.

First, how many of the Top 100 Paid iPhone apps do you think have an accompanying free/lite version?  Go ahead and render your guess…  The answer (as of March 2nd) is 47 out of 100, or less than half.  Clearly, creating a lite version of an app is still an effective technique, but it’s also certainly not the only path into the Top 100.

Games VS. Apps

I always like to analyze games separately as these make up a large portion of The App Store.  Is there a trend in games?  Do gamers need to try before they buy?  Or are other non-game app users more discerning in their purchases?  Turns out, there’s not a huge difference between games and other apps.  In The Top 100 Paid Apps there are 60 games and 32 of those have a free/lite version also available on The App Store.  Close to the same ratio as when including all apps.

Price

If I would expect any subset of the Top 100 to NEED to have a lite version it would be those with prices over $0.99 as these would have a tougher sell with more reluctant buyers who would need a free trial to justify the ‘high cost’.  I was surprised to find that only 9 out of 25 apps in the Top 100 priced at $1.99 or over have lite versions.

Well, what about eliminating the 8 apps that are $1.99?  That brings apps $2.99 and over ringing in at 6 out of 17 that include a free version, almost exactly the same percentage as when including the $1.99 price tier.

Even eliminating the 12 apps that are $2.99 and leaving only the 4 apps that are $3.99 or more leaves you with 1 out of 5 that have a free version.

Clearly, successful apps higher in price don’t necessarily need a lite version.

Indie VS. Big Guys

Last, I wanted to examine some stats on indie vs. established publishers, to see if indies mostly used the lite version driven model whereas big guys like Disney mostly threw their big names behind the titles and didn’t need to have free versions.  However, this type of labeling is very subjective with a lot of grey areas, so I decided against hard stats.  One observation I did make was that big-name publishers are certainly no stranger to the strategy with EA releasing a lite version of NBA Elite 11 and GameLoft releasing a free version of Oregon Trail.  In contrast, there were also indies that were able to climb the charts without resorting to a free version (see Tiny Wings).

Conclusion

So it appears a lot of successful developers both big and small are still using the lite-to-paid strategy.  And the biggest surprise here was that higher priced apps don’t necessarily need to incorporate a lite version to be successful.  Want analyze the data and come to your own conclusions?  The spreadsheet I used is available for download here.

I just got back from iPhoneDevCon yesterday.  I learned a lot, had a great time, and met a lot of interesting people.  If you’ve never been to an iOS Developer Conference, you really need to attend at least one.  Not a lot of indie devs have the big bucks to shell out for WWDC, but for a quarter of the price you can attend a number of other great events:

Upcoming

GDC Online - Oct. 5-8 - $595 for iPad/iPhone Summits, $1195 for all access - Austin - The Game Developers Conference with two all day summits devoted to iPhone and iPad gaming.

Voices That Matter - Oct. 16-17 -$695 - Philadelphia - A 2-day iOS event featuring speakers that have written iOS dev books.

DiscoveryBeat - Oct. 18 - $395 - San Francisco - Conference dedicated to app discovery with a major focus on mobile and The App Store.  Speakers include executives from companies that routinely top the charts:  Zynga, BackFlip Studios, and Tapulous/Disney.

SecondConf - Oct. 22-24 - $449 - Chicago - Taking the place of the now-defunct C4 is SecondConf, a single-track indie iOS and Mac dev conference.

360iDev - Nov. 7-10 - $599 - Austin - Four day conference devoted entirely to iOS.  I went to 360iDev San Jose earlier this year.  Lot’s of indie devs attend to see the great sessions and take part in the all night Game Jam.  Definitely worth the trip. 

CodeMash - Jan. 12-14 - $175? - Sandusky - 3-day developer conference on multiple technologies with a dedicated mobile track.  (See Chris Adamson’s comment to this post for more info…)

GDC 2011 - Feb. 28 - Mar. 3 - $595-$2100 depending on when you register and what you want to see - San Francisco - The main installment of GDC.

iPhoneDevCon - April 4-6 - Boston - These guys just put on their first conference last week and did a great job.  Looking forward to the next one.

Not Yet Scheduled

WWDC 2011 - June? - $2000? - San Francisco - Apple’s Official Conference

iOSDevCamp - The iOS Unconference

Tip:  Search Twitter and the speakers’ blogs and you can often find discounts on tickets.

If I’ve missed anyone, leave a comment and let me know.

In last week’s blog post, I examined The App Store Top 100 Grossing rankings over the course of one year, and found that the average purchase price of a Top 100 Grossing app had decreased.  This decrease was facilitated in part by the 11 Free apps that made it onto the Top 100 Grossing charts.  Today I’m looking at what In App purchase business models these apps are using to produce enough revenue to gain a highly sought-after spot on the charts.

Apple announced In App Purchase (IAP) for free apps in October of 2009.  Right away, there was a lot of talk about how IAP would be used.  Plenty of developers and media outlets discussed the elimination of Lite/Pro app versions which would be replaced by a single free ‘Plus’ app with a single IAP upgrade option.  Well, there is only one out of eleven Top 100 Grossing Free apps that is using this IAP upgrade model.  I don’t have any data to find out if this business model just doesn’t produce revenue, or if there aren’t many apps using the model…but it’s not showing up on the charts.

So what model are the rest of the Top Grossing Free apps using?  With the exception of the previously mentioned app using the upgrade model and one app using a subscription model, the remaining nine apps use the Freemium Pay-To-Play(-More)/Pay-To-Not-Wait model.  This is the FarmVille/WeRule model where you have to either wait for things to happen in the game or speed it up by purchasing their virtual currency.  Here they are listed along with their top three IAPs:



The biggest benefit to using this IAP model in an app is that there is no limit to the amount of revenue you can obtain from each user.  In This Week In Startups Episode #60, ngmoco CEO Neil Young claims that some users have spent over $10K on IAPs playing the company’s We Rule app.  No, that’s not a typo…$10K…on We Rule Mojo.

Additionally, it seems likely that users are more open to advertising in free apps even if they are the Pay-To-Play(-More) model.  This allows devs to open up another revenue stream with ads in these types of apps.

The biggest downside is that this model couldn’t work for every type of game or app.  Imagine a Twitter client that only let you tweet once a day unless you bought more Twit-bucks.  Probably wouldn’t be very popular.  However, I do think this model could be extended beyond the FarmVille-esque build a farm/kingdom/city games.

Are you considering this model for your next app?

—-

As a quick side-note, I’m heading out to iPhoneDevCon tomorrow.  See you there!