iPhone Video Output

There are a couple of options available when preparing to perform a demonstration of an iPhone app to a larger group of people. All these options have flaws, however. The "gather around" method, for example, doesn't work well for groups of more than a few people. Any more and you would ideally want to project the iPhone screen contents onto a big screen.


The "iPhone simulator method" is probably the most used method. It's simple to set up but limits your app navigation to the mouse, making multitouch gestures difficult to perform. Also, there is no way to show off accelerometer functionality like "shake to undo".
The "camcorder method" avoids the simulator's issues, but can be a hassle to set up. It also restricts your movement as you have to make sure to keep the device on screen and avoid reflections as best you can.

Doing it Steve's way
Why don't we take a page out of Steve Job's playbook and mirror the iPhone screen directly from the device onto the big screen?
Sadly this is not straight forward. So far only the iPod application supports video output via Apple's AV cable, at least that's what I thought until I stumbled upon Rob Terrell's iPhone App Video Mirroring blog post (go read it now, I'll wait).

Using the private MPTVOutWindow class in the MediaPlayer.framework API, Rob's code mirrors the iPhone screen onto the AV cable. For demonstration purposes this is a great solution, but being based on a private API it should not be left in the app when submitting it to the App Store.

Originally the code did not support on-the-fly orientation changes and touch indicators, both of which I needed. Thanks to Rob posting the source code I was able to implement these changes and have since submitted the updated code back to him, although I haven't heard back after doing so.

Get your hands on the code
In the spirit of sharing I have prepared a sample project, TvOutputSample, which shows you how to add video output to an Xcode project. This is the application shown in the video above, it should build and run out of the box, using iPhone SDK 3.0.

Download the code: TvOutSample.zip
[UPDATE: The project has moved to github]

I should mention that since the video mirroring is software based it affects application performance somewhat. On an original iPhone 10 fps works well, on an iPhone 3GS I have had no problems running at 20 fps. The fps setting is near the top of the UIApplication_TVOut.m file, do your own tests to see what works best for your app and hardware.

The current version (as of October 2009) of the code does not support OpenGL video output.

 

How Apple can improve iPhone scrolling

I want to mention a UI issue I have with the iPhone OS implementation of scroll indicators, the unobtrusive bars that appear on the right side of the screen when scrolling through a list.

My hand obscures the scroll indicator

Like most people, I tend to use my right hand to interact with the iPhone. This means that my hand obscures a large part of the extreme right of the display, making it hard to see how far down the list I have travelled.

Proposed UI enhancement

My proposal is to have the scroll indicators appear on both sides of the screen.

The effect is illustrated in the photoshopped screenshot below, based on the settings screen in my Hiragana application.

Note how the scroll indicator appears on both the left and right sides

Note how the scroll indicator appears on both the left and right sides

Is this really a problem?

This issue tends to bother me the most while reading longer articles at RoughlyDrafted Magazine or Daring Fireball. I often want to quickly check how far I have to go, in order to decide if I have time to finish the article or if I should save it for later.

In these cases the scroll indicator tends to be pretty small and a fair distance down the screen, right where I am least likely to easily see it.

What about panning?

Mobile Safari, and other applications that allow you to pan around a larger view in two dimensions use a horizontal scroll indicator in the lower part of the screen. This can can also be partly obscured by your hand, and should thus be supplemented by a scroll indicator across the top of the screen.

Speculation on the scroll indicator's background

I suppose Apple's decision to limit the scroll indicators to the right and bottom of the screen is based on how scrolling works in the classic desktop applications where scroll bars remain on screen whether in use or not.

To minimize wasted screen real estate and avoid UI clutter, it makes sense in a desktop application to chose a single place to present the scroll bar. The standard seems to always have been to place it on the right, and along the bottom for horizontal scrolling.

However on the iPhone scrolling works differently. There is no screen real estate wasted by showing the indicators on both sides since they are only visible while you are scrolling.

The appeal

So Apple, please add support for dual scroll indicators. It just makes sense.

Hiragana, Katakana and the WWDC Wall of Apps

At WWDC there was a really cool wall of apps, which used 20 Apple Cinema Displays to show the icons of the 20,000 most popular iPhone apps, and illuminate them whenever they were downloaded from the App Store. Pretty neat!

Greg Pascale, a student at Brown University, made a Photosynth of the whole wall, allowing us to study it in detail. I took the opportunity to look for my applications, and found them at the far right of the wall.

I can hereby claim having had a presence at WWDC '09. Sweet!

10 000 App Store Downloads

As of the latest available weekly sales report on iTunes Connect, the number of downloads for my three iPhone applications have passed 10 000!

The apps are Hiragana Lite (free), Hiragana ($2.99) and Katakana ($2.99).

I am amazed at the success of these admittedly simple applications and would like to extend my sincerest thanks to my customers, especially those who have left feedback and pushed me to improve the apps.

The numbers

(click to view large version)

(click to view large version)

The vast majority of downloads have naturally been for the free version Hiragana Lite. However with just under 10% of the total downloads, the paid apps have together been able to edge over the 1 000 downloads line. This is way beyond my wildest hopes.

The explosion of Hiragana Lite downloads makes the sales lines for the paid applications look almost flat. But if we disregard the Hiragana Lite downloads and look closer at the sales of the paid apps, combining their numbers, we notice something interesting.

Don't let the changed scale on the y-axis in the following graph confuse you, it goes to 1000 instead of the 9000 shown in the graph above.

Before the release of the free version the sales trend had been declining after the first few weeks. It looks like it was about to go flat right around 500 sales. However since Hiragana Lite has been available sales have picked up and have held remarkably steady.

My conclusion to this is that it is a very good idea to make a free version of your app available, letting potential customers try before they buy.

A second conclusion is that I should probably set aside some time to develop a few more apps.

---

*Note that these numbers do not include updates, only new customer downloads are counted.

Using Mono for .NET development on the Mac

Yesterday I decided to install Mono onto my MacBook to enable .NET development. Below I have listed the steps I took to accomplish compiling and running a Windows Forms hello world style application and packing it into an app bundle so I can run it by double clicking the icon.

The reasons for doing this are twofold;

* I spend most of my time at work professionally developing .NET applications using Visual Studio, so obviously I'm interested in using .NET also on the Mac.

* I'm thinking of writing an experimental Push Notification Service backend in .NET and would rather avoid having to launch Windows to do this.

Requirements

Leopard (Supposedly works on Tiger as well, but then you need to install X11 to make Windows Forms applications work)

Installation

1. Get Mono for Mac from the Mono Project website. I grabbed version 2.4, the latest stable version as of this article's publication.

2. Run the installer. Mono installs under '/Library/Frameworks/Mono.framework'.

Hello World on the command line

3. Compile a command line hello world tool:

hello.cs file contents

// Compile with %> gmcs hello.cs
using System;
public class HelloWorld
{
static public void Main ()
{
Console.WriteLine ("Hello Mono World");
}
}

Compile using the 'gmcs hello.cs' terminal command.

4. Run using the 'mono hello.exe' terminal command. The 'Hello Mono World' message should be printed.

Windows Forms Hello World

5. Compile a Windows Forms hello world app tool.

helloforms.cs file contents

// Compile with %> gmcs helloforms.cs /r:System.Windows.Forms.dll
using System;
using System.Windows.Forms;
public class HelloWorld : Form
{
static public void Main ()
{
MessageBox.Show("Hello Mono World");
}
}

Compile using 'gmcs helloforms.cs /r:System.Windows.Forms.dll'.

6. Run using the 'mono helloforms.exe' terminal command, and if all is well a message box should be displayed.

Creating an app bundle

7. Use MacPack to package the .NET assembly into an app bundle, which can be launched from the Finder.

'macpack -n:HelloForms -a:helloforms.exe -o:. -m:winforms' on the command line.

8. Launch the app bundle HelloForms.app from the Finder to make sure it works.

That's it really. You are now ready to start development on your enterprise level .NET project using Mono on your Mac.

Additional tips

* MacPack has a really good man page documenting its use.

http://linux.die.net/man/1/macpack, or just 'man macpack' on the command line.

* Simplified compilation using pkg-config

