Monday, 9 September 2013

Kickstarter and iOS Apps

Some Kickstarters are about creating mobile apps and others use mobile apps to give some extra value as part of a stretch goal or add-on.

Getting your Android app to your backers is relatively simple - you just point them at a secret URL and let them side load it.  But for iOS apps, that's not so easy and you can't assume that all your users have a Jailbroken phone - I'm a developer and I don't have a jailbroken phone.

If you promise an iOS app to your backers and you intend to charge for your iOS app, there's a few important notes to consider:

  • If you gift an app to someone, even if you created it (or are the legal owners of it), you can't do this for free.  You'll be charged the full amount and then Apple take their cut before giving you the money for it (a couple of months later).  Apple don't want you cutting them out of the financial loop at any stage and even though it's your app, you're playing in their sandbox.  That's a bit like expecting retail stores to take delivery of your stock and distribute it to people who pre-paid through some other channel.  
  • You can't gift apps across App Stores.  Someone in the US can't gift an app to someone in the UK.   Well, that's not strictly true.  If the sender has an iTunes Store account for the destination country and has a credit card registered to an address there then you can select the destination store and gift it directly.  There are some countries which you can gift to direct from the US store, but it's not clear which countries can be gifted to directly from other stores.
  • You can't gift free apps.
  • You're limited to 50 100 promotion codes per version of the app.  If you artificially roll your app version too many times for this purpose your app will be kicked out of the App Store.
So what strategies can you use?

One option is to make the apps Tier 1 price for a day, generate all the gift codes and then up the price to whatever is required on subsequent days.  However, you still have the problem of cross-store gifting.

The most common approach is to make the apps free for a short period, notifying backers well in advance, and then change the app to a paid app later.

Finally, consider not charging anything for your app, period.  Or rather, adopt a freemium model.  A lot of the the top grossing apps are free with in-app purchases, so it's food for thought.  Deliver what your Kickstarter backers are expecting and put it on the App Store for free, but make sure to let them know it's not exclusive, and then add new functionality that people will want to buy later.

Sunday, 25 August 2013

Enterprise Android

Well, in a strange twist of fate, when considering my last post, but I find myself on an Android application for a UK financial institution.  It's a fun project, mostly, but working with Android in an enterprise environment has its challenges.

We have a continuous integration environment based on Jenkins and our build uses Maven.  However, we have a number of dependencies which are not available via Maven central so currently have to install a few jars in each environment we build in.  Not pretty, but we are hoping to get our own repository set up soon.

We have two projects, one that builds the app and one that contains UI tests.

In the main project we have unit tests based on Robolectric and in the UI test project we have tests that use Robotium.  Since we are using Eclipse as our IDE (at the moment) Maven causes us a little pain.  The m2e plugin combined with the m2e-android plugin struggles with dependencies - it can't separate the testing dependencies from the ones used by the app itself and ends up including them all.  As a result Android will try to dex a lot of classes that it doesn't need to, including its own library which causes all kinds of problems.  Our solution was to have separate Maven profiles which you change via the Maven preferences depending on what you want to do; unit testing or running the app (or UI tests).  Generally, I leave Eclipse in "unit testing" mode and run the app from the command line.  However, if I want to run our UI tests then I do have to switch and if you forget to do a proper clean of your environment (I call this "the dance" or "the ritual") it can result in some unexpected results.

Of course, none of that is required outside of Eclipse, so we are waiting for the right time to move to IntelliJ IDEA or Google's own Android Studio based on the same technology allowing us to simplify our build somewhat.

On Jenkins we have three jobs in a kind of pipeline, each job triggering the next:

  • Build for Junit
  • Build (and run) UI tests
  • Build a clean APK
Of course, it's not a proper pipeline because if someone commits while the Junit job is running then the subsequent builds end up using the committed code rather than what was used to execute the unit tests.  I am hoping we will switch to something like Bamboo which should, I believe, allow us to do this properly.

Additionally, there isn't a reliable way to run UI tests at the moment, especially headlessly, so all that job does is compile the UI test project code.  We are planning to use a Mac Mini in the office with a device attached, but will need to unlock the device(s) and login in to the company's WIFI on a daily basis, so that's not going to be very efficient.

We also have a fourth job for doing releases.  With a single click (and after entering a couple of parameters for version numbers, etc) we can build a version of the APK with its manifest properly configured with a new version code and number.  The APK is then published to our Confluence so that interested parties can install and use the application, though anyone who knows where our Jenkins is located is welcome to install the dev version of the APK at any time.

Fragmentation has only been a minor issue so far.  We of course have to design for a number of device sizes and resolutions which is tricky enough, but have noticed some strange behaviour on (wait for it) Samsung devices, especially the S2 running TouchWhiz.

We are also using ActionBarSherlock to provide ActionBar functionality for older devices, but have been glad to hear that the new support library supports it explicitly.   Maven support in Eclipse has been painful particularly ActionBarSherlock has been sherlocked by Google?  It seems so.