iOSDev UK: Tap to Experiment

Chris Ross, Osmosis Apps, @darkrock

An attempt to find success on the AppStore

• App: Tap to Chat
  • Other chat apps look very similar — buddy lists & tab bars
  • Decided to try something different — picture-based
• Go along to a nearby group (e.g. Brighton iPhone Creators)
• Experiment #1: universal Facebook chat app with a novel UI
  • 1.5 weeks each for two people
  • Used pre-existing code from other apps (Facebook XMPP chat)
• Collaboration helps — both to evolve good ideas and filter bad ideas
• Can appeal app store rejections, even if you don’t change the code (e.g. if your app relies on a third party that was down during testing)
• Don’t underestimate the phenomenal power of the Christmas period
  • e.g. EA drop their prices just before Xmas, their apps go to the top, and their downloads rocket
• Experiment #1.5:
  • iAds seeing only 10-15% fill rate
  • Apple pay you just to show the advert
  • Admob have a higher fill rate, but only pay you for click-through
  • More differentiation with paid app
  • Removing adverts is not enough to get people to buy the paid version
  • Added “share app on friends’ walls”
  • had a spike -> 1000 shares a day
  • revenue jumped to £4-4.5K / month
• Experiment #2:
  • Started a company to house the app
  • Rewrite the code
  • Changed the facebook (spamming)sharing since Facebook complained…
  • but they were polite
  • Added Google chat, AIM + others
  • More free apps: one per API — better upgrade path (get all in one app)
  • Got a designer
• Aimed to do all that in two weeks…
  • but took three weeks from 6am-11pm
  • downloadDidFailWithError is a private API
• Got an expedited AppStore review to be in store in time for Apple Design Awards
• Results:
  • Revenue jumped to c.£6k/month
  • Difficult to convert people from v1 to v2 (especially since v2 was on a new (company) iTunes account)
• Success in the AppStore?
  • Overall stats:
  • Mean amount of money made: £30,000
  • Median amount made: £600
  • Tap to Chat:
  • 18% revenue from paid apps (18K downloads)
  • 82% revenue from adverts in free (500K downloads)
  • £40K made so far
• Moving to using mopub to do advertising
  • provides more control on the server side
• Mistakes
  • changed sharing in v2 — less visibility
  • no push notifications in v2 (but kind of a choice anyway)
  • transitioning to a new iTunes Connect account
• Next steps
  • building a backend server for push notifications
  • building libraries for MSN & AIM
  • improving user retention:
  • Osmo character offers advice and news

Q&A

• Facebook App ID
  • can share same app ID between apps
  • v1 & v2 (different iTunes Accounts) and free apps use same facebook app ID
• Facebook spamming guidelines
  • you must have a single action per share
  • you must allow the user to edit their text on others’ walls
  • If there is an issue, facebook contact you to say that you have to resolve the issue in 24hrs — but they need you to respond in that time
  • you can ask for a grace period
  • Tap to Chat asked for 2 weeks
• Transferring iTunes Accounts
  • can convert a personal account into a corporate account if you ask
• Experiments with price?
  • v1: 59p
  • aim to bump the price with each added network
  • “no point putting things for less than £2 on the app store — if people have made a decision to buy it, then they’ll buy it…”

BarCamp London: Messaging Scales – Matt Biddulph

Asynchronous messaging coming in to web (been around for a long time, esp. in banking & finance)

Concurrent languages: erlang, scala, haskell, e

If everything is done with message passing, there is no need for shared state

messaging systems:

• dopplr uses ActiveMQ (using JSON as message bodies)
• spread is another
• google gears — provides local message bus for thread worker pool

long-running processes:

• e.g. kayak.com travel search, gradually fills in your results

dopplr coincidence calculations:

• local information done immediately
• rest of social network done by passing a message to queue
• workers just collect and get on with it
• if queue is too long can start up some Amazon ECS resources to process the queue for an hour or so

extreme late-binding

• Alan Kay said that he may have overstated the objects in object orientation :-)
• important thing is messages — work can happen anywhere if messages contain context

can have shared state using sequenced messages

• update your own state by sending messages to the bus
• everyone can share the same state
• when go offline can store messages to pass, ready for when reconnect
  • can speculatively update state to present to the user
  • when reconnect can discard speculative state and catch up properly

network quake

• short (200ms) periods of uncertainty, code guesses what will happen in that time before messages come from other players
• guarantee that players will sync about once a second

founder of erlang: “humans are long-running processes, can pass messages, others can ignore”

OTP — built on erlang by Ericsson (who invented the language)

• includes code changes as changes of state
• talks about fault tolerance
• “crash only programming”
  • don’t need shut down — just pull the plug; when start up look for any state to recover
• like XP — a set of practices that work together

Another recommendation: Enterprise Integration Patterns by Gregor Holt

Problems with message passing:

• only do it if the request really is async, otherwise wasting time
• introduces dependencies on messaging system

What’s next? Matt is currently interested in Arduino

• similar to messaging services