Note that using pkg-config (see if it's setup on your system by running 'pkgconfig' on the command line) you can compile the forms app using 'gmcs helloforms.cs -pkg:dotnet' instead. Not a big difference in this example, but not having to list all needed assemblies will help when compiling more complex projects.

For .NET 3.5 compatibility, you would use the -pkg:dotnet35.

To set it up, add the following line to the '~/.bash_profile' file, if the file does not exist create it:

export PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Versions/Current/lib/pkgconfig/

References

Windows.Forms and Mac OS/X
http://oepapel.blogspot.com/2005/04/windowsforms-and-mac-osx.html

Mono Basics
http://mono-project.com/Mono_Basics

Customizing Terminal when Compiling Mono apps
http://dotmac.rationalmind.net/2008/12/customizing-terminal-when-compiling-mono-apps/

Archive for the 'firefox' Category
(contains info about pkg-config)
http://wp.colliertech.org/cj/?cat=9

iPhone SDK development on multiple computers

Sometimes it's good to be able to use several computers to develop your iPhone app. In my case my main development machine is the iMac, but summer is coming up and I may not want to stop developing just because I go out of town. Luckily I have a MacBook, on which I have also installed the iPhone SDK.

In order to test on the device when I develop using the MacBook I have to move my certificate, private key and provisioning profile to it. Here's how I do that.

1. Launch Keychain Access on the iMac (main development computer).

2. Under the Keys category I Ctrl-click the private key that has the certificate for 'iPhone Developer: ' attached to it.

3. In the context menu select 'Export ...'.

4. When saving provide a password, which will be required for importing on the other computer.

5. A .p12 file was saved, transfer it to the target computer.

6. Grab the development provisioning profile (either by downloading from the iPhone Program Portal or by grabbing the right one from ~/Library/MobileDevice/Provisioning Profiles/) and transfer it to the target computer.

7. Double click the .p12 file on the target computer. If you provide the correct password the key and certificate will be installed into the Keychain on the target computer.

8. Drag the provisioning profile onto the Xcode dock icon.

The application can now be installed on the device from the target computer, which in my case is the lovely black MacBook.

Not announcing the Kinetic Battery Charger app

I had hoped to announce the release of my latest iPhone application on the App Store, sadly that's not happening here.

Lately I've been experimenting with the built in accelerator and wanted to put the code to use in an actual app, so I decided to make an app which simulates charging the phone battery when you shake it. Like you would shake your kinetic wristwatch to keep it running.

I designed a battery graphic and added a bar that grows when the phone is shaken to simulate charging. I thought it turned out really well, and the people I've shown it to have said it's hilarious even though they weren't fooled for long.

I submitted the application as a freebie to the Entertainment category on the App Store, but it turns out Apple's reviewer didn't find it entertaining. Instead I received a letter stating that it wouldn't be allowed on the store.

Unfortunately, your application, Kinetic Battery Charger, cannot be added to the App Store because it uses standard iPhone screen images in a non-standard way, potentially resulting in user confusion. Changing the behavior of standard iPhone graphics, actions, and images, or simulating failures of those graphics, actions, or images is a violation of the iPhone Developer Program agreement which requires applications to abide by the Human Interface Guidelines.

Now this is obviously a form letter as I am not using any standard iPhone screen images at all, except for the info-button which works as expected by revealing a settings screen. I sent a reply stating this fact but have not heard back.

I also spent a few hours poring over the Human Interface Guidelines in search for anything explaining why my application would not be acceptable but came up empty handed.

I find it a little frustrating that the feedback you get from the App Store reviewers doesn't contain any actual information about what they are objecting to. How hard can it be to take a screenshot of the application and draw a circle to point out the offending piece?

Oh well, back to updating the apps I already have on the store, that will hopefully be time better spent.

CodeSign error: a valid provisioning profile is required for product type 'Application' in SDK 'Device - iPhone OS 2.0'

Lately I've been working on adding some improvements to my Hiragana iPhone application, which I expect to submit to the App Store any day now.

This post, however, is not about amazing new features. Instead it's about a problem I ran into when compiling for Ad Hoc Distribution. Instead of the expected Succeeded message Xcode gave me the error message CodeSign error: a valid provisioning profile is required for product type 'Application' in SDK 'Device - iPhone OS 2.0'.

None of the classic tricks of restarting Xcode and cleaning the build had any effect. After banging my head against the screen for a while (that iMac screen is surprisingly sturdy) I was finally able to figure out that my project file wasn't set up to use the provisioning file I had installed on the system.
 
Since last compiling the application I have added a few new devices to my Ad Hoc provisioning profile. This appears to have surprised Xcode somewhat since it did not update the project file with the new provisioning identifier.


Here are the steps that worked for me, perhaps they'll come in handy for someone else as well:

1. Go to ~/Library/MobileDevices/Provisioning Profiles and open your Ad Hoc provisioning file in a texteditor, I used Smultron.
2. Find the section that looks like this
<key>UUID</key>
<string>xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</string>
3. Copy the identifier string.
4. Go to you project directory and make a backup copy of your MyProject.xcodeproj file.
5. In the Finder right click and select Show Package Contents on your MyProject.xcodeproj file.
6. Open the project.pbxproj file with your text editor. 
7. Find all rows containing "PROVISIONING_PROFILE[sdk=iphoneos*]" = "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"; that appear in an Ad Hoc section.
8. Replace the assigned value with the provisioning file's identifier, which you copied earlier.
9. Save and launch Xcode to try to build.

This worked for me. I hope it works for you if you run into the same problem. 


Analyzing App Store sales for 2008

Way back in October I wrote a post analyzing the sales data from the first three weeks of my applications in the App Store. Things were looking good, with over 250 sales in those three weeks.

Now that we're a little bit into 2009, it's time to take a look at how the sales performance evolved over the rest of 2008. Interestingly the combined sales of the 13 weeks since my previous report have failed to even equal those of the three initial weeks.

Click the images for higher resolution.

Sales Growth

All in all my two apps, Hiragana and Katakana, racked up a total of 467 sales during 2008. As can be seen the sales have leveled off to just a few per week, it will be interesting to see if the release of the free Hiragana Lite has any effect going forward.

Biggest Markets

Like before just under half the sales were generated through the US App Store, with Germany coming in second.

Payout

So far the sales have generated the following payouts:

$ 609

€ 207

¥ 5690

It seems Apple don't strictly follow the $250 minimum revenue per region rule before paying out. The Japanese amount above is way less than $250, and the dollar amount actually includes three separate payouts of $430, $91 and $88 respectively.

Announcing Hiragana Lite

I have decided to make a free version of my japanese study aid application, Hiragana available on the iPhone App Store.

This free version is exactly like the paid version except for 3 small differences:

  1. It's called Hiragana Lite.
  2. It contains the 46 basic hiragana characters, as opposed to the full set of 104 hiragana caracters available in the full version.
  3. Buttons on the info screen which open the App Store using the technique described in my earlier post Launching the App Store from within your iPhone application.

I'd be very happy if you gave it a try and leave me your feedback.

Hiragana Lite (App Store link).

I have also decided to mark the occasion by lowering the prices for the full versions of Hiragana and Katakana to $2.99.

Phil Schiller and the case with the missing menu bar [Updated]

I just watched the video stream of Phil Schiller giving the Macworld keynote presentation.  I am as usual hugely impressed with the software Apple churns out, this time the addition of face detection and recognition to iPhoto was my personal favorite new feature. Look out Phil, $79 is coming your way.

The one thing, though, that stuck in my mind more than anything about the presentation was the mysteriously missing Mac menu bar in the demo of the new iWork.com service.

First Phil prepared a document for sharing using Pages on his computer.

Phil with the menu bar

Phil with the menu bar

He then switched to the fictional user Tia's computer to show us what she would experience on the receiving end. Tia's computer however didn't have the Mac menu bar at the top of the screen.

Look, no menu bar

Look, no menu bar

I have had a slight look around to figure out how to hide the menu bar in Leopard, but to no avail. This begs the question, can it be done or was Phil not using Leopard in the demo?

By the way, good news about all iTunes songs being DRM free! Finally I can commence my long planned iTunes shopping spree.

UPDATE: The iWork.com demo starts at 1.01.20 into the video stream.

Launching the App Store from within your iPhone application

Today I decided to figure out how to launch the App Store application from within an iPhone application using the SDK.

It turns out this is pretty simple, but you have to beware of a few issues.
  • First and foremost, it doesn't work from the iPhone Simulator, in all probability since the App Store application is not available on the simulator.
  • Second you need to provide a valid URL to an application in the App Store. You can access the URL to an application by simply right clicking the Application in iTunes and selecting the "Copy iTunes Store URL" menu item.

Here is the core code needed.

[[UIApplication sharedApplication]
 openURL:[NSURL
  URLWithString:@"http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=291170459&mt=8"]];

The above URL points to my Hiragana application.

I then chose to store the App Store URL in the info.plist file under a key named TEBAppStoreLink, so that I can use the same code for any future applications.

I ended up with this method for launching the App Store with the URL in the info.plist file.

- (void)goToAppStore
{
  UIApplication *app = [UIApplication sharedApplication];

  // Get the url from info.plist.
  NSString *appStoreLink = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"TEBAppStoreLink"];

  // Open the url if it was available.
  if(appStoreLink){
  [app openURL:[NSURL URLWithString:appStoreLink]];
  }
}


What really happens is that Mobile Safari is launched with the provided URL, and upon realizing that the link is an App Store link it in turn launches the App Store application.

Of course, if you provide any other URL it just opens in Safari as usual. I haven't tested what happens if a YouTube URL is used, but I imagine the YouTube app would launch. That, however,  is not the problem i set out to solve today.

A few thoughts about the Cocoa Bootcamp

This fall I attended Aaron Hillegass' Cocoa Bootcamp at Big Nerd Ranch. I had planned to write up my thoughts about the experience earlier, but life (and work) interrupted.

After being confirmed for the class I made travel arrangements to arrive in Atlanta one day early to adjust to the time difference, and also to get a chance to see a little of Atlanta itself. I ended up having time to both visit the Apple Store at Lenox Square Mall and visiting the Georgia Dome for a taste of the NFL (the Broncos visiting the Falcons). I'm really happy I made the decision to fly in early, as I had a very good time in town.

NFL action

NFL action

On Sunday I ventured back to the airport via the subway to be picked up by the Big Nerd Ranch shuttle. While waiting at the baggage claim area I met a few other attendees and then the shuttle came by to pick us all up for transport to The Historic Banning Mills, where dinner was waiting for us. We were provided with a nice room each, overlooking a beautiful valley.

The Historic Banning Mills

The Historic Banning Mills

Spectacular views all around

Spectacular views all around

The next morning the Bootcamp got going, and within minutes Aaron had us coding our first app. The class followed Aaron's book Cocoa Programming for Mac OS X, with Aaron explaining some concept from each chapter and then having us using the learned concepts in code. There were also a couple of things covered which aren't in the book, for example an iPhone project. The frequent coding assignments and the opportunity to raise any questions with Aaron or any of the other students was a very efficient way of learning.

The pace in the classroom was intense, but every afternoon also provided the chance for a brief walk around the beautiful scenery, with Aaron himself as guide. This was a good opportunity to catch your breath, think about what you had just learned in a broader perspective, and to take a few photos.

Aaron goes for a walk

Aaron goes for a walk

Every day we were provided with no less than three huge and delicious meals, I think I ate more good food during the Cocoa Bootcamp than I will during Christmas, which says a lot. There were also snacks and soft drinks provided in the classroom, so no risk of going without energy. A good thing, since it did take quite a bit of energy keeping up with the learning tempo.

I think it would probably have been possible to learn pretty much what the class teaches by yourself by spending a couple of weeks or months with the book. I tried to go down that route this summer, but kept getting side tracked. Nevertheless I must reiterate - the book is a must buy for any newcomer to the platform. 

I'm really glad I took the class since it propelled me right past the first plateau in the learning curve and I now feel comfortable using Xcode and the Interface Builder. The opportunity to ask questions and have Aaron and others help debugging problems encountered during the assignments totally eliminated the frustrations encountered when trying to learn from reading a book on your own. The distraction free surroundings also helped me focus my mind on the task at hand.

I would say the Cocoa Bootcamp is probably the perfect way to get started with Cocoa development for the Mac. I'm happy, though, that I asked my employer to cover the costs when negotiating my contract for employment, as it is not exactly cheap. Nevertheless, if you can afford it I think that the Cocoa Bootcamp provides good value for the money spent.

A further advantage was that I got to meet a great, and diverse, group of people dedicated to software development and the Mac platform. The attendants were from all over the US, even some local to the area, as well as a couple of us Europeans.

If you attend the Cocoa Bootcamp, you'll leave having the confidence and understanding necessary to take on true Cocoa development projects. Let's hope something like that comes my way eventually, even though my day job is currently strictly .NET.

I'll make good use of my newfound knowledge in my spare time either way. Stay tuned...

En route to Atlanta for the Cocoa Bootcamp

I'm just now at the airport, waiting to board the plane which will take me to Atlanta and the Cocoa Bootcamp. This is a trip I've been looking forward to for over a year.

I have prepared for the course by reading most of Aaron Hilegass' book Cocoa Programming for Mac OS X, and of course by meddling with iPhone development. But I have always found it easier to learn by interacting with knowledgeable people, so this will be my big chance to really get to grips with the parts of the Cocoa framework which I haven't been able to grasp. 

The Interface Builder has been my biggest stumbling block so far, leading to me writing all interfaces in my iPhone applications in code. So I hope to come away from this week with new insights into how it's supposed to be used. Interface Builder is a very different beast compared to the .NET Visual Studio experience I'm used to. However, I fully expect it to be superior once I can wrap my mind around it. It is an Apple product after all.

Judging by his book, Aaron has a knack for systematically introducing progressively more complex concepts in a very clear and easy to follow manner. I thoroughly recommend his book to anyone new to Objective-C and Cocoa. I think I may be able to finish it during the flight.

I'll summarize my experience at the Big Nerd Ranch in an upcoming post.

Japanese navy flag and the App Store reviewer backlash, an apology

As you may remember from my previous post Analyzing App Store sales data, the vast majority of sales I've seen for my iPhone applications have been in the US market. 

My applications have been available for well over a month now and I had been wondering why I barely saw any reviews in the store. As it turns out, reviews are not combined worldwide but instead tied to the store the reviewer is in. This makes sense I suppose, avoiding any language problems. Sadly there is no way for a developer, as far as I can see, to get a summary of the reviews left worldwide. Instead you have to go into each and every store to see if any reviews have been written for the specific markets.

I just realized this fact the other day when I switched over to the US iTunes store to see what movies are available for rental there. I then did a search for my app Hiragana and noticed that all of a sudden there were a couple of reviews that I hadn't seen before. Almost none of them positive!

My applications are marketed towards students of the Japanese language, and apparently people were taking offense with the Japanese navy flag that I was using both for my icon graphics and as a background image for the flash cards in my applications.

Version 1.0 look

Version 1.0 look

Some review excerpts:

"I don't know if you know what it means but it is like using Nazi flag for learning German application icon."
"Are you even aware of the gross political incorrectness of that imperial military flag you're using as an icon and background? People don't even dare fly that thing in Japan anymore."

Read more reviews here (App Store link, make sure you are in the US iTunes store)

The second review above hits it on the spot. I was not at all aware that the flag I was using is considered politically incorrect. In my eyes it is a very neat design, I even bought a jacket featuring it as a design element when visiting China last year. I guess now I know not to bring that jacket when going across the Atlantic to Aaron Hillegass' Cocoa Bootcamp at the Big Nerd Ranch this winter (more about this in a later blog post). 

I did know the flag was/is used by the Japanese navy and i know that the Japanese committed a bunch load of horrible war crimes during WWII, but it never crossed my mind that people may equate it to the nazi flag. Is this really true? Wouldn't the App Store staff have considered this before clearing the applications for release? Feel free to leave your thoughts in the comments section, I would really appreciate it.

Measures taken

Of course I could not let the current state stand, so here are the measures I have taken to try to rectify the situation.

  • Redesigned icon
  • Removed card background
  • Half price during the full month of November!

Also I would like to express my apologies here to everyone offended by my using that flag in my applications.

Shameless plug

Introducing version 1.1 of my Hiragana and Katakana apps.

Now containing:

  • 100% less Japanese navy flags
  • Refined transition animations
  • Other minor fixes
Version 1.1 look

Version 1.1 look

These have already been available for a couple of days, and a few more positive reviews have trickled in. If you own the previous versions i recommend getting them updated via the App Store, unless you really want to hang on to that navy flag of course.

If you have avoided purchasing these applications for any reason, now is your chance to get them at a discount; $1.99 as opposed to the regular price of $3.99. Get them at the App Store.

Oh, and don't forget to leave a review in the store if you feel like it. Thanks!

Analyzing App Store sales data

I am currently selling two applications on the iTunes App Store. Hiragana and Katakana are educational applications aimed at the novice students of the Japanese language. Hiragana and Katakana are also the names of the two Japanese character alphabets my applications focus on.

Apple provides sales data for applications sold via the App Store, but the data is presented in the most unintuitive way possible, as plain data tables. This makes it extremely hard to get a view of sales performance, so I dropped the data files for my first three weeks of sales into my favorite data analysis application and ended up with the following insights. Click the images for higher resolution.

Sales Growth

Hiragana was first available for download from the App Store on 20th of September, with Katakana following on the 27th. In less than three weeks 266 units have been sold with Hiragana representing the majority of sales. The last week had the highest sales with a combined 126 units, 71 of which were Hiragana and 55 were Katakana.

Biggest Markets

Close to half of the sales were in the US market (122) with Germany, Canada, Japan and Australia being the other regions with more than ten sales each. The long tail of stores selling less than ten units represents 85 sold units, with 11 stores clocking in at one sold unit each. I doubt I'll ever see any profits from those markets as I need to sell approximately 100 units in a store to reach Apples minimum amount of $250 for royalty payout.

The information above is based on the weekly stats reported by Apple. Apple also provide daily statistics, but you have to grab them while they're fresh, only the last 7 days are available. I was out of town for a little over a week and forgot to download a few days worth of data. Going forward I'll try to store every day and return with a more detailed analysis. It should be interesting to se the daily trends. I would expect weekends to lead the sales since that's when people may have the extra time to play around with their iPods and iPhones. We'll see.

Published on the App Store: Hiragana

My first iPhone/iPod Touch application, Hiragana, has been published on the App Store. Apple's review of it took less than a week from submission to publication which did catch me off guard, as I was hoping to have more time to prepare a webpage for its launch.

Hiragana is a flash card application which helps me, and hopefully others as well, take advantage of occasional down time during the day to study the Japanese hiragana characters. 

You can slide the cards left/right to flip through them. There are 104 character cards in all, plus one information card which functions as the application manual.

Sliding the card upwards reveals the pronunciation of the character.

A double tap zooms the card out to fit the whole card on screen, and presents a card removal button similar to the ones in Mobile Safari's tab view.

The cards can either be studied in order or in randomized order. This is toggled by tapping the crossed arrows in the lower left corner.

The i-button in the lower right flips the view around and allows the customer full control over which characters to include in the card set. 

The application makes use of Core Animation to provide a very smooth and pleasant user experience.

Hiragana is available now for $3.99, all feedback is appreciated.

A version of the application focusing on the Katakana characters has also been submitted, but it is still in review.

iTunes application icon in Ad Hoc distribution

A few weeks ago I started a beta program for my iPhone application using the official Ad Hoc distribution model, allowing my beta testers to install early versions of the application by simply dragging it into iTunes. It's all very convenient, but it bothered me that my application showed up under the Applications section of iTunes with a boring black generic icon.

Luckily there is a simple fix for this.

What you have to do is prepare a 512x512 pixel JPG image, rename it iTunesArtwork, without extension, and then copy it into your application bundle. You access the contents of your application bundle by right clicking the .app in Finder and selecting Show Package Contents, then just drop the image in there next to all the other stuff making up your application.

 

Running SDK apps on a jailbroken 2.0.1 iPhone [Updated]

Update: There is useful information in the comments about how to do this with later versions of the SDK as well. Thanks to everyone who has contributed. 

 

This summer I've spent some time working on my iPhone app, which I hope to release on the App Store later this fall.

Since I imported my iPhone from the USA, I have to use the iPhone Dev Team's Pwnage Tool to unlock and jailbreak it. I chose to stay on firmware 1.1.4 until 2.0.1 was available to avoid the performance issues that were widely reported. This means I have not had the opportunity to try my application on the phone itself, but last night I updated to 2.0.1 and tried installing the app.

It turns out my application works great, but I still need to add a few more features and spend some time generating nice visuals to replace the placeholder graphics I am using.

To get the application running on the iPhone I had to copy it using scp to the /Applications directory on the phone and bypass the iPhone Code Signature check. After some googling I found the ldid tool written by Jay Freeman, which takes care of the Code Signature.

Here are the steps I used to get my SDK developed app running on a jailbroken iPhone, all commands should be entered as one liners in the Terminal:

1. Make sure you set Xcode to compile for the device, not for the simulator.

2. Compile the project, then copy the resulting MyApp.app directory to the iPhone's /Applications directory.

mac# scp -r MyApp.app/ root@iphone_ip:/Applications/

3. Access the phone using SSH. The root password is alpine, at least on my phone.

mac# ssh root@iphone_ip 

4. Make sure the executable is marked as such, this step is probably unneccessary but it wont hurt anything.

iphone# chmod +x /Applications/MyApp.app/MyApp

5. Install the ldid tool, this step probably needs Cydia to be installed on your phone.

iphone# apt-get install ldid

6. Run ldid on the application executable on the phone.

iphone# ldid -S /Applications/MyApp.app/MyApp

7. Your application icon should now turn up once the phone is rebooted.

These steps will work even if you have not been accepted to the paid iPhone developer program.

Note that these instructions are experimental. I can't be held responsible for whatever happens if you try them.