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)

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 pouring through 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. 

Zoinks, indeed!

The not-so-governental guide to the unemployment rate. This is scary stuff.

(Via Big Contrarian)