Category Archives: Software

Over the holidays I somehow found the time to code up an advertisement server for use with my mobile Apps.  The reason for writing a custom solution for this is that I wanted to use non-standard image sizes which I can then pull into the apps and games in unique ways so that they don’t have the look and feel of an ad.

The custom ads will be popped up in a balloon, animated across the screen or hidden in a drawer waiting to pounce.  With a unique delivery of the ad I hope it can stand out without getting in the way or feel annoying.  With the non-standard sizes I hope it won’t get the immediate “this is an ad” response from people who see it.

One of the things I have learned about doing print advertising and direct mailers is that to be noticed you have to do things unexpected.  Show someone something that they simply can’t ignore.  That’s why the classic 5 cent letters work so well – a nickel attached to a letter will immediately get noticed, and you will surely open it up.  Getting outside of the normal bar style ad along the bottom of the screen is just one simple way to break out of the expected.

Going with the standard ad services out there such as Admob or one of the many other networks is a good way to get paid, but (from my testing) is a terrible way to advertise.  Erroneous and fraudulent clicks are rampant on phones and paying for clicks simply doesn’t come close to breaking even in most cases.

I needed ads that could be targeted and integrated with the look and feel of an app.  To do that I wanted the flexibility of an image. but I also wanted the ability to provide both app specific ads as well as network wide ads.  So for example if there is a free and paid version of the app I can always advertise the paid version on the free app.  But moving the ad to the server allows me to test different images, or run special promotions.

Looking forward to seeing how it performs live in January.

Having developed a few iPhone/iPad apps now there has been a few things that have tripped me up and created more work than necessary.

One of those is that small bugs in the program such as a bad link, misspelled words or game play tweaks like speeds and frequencies that you want to change after the app has been submitted usually require fixing the code and re-submitting the new binary which takes another week to get reviewed.  Depending on the error it could delay the marketing push on the app and cost you a week of lost revenue.

The week long delay in fixing what can be trivial typo errors can be frustrating.

To counteract that it can be useful to move some of these settings to a plist file and update the values from a website.  It can be as simple as putting a json/xml file on a web server somewhere and loading/parsing that file every time the app comes into the foreground.

This feature has become central to a few of my apps.  allowing me to update the content of the app with fresh information, it has also allowed me to test various minor changes in some games in production, and allowed me to fix a link to include an iTunes affiliate link after it was published without one.

This merging of what makes native apps so great (speed, better controls etc) with what makes web apps great (always up to date, easy to deploy fixes, and tracking) is what I find most interesting about mobile apps.

As a way to help encourage me to learn how to use Inkscape to draw vector art I set myself a challenge over this past weekend to re-skin an iPhone/iPad game.  I wanted to completely finish it and submit it to Apple.  Which I did manage to accomplish.

The result was Whack A Turkey.  A very simple game which is finished and currently waiting for approval into the App Store.

I must say that using Inkscape was surprisingly easy especially after reading through the tutorials that inspired this endevour.  2D Game Art For Programmers over at Gamasutra.

The very first lesson I have learned about making profitable iPhone Apps is that the most effective monetization strategy is to have a free app with in app purchases.  I have very little problem spending $0.99 for a game on the App Store, but I have found that there are many people out there that don’t have credit cards attached to their iTunes account or simply won’t buy things.  The free app gets past this initial barrier and also opens you up to additional people who can play with your app and act as word of mouth promotion.

For in app purchases a lot of thought needs to be put towards how best to price things.  Choosing the most effective price points and providing a range of options so that people can buy the things they find the most value in is crucial and non-trivial.  But one key thing to keep in mind is to make it really easy to spend $1 and possible to spend $100/month.

The value of money is a strange thing.  To me spending $100/month on a iPhone game is crazy, but to others $100 is only 10 minutes worth of work.  Perspective is everything.  In a world with an increasing gap between rich and poor it is important to give rich people ways to spend more of their money – selling digital goods with zero marginal cost is a pretty good strategy for that.

Looking forward I don’t think I will consider doing an app that doesn’t have the opportunity to make full use of in-app-purchases.  I’ll share my actual numbers at the end of the month.

After getting UFO Invader published there were a couple of things that became obvious points of improvement from a marketing perspective.

Web sites have the advantage that you can count on having internet access when visiting a website so it’s easy to tie things in dynamically all over the  place.  Things such as Adsense ads are loaded and managed by other people using other services.  they change depending on who you are, what the page is like, and what time of day it is.

With a turn around time for publishing native apps to the iPhone being more than a few days – having anything from news messages, advertisements or dynamic content becomes a bit more complex.  You can’t simply push an app update out to update a message to say you’re working on a big update for example.  You also can’t count on internet access being available.

The idea for the iPhone App Control backend is to pair a web admin service with a library of Objective-C UIKit components.  An API call would be made out to the service to get marketing messages, news or alerts text or whatever else and it would also serve as a bit of an analytics service, tracking clicks on ads, and perhaps performing A/B split tests on offers.

Once built, this software will help control all of my current and future iOS Apps.

Will I release this software?  I’m not sure.  What do you think?  should I sell it? open-source it?  sell accounts and access?  Let me know your thoughts…

Test driven development has become the status quo for any hot start-up.  It has become part of University Computer Science curriculum and become a fairly significant movement (religion) among Software Developers.

However, in my various jobs, and through several personal projects I have found that unit testing is often more trouble than it’s worth.

What brought me to this conclusion?

First, writing tests takes time – usually far too much in my opinion.  Tests should be simple and obvious to write, but somehow they almost never are.  In my experience tests feel like the worst kind of hacked code.  You often have to get down and dirty with low level knowledge of the language in order to fake things so that they appear to be working for the method you are testing.  This could be by injecting fake implementations of classes or doing run-time modification to replace functions or methods.  It’s stuff that I find counter intuitive and far more complex than simply finding ways to make user testing easier.  Making the code so that it is easily testable I have found results in added complexity with logic spread all over the place.  It makes it difficult to follow simple processes when everything is pulled together at run-time.

Second, tests can take a while to run.  In the time it takes to run tests even if it’s just 1 minute I often find myself distracted.  As a result my ability to focus on the code at hand is greatly reduced as my brain context switches between writing code, starting the test-suite, getting distracted and reading something on reddit.com and then remembering tests were running and finally getting back to the code.  It’s said that the brain takes about 15 minutes to regain focus after a disruption.  Test driven development rarely allows for 15 minutes of focused coding before switching to running tests.

Finally, in a productive work environment using high level languages, with knowledgeable people, good logging and notification systems, and systems in place for quick and easy deployments to production any bugs that do happen to make it into the wild should be quickly reported and usually simple to fix.  This is generally the case when changes are small.  Bigger changes should be user tested – even if there is a solid set of automated tests in place.

There are cases where I do find tests to be useful.  Generally it’s when I find myself accidentally breaking things more than once.  Usually though these tests are just superficial – do all the URLs in my web app resolve correctly? will a function run?  But other cases for automated testing is usually called for when sensitive money handling code is being developed, or public APIs need to be security hardened.

Having worked with teams on big projects that relied only on user testing and ones that relied heavily on automated testing the productivity was much higher on the user tested code, while the code quality (in terms of bugs – not code organization/structure) was close to the same.  But of course your mileage may vary.

After the initial release of UFO Invader there was one thing that I found extremely frustrating.  Lack of information about how many people were using the game, how often they were playing, and what areas of the menus were being accessed.  I was left to guess based on download numbers, ad impressions and the number and quality of reviews how it was doing.

Real data on app usage allows you to make design decisions based on what people are actually doing rather than what a few loud people say they want.

Doing a bit of digging yesterday I found out that there is a Google Analytics SDK for iPhone apps.  It allows you to track exactly what users are doing when they’re in your app and then you can easily comb through the data in Google Analytics.

Google Analytics gives you tons of ways to slice and dice the information.  But there’s a catch.

Analytics is designed for websites. Within a native application some of the concepts need to be twisted a bit to make sense, others won’t work.  It’s also a bit different in that you have to manually trigger all events in the code it’s not as simple as adding a bit of javascript to a WordPress theme.

However, it only takes an hour or so to get everything set up in your app to use Google Analytics.  The insight it gives into how people are using your apps and what they do with them could easily be worth 10x the effort.

Update: After playing with a bunch of different analytics options,  Google Analytics seems like the worst of the options (the library takes up a massive 1MB in your app, and it is kind of awkward to code)  I have opted to switch over to using Localytics

Since launching UFO Invader in early August I have been hard at work with a MAJOR update to the game which will add in all the features that I never had time to implement for the first release.

This is totally changing the game.

I have added a store and a currency system to the game with a couple of novel ideas that I think will be interesting to gauge the response on. Users will be able to upgrade their ship, with various weapons, power ups and just like the old arcade games there will be a pay to continue option.

One thing that I have been interested in trying to tackle is adding features that give the game more replay value. Some of the things that will be implemented are:

  • different gameplay modes
  • progressively get harder to make beating your personal score more of a challenge
  • prominently displaying friend’s and global top scores for incentive
  • new levels, graphics, power ups and upgrades to change gameplay options and add variability
There was a very long list of things on the TODO list to get this done.  A lot of effort was put into getting the iPad version working which was actually a lot more time consuming than expected.  A result of doing the iPad version is that the entire menu system was overhauled with new graphics. It looks 10x better.
I’m excited to get this out there.  It should be in the store sometime  in the first week of September.

There are many ways that you can make money with an app on the App Store.  One of the lesser used ways is through affiliate sales.

Apple has an affiliate program that runs through LinkShare.com which pays out 5% on iOS Apps, Music, iBooks and even the Mac App Store software.  It’s free to sign up for LinkShare.com and takes just a couple days to be approved to promote App Store products.

Once signed up you can start creating links using the Apple Link Maker which will deliver a user directly to the App Store if they click the link from their iOS device.  It puts users in a position where one click and a password is all that’s needed to make a purchase – and for you to get a 5% commission.

It was an important part of my longer term App strategy to bake this into everything that I ship for two reasons.  I can share some of my favorite games with people for a few extra bucks in my pocket and going forward I can swap out swap out other people’s games for my own and use the same code to help promote my other products.

The code that I wrote for this feature I have made freely available for you to integrate into your iPhone App.  I would love to start seeing more indie developers finding new and different ways to monetize their apps.  Every little bit helps, especially when it’s a small shop.

It gives you a screen that looks like this:

 

Clicking on one of the links brings you right into the iTunes store to read more about the app.  The About tab is there just for information about the current app and back will dismiss this screen and put it back into the game.  It’s very basic code and should be relatively easy to understand and use.

To use this in your own iPhone App check out the project on gitub.

Waiting seems to be something that you have to get used to when dealing with Apple.  Granted, the whole process is vastly more efficient than waitingit was back in the days of physical distribution.  And I’m thankful that that I don’t have to hire a publisher and deal with box designs, CD duplication and the massive up front costs they would have incurred.

In fact the 1 to 2 week waiting time I expect for my first game to be approved is hardly enough time to get my marketing plan up and going.  There’s videos to create, stuff to write, lists to build and people to contact.  It’s all work that takes time.

However, it’s also frustrating when people who are anxious to play it can’t and have to wait weeks before they can – even though the development is finished.

These next few weeks are also a time to start looking forward to my next app.  The first one isn’t yet out the door and the next one is already getting sketched out on the whiteboard.  Getting the jump on development is going to be key to keeping the flow going.

So yes, there is some waiting involved, but it’s actually a welcome break to focus on next steps.