Want to Know How We Reached the #1 Spot for Kids Games in Portugal?

So do we.

Puzzle Fun Pack: Wild Animals! is apparently huge in Portugal. We have no idea exactly why (other than it offers wonderful gaming value, delight, and wildlife fun – transcending  borders to appeal to kids across the globe) but we’ll take it. Obrigado!

An App Developer’s Vision for iTunes Connect 2.0 – Part 2: Social Asks

An App Developer’s Vision for iTunes Connect 2.0 – Part 1: Let’s Start with Data

Over the past few years, the iTunes Store has grown into the Swiss Army knife of online entertainment. With the addition of the App Store, Apple has brought the ability to create, share, and sell software like never before. The iTunes store is obviously functional for it’s current purposes, but the supporting framework for app developers, iTunes Connect, has been under pressure to keep pace.

For those that don’t know, iTunes Connect allows developers to submit and manage their apps, as well as serving as the sole source of reporting for daily/weekly/monthly sales, financial reports, and more. The earliest target for criticism was approval timelines from the tool (which have seen obvious improvements), but that spoke more to the processes of the store vs. the tool itself. Any developer can tell you that the next stage of evolution for the iTunes Connect service is well overdue.

We’ve found with the current iTunes Connect system does an adequate job of suppling some of the information that we need, but in a less than elegant manner. Sales data is supplied in daily text files, no graphs, trending, or tracking over time. Reviews, ratings, and other touchpoints are only accessible through the store interface itself. Promo codes are created through a four step process ending in a text file and aren’t trackable.

So now that the iTunes App Store is obviously a hit, it’s time for Apple to get serious and create iTunes Connect 2.0. Every developer has their own wish list, but we’ll be tackling a few topics in the next few blog posts, starting with data in this post.

Developers have the opportunity to become more sophisticated in how they design, build, and market their apps. For Apple, the benefit lies in keeping developers happy, and increasing the size of the moat that they’ve created to keep the Android, Blackberry, and Windows app stores far behind them.

THE DATA ASK

Apple should create a system that can report in-store behavioral and attitudinal information to app developers, much like traditional web analytics reporting. Creating a system won’t be cheap, so let’s start with the short putt where the data is already being collected: ratings and sentiment. Tell us how our apps are doing with iTunes Store ratings and review reporting across all geographies. Let us know how our apps are reviewed vs. other apps in our category, and how the people giving us a good/bad review typically review other apps. Speaking of reviews, the biggest missing piece here isn’t just the data and reporting, it’s letting us contact unsatisfied customers for support or assistance. These our are customers – make it easy for us to digest and respond to feedback.

Now on to the fun asks: let’s get some behavioral data from the store. We’re talking visits, visitors, app page views, and time spent on our app pages for starters. More importantly, let’s get into the actionable data like traffic sources. When someone views our FunkBox Drum Machine app page, where did they come from? Was it an external link, a New Release list, a Top 100 list, a Genius recommendation, Tell-A-Friend functionality, or a new review site? What’s the purchase conversion once they land on the page (and how does it differ by referral source?) Give developers tools to slice the data by geography, demographic, and segment by types of apps they buy. Give us iTunes Store search data. How often are we appearing in results, and how often are people finding us through those searches? Are customers more likely to purchase that way? Are there valuable keywords that apply to our apps that we’re not listed under?

Now that the covers have been taken off the iPad, it’s also time for sales data based on device type. Give us all the above information, and the ability to see who is buying/installing on an iPhone, iPod Touch, or iPad (and overlap.)

Each of these data asks are trivial on their own, but combining the pieces of data together can help give us a better picture of our customers, and build better apps by using data. Instead of simply throwing an app into the iTunes ether and crossing their fingers, developers would have the tools to begin actively managing their apps as products. It’s silly that today we can tell more about our customers from high-level analytics on our Youtube videos vs the iTunes store.

In future posts, we’ll tackle the remaining asks we have of iTunes Connect, including social opportunities and tackling improvements to the store itself. There’s so much that can added to make the guts of the store a truly remarkable opportunity for developers. In the meantime, let us know what you’re looking for from iTunes Connect, and what we’re missing.

App Approval Times – What We’re Seeing

Online news reports and forums are filled to the gills with iPhone developers claiming to be seeing astronomical improvements on app approval times since the new year. The old days of no transparency and months of waiting are finally over, they proclaim.

So what are we seeing? Well, we’re seeing improvements, but nothing through the roof quite yet.

Our latest app, the FunkBox Drum Machine, was submitted to Apple about five days ago, and was just approved this afternoon. Our wait times were never that bad to begin with – we were seeing weeks, not months.

With this latest release, we’re definitely seeing an improvement, especially how fast the app gets placed “in review”, which took all of three hours. But we then waited for five days before getting released into the iTunes App Store. Other developers are reporting updates to apps being approved in a few hours, and brand new apps in twenty four hours. We sure didn’t see that.

Sure, we may have got caught up in some Apple employee getting us into their approval queue and then heading out for the three day weekend, so this may not be the best time to test out the store’s approval timeline improvements. We’ve got another app to submit in the next few weeks, we’ll hopefully get some twenty-four hour goodness on that one. The trend is definitely heading in the favor of iPhone developers, sounds like Apple is listening to the community and responding.

babyCalm iPhone in-App Analytics – 2 Week Update

We were very excited to launch babyCalm in the iTunes App Store two weeks ago. For those that aren’t familiar with babyCalm, it’s a pretty simple app that uses sound, visuals, and vibrations to help calm fussy babies.

WHY WE USE IN-APP ANALYTICS

With every app we build, we try to anticipate how our customers will interact with our apps, and how to best exceed their expectations. Unfortunately, with the current feedback systems in place (support email, iTunes Store reviews), we don’t always get a full picture of what’s going on with how people are really using the apps we build. So, to get a better picture, we’re using Pinch Media (who just merged with Flurry) analytics to track user behavior within the app and figure out what’s working, and what’s not. How are our apps performing? Do people like them? Are they using the apps like we thought they would?

START WITH GOALS

With any data analysis, you need to start with goals. If you don’t have a clear idea of questions you are trying to answer, you’ll never get that answer. So, what are the goals for babyCalm? Well, put in the simplest terms, we want people to:

1. Buy the app
2. Like the app and use it frequently
3. Tell friends

Most of what we can talk about today will be around subject #2, the sentiment and use of the app. There have been lots of conflicting reports we’ve read over the past year on how much people actually use the apps the download from the iTunes App Store. We like to think that people are happy with the apps they purchase from us, but how do we really know? A few sources can start to tell the story, including iTunes Store feedback (which is pretty non-existent so far for babyCalm), blogger reviews (babyCalm has had some coverage to date, but not a lot), and direct feedback to our support channel via email (which is also rare.) The best measure we have is usage. Generally, if people like an app, they’ll use it a lot and come back for more. So how are we doing in that respect?

DIVING INTO THE DATA

One good measure for engagement from our in-app analytics is Average Sessions per User. This is a daily breakdown of how many times, on average, our install base is opening and using the app on their iPhone.

We’re looking at around 2.5 average sessions per day, per user. That’s pretty good from our perspective – it’s about how many times I used the app with my son during testing, and it means that people are getting good use out of the application. It’s a win from our perspective – it means that the app has worked it’s way into their daily lives. But – are people continuing to use the app as time goes by, or are they using their “new shiny object” for a couple of days and then forgetting about babyCalm? A few things are going to impact that analysis. First – we’re still in the first two weeks of the app’s public lifetime, so it’s pretty early to make that call. Second, the purpose of the app is to calm infants, and as your infant grows up, well, you shouldn’t really need the app as much as you did the previous week or month. But, we can take a quick look at the Statistics by Lifecycle section of Pinch Media to get more insights.

This take a slice at the data based on how long each user has had the app installed. We’re seeing that the app receives more Average Sessions per User (Lifecycle) in the first week vs the second, but that users are still using the app at least once per day in the second week. Seems like our trend might be headed in a direction we don’t like. Let’s try another view.

Hmmm, using the measure of Time Spent per User (Lifecycle) view, we can see that users are actually using the app more in the second week than the first, just in longer single sessions vs. multiple shorter sessions. It’s possible that as people learn the app, they just keep it running vs. open multiple times. Either way, engagement is still extremely high for this app. To dive in, we’ll check Average Time Spent per Session.

The Average Time Spent per Session is quite impressive so far, and much higher than anticipated. People are using the app for upwards of an hour ON AVERAGE some days. The design of the app to date has been for quicker-fix baby calming vs. a white noise machine, but the takeaway here is that we’ll probably want to follow our user’s lead and add some of this functionality that could be used for longer durations, like white noise selections and maybe an Airplane Mode toggle to silence the phone for longer periods of time.

ACTION ANALYSIS

So – we know that we’ve got some great looking session and time spent numbers in our babyCalm app so far. But – what are people actually doing while they are in the app? Our in-app analytics can help us there as well.

The main differentiator for this app is the vibration functionality. With lots of apps in the store that can play sounds, we thought adding vibration would be a great addition to the feature set. So what do the numbers tell us? Diving into the data, it seems like lots of people are using the sound AND vibration functions of the app, while a few are using the visuals. And LOTS of people are customizing the UI, so that’s a feature that seems to be resonating with our users.

So overall, looks like the app has been a success with the people who are using it. We’ve got a few takeaways on what we can refine and add to the app to add to the list we’ve already got going. Getting a view into user behavior is always interesting, very often humbling, but can help give you an advantage in whatever you’re trying to achieve. Even calming fussy babies.

Two more apps from Synthetic Bits…

We haven’t been updating this blog lately, but we are still hard at work cranking out new apps. Our latest two to hit the iTunes Store are Christmas Advent Games, a Christmas themed advent calendar puzzle game, and babyCalm, a healthcare and fitness utility app to help you calm down a crying baby.

Christmas Advent Games made the iTunes Top 75 Kids Games list in the US for over a week, and peaked in the Top 50 in the UK. babyCalm was just released yesterday and is the first app we’ve made that isn’t a game or entertainment related, so we’re interested to see how it does.

These will be our last two apps that get released in 2009, so it’s probably a good time for us to thank everyone who has helped us out with their support and encouragement. Thank you so much!

That makes five Synthetic Bits apps out there in less than six months, and there are more on the way. We’ve even made it through our first major iTunes store re-design, as you can see by comparing the image clips of our new apps in the store above compared to the ones we posted in previous entries. Now we’re using all the experience we’ve gained from developing these first few simpler apps to get ready to start designing and working on some new and even more exciting things. The next two apps are already in development with some interesting new twists, and bigger projects await in the new year.

Thanks again for your support and happy holidays!

App number three accepted and in the store.

Our third app, Underwater Ocean Puzzles, was accepted and is now for sale in the App store. This one is just a variation on our Spooky Halloween Puzzle app, so it’s really only app number two and a half, but it’s our first non-holiday app and our first one geared towards kids. It also includes some electronic music from my band Submodern’s last album, which is something I hope to keep doing in the future.

Apple approved it in exactly 14 days, so they get to count it for their “14 days or less” success rate. So far we’ve had everything approved within two weeks and no rejections, knock on wood, so our experiences with the approval process have overall been very positive.

Submitted: October 2
Tested by Apple: October 13
Accepted: October 16

Making an iPhone app 2.2.1 compatible

One of the things we added to the 1.1 version of Spooky Puzzle (still in review with Apple) was compatibility with iPhone OS 2.2.1. Really we should say iPod touch OS 2.2.1, because those devices are usually the ones that people don’t upgrade, because it costs them money to do so. Anyway, we’ve read widely varying accounts of how many people update to the latest OS, and how fast, but we wanted to give it a shot to at least learn how it’s done and to try to make our apps as compatible as possible.

As it turned out, for Spooky Puzzle it was pretty easy to make it compatible, once we figured out how to do it. That last part, of course, is almost always the catch. Maybe we can save you some time by telling you what we figured out.

Note that there are a number of ways you can do it, some more elegant than this one. This is how we did it, quick and cheap and easy. Want elegant, extendable, pretty? Keep Googling.

The first thing you we did was kept our Base SDK as we normally would, to the latest version:

This allows us to keep using all the latest and greatest OS3.0+ methods and properties in our code, without #ifdef’ing them out. Of course, a 2.2.1 phone/touch won’t have any idea what these calls are, so if they come across one of them they will flail and crash. But we’ll get to that later.

The next thing we did was set the deployment target to the earliest version we wanted to support:

In this case, we’re saying anyone with 2.2.1 can run this binary, even though it uses the 3.0 SDK as a base. Which is exactly what we want to happen.

So now that we set that up, you can see that Xcode will allow us to run our app using a 2.2.1 Device or the 2.2.1 Simulator:

Sweet! We’re done! Just compile and run and… ah crap, it crashed.

So the final step is to figure out what doesn’t work with 2.2.1, and handle those specific cases differently as needed. For example, in Spooky Puzzle we found out that modal transition styles got an upgrade with 3.0, and the ones we were using weren’t supported in older OS versions. So, in our code we check the version of the device, and only set the transition style if we are running 3.0 or greater:

Running 2.2.1? Sorry, you get the old, lame, default style. Bummer for you, but at least the app runs.

Now, how did we know what bits needed to be changed and worked around? Well, that’s the tricky part. A good first step is to look through the 3.0 release notes to see what Apple added and changed. Or, alternately, you can just say screw it and run the thing and see what happens. Yes, we did this first, and so will you. Anyway, this works… as long as you test everything thoroughly and perfectly, which is of course impossible. There’s also the problem that things might mostly work, but they might not work exactly like you want or expect them to work. For example, I noticed a difference in the way ViewWillAppear was being called between 2.2.1 and 3.0, and had to tweak my code so that the things that were set there were being set properly in either version. So you actually do need to jump in and test everything yourself, both in the simulator and on a 2.2.1 device. You can’t assume it will work right just because it “should”.

So, making an app backwards compatible is stupidly easy right? Well, this one wasn’t bad, once we tried a few different approaches and found one that worked. Our other app though, the Halloween Costume Generator, would have been a much bigger task. It uses table views, and there are some differences in the way you set cell fields between 2.2.1 and 3.0 that would have required me to change most of that code. The Costume app also uses the Apple Reachability code to test for an internet connection, and that didn’t want to work properly either, which is tricker because now we’re talking about modifying other peoples code, which can always give you unexpected results. Finally, the Costume app allows you to send emails with the costume info, and that again was very different in 3.0 vs 2.2.1. So we ended up not making this app 2.2.1 compatible, since it has a limited shelf life up to Halloween, and if by next year anyone is still running 2.2.1… well, let’s hope they’re not…

Now, the important question: will it make any difference in sales in the end? Given how long 3.0 has been out, and the already low sales of Spooky Puzzle, we kind of doubt it. But, at least we figured out how to handle these cases for when Apple comes out with 4.0, 5.0, 6.0. Also, it is nice to avoid the 1 star reviews from people who somehow download a 3.0+ app to their 2.2.1 device, and then get mad at you because it doesn’t work. Every little bit helps!

Our first two apps were accepted!

Break out the cham-pan-yah, our first app was just accepted into the iTunes Store. It hasn’t shown up in the store itself yet, but should be appearing there shortly. Update: it showed up in the store four hours later.

Halloween Costume Generator
Development started: July 25
Submitted: September 5
Tested by Apple: September 13
Accepted, “Ready For Sale”: September 17, 8:00PM EST
Available in iTunes: September 18, 12:03AM EST

Update: Our second app was also just accepted!

Spooky Halloween Puzzle
Development started: July 16
Submitted: September 6
Tested by Apple: September 14-15
Accepted, “Ready For Sale”: September 17, 10:00PM EST
Available in iTunes: September 18, 2:15PM EST

OHAI

You build. You submit. You watch, you wait. You hope. You wonder. And then suddenly – you see something. You see what we like the call “the data spike of hope.”

It’s a beautiful sprout of in-app analytics. It’s the elusive New User that we’ve been waiting 10 days for on our first submitted app, the Halloween Costume Generator. It’s directly in line with what we’re hearing in the forums – 14 day average, but Apple reviewers tend to access to app 4-5 days before they send an approval/rejection note. What we know is that they used an Apple 3GS to test the app, that it didn’t crash (thankyouverymuch), and that they used it for just under 2 minutes.

But would our second app, submitted 24 hours after the first, follow the same trend? Are the iTunes store reviewers keeping pace?

BAM. The second shoot appears, this time for the Spooky Halloween Puzzle. You saw that one coming, didn’t you? This time they used an iPhone 3G, similar time of use (just under 2 minutes), and no crashes.

So now the big questions remain:

1) When will we get final word?
2) What will the final word be?

Stay tuned. But it’s nice to know that Apple has at least gotten around to kicking the tires. We can see some progress, which helps. Hopefully exciting news to come.