Archive for the 'iPhone' Category

Pebble: First Few Weeks

Monday, April 1st, 2013

What seems like a long time ago now, I backed a Kickstarter project to create a smart watch for iOS and Android called the Pebble. Due to deliver late last year, the project ran a little over schedule, but a few weeks back my Kickstarter Edition Pebble watch arrived in the mail, and I have been living with it ever since. This is my summary of my experiences in those first few weeks, using the watch connected to my iPhone 5.

I am deeming it to be semi-smart though, in contrast to some of the watches that are available since without the connection to the smartphone it does nothing more than tell the time. Even updating the time when daylight savings came into effect was dependent on a ping from the associated phone.

more…

Prepaid Plans for iPhone Users

Sunday, December 30th, 2012

As a traveler who likes to stay connected, but doesn't like the rates that my home network operator charges when roaming, I am accustomed to looking for a prepaid SIM for my unlocked iPhone before traveling. When a relative from Australia said one of her first tasks after landing was to sort out a plan for her iPhone (which she checked was unlocked), I thought I would take a look at the prepaid plans available.

more…

Free With Ads or Ad Free

Tuesday, April 12th, 2011

Every so often an app comes along that breaks the sacred rule of ads: they include some form of advertising in a paid app. The most recent was Angry Birds, a hugely successful $0.99 app, by including a house ad on their pause screen. That’s pretty innocuous – most players will rarely, if ever see that screen, and the ad was for other Angry Birds products. But where did this rule come from?

Free With Ads
Most people seem to have accepted that a free app with some ads is an acceptable compromise, allowing the developer to collect some revenue to (help) pay for the development & maintenance of the app. This model appeared on the web too, where many sites carry ads to pay for their content being free.

Unfortunately, it rarely brings in enough money to truly pay for the development of the app, or the creation of the content. As the news industry is discovering, ad supported web sites alone just don’t pay the bills. The solutions for the web are well known:

  1. Less content, which is a vicious circle, since less content means less ads;
  2. Lower quality content, also a vicious circle since you less readers;
  3. Subscriptions for accessing some or all of the content;

In the app world, especially in an app world where updates are expected to be free for life & the initial purchase price as near to $1 as possible, the choices are more limited. The Angry Birds idea of adding discrete ads later in the life of the paid app seems like it might become more the norm as developers loom for ways to at least subsidize ongoing maintenance of very low cost apps that are in the long tail of their sales volume.

Old Media
The odd thing about the fuss over ads being included in a paid app is that most of those complaining are probably happily paying for newspapers, magazines and television content, and at rates often much higher than $0.99 for life, yet all of those include ads as well.

My Comcast cable bill makes my app purchases look insignificant, and yet almost all the channels on there show ads. Even the premium HBO channels show house ads between programming; essentially the equivalent of the Angry Birds pause screen ad.

Watched a movie at a theatre recently? Over $10 to enter, and they spend 15+ minutes before the movie plays showing ads for all kinds of things.

Why is it acceptable to pay for these types of content and still see ads, but it breaks an inviolable law for a paid app, charging a fraction of the price, to include even discrete house ads? Seems like there is a double standard there somewhere.

Free Updates
There’s no such thing as a free update, at least not for a developer. Every update, no matter how small, involved time and effort. It also requires an annual subscription to the developer program(s) for the platform(s) the app is being supported on, and continuous outlay for expensive hardware to make sure the app works on the latest devices as well as a selection of older ones.

I don’t want this piece to become a whine about how developers are not getting paid enough for their apps though. If you’re not getting paid enough to keep your business working, you need to look for a (creative) solution to that, or change business!

With enterprise software, the cost of updates is covered by, often very expensive, annual maintenance contracts. For shrink wrapped or downloadable desktop consumer software, the initial purchase price includes some maintenance, and major updates normally have to be paid for (if you’re lucky, at a discount rate). But for mobile apps, free updates for lifetime have become the rule. A developer who tries to charge for an update by making the next version of their app a different app that must be bought again is likely to called greedy & given lots of bad publicity online.

In some segments of the market that is less of a problem – games, as an example, have a short life before they are replaced by the next great idea. Apps that are expected to have a longer useful lifetime find it harder to maintain a revenue stream that can pay for new features, or even maintenance of existing ones.

Options
What options are available in the current app world to a developer wanting to keep improving their app?

  • Ads, even in an app that was initially paid for;
  • Subscription for content and/or a service;
  • Charging for new features via in-app purchases, or by creating new apps on major releases;

If your app does not lend itself to a service you can charge for (or Apple’s ever changing rules on subscriptions outside of the app store payment mechanism concern you), then your options are charging for new features or running ads.

In the near future, in expect we will start to see more paid apps including some form of advertising. I hope it is better than the generic & poorly targeted banner ads we see today from networks like AdMob and iAds.

Location Based App Survey

Saturday, November 13th, 2010

You Are HereDo you use any of the current location based services? Things like Foursquare, Gowalla, Facebook Places or even Yelp’s check in option? Or, perhaps you don’t use them because you don’t like something about them? If you have a spare couple of minutes, we’d really appreciate it if you could take our 7 question survey asking about these applications / services.

Once we have enough answers in the survey to make it meaningful, we’ll publish the results here and/or on the ourLivez site.

Torpedo Alley

Monday, October 4th, 2010

At the end of last week, ourLivez LLC, my fledgling mobile app development company, launched its first game for iOS devices (iPhones, iPod touches and iPads): Torpedo Alley.

The game is pretty simple in concept, but surprisingly addictive. Fire your torpedo at just the right time to hit the mothership on one of its two weak spots, destroying it. You have at most 5 torpedoes to achieve this goal. As you progress through the game though, defending mini-subs appear to block your torpedoes.

On the iPad, the extra screen space allows us to support two player mode so you can play with a friend for added fun (not to mention the extra element of strategy from allowing your friend to take out the defending mini-subs allowing you a clear shot at the mothership!).

Want to see a preview of the game in action? Check out our YouTube video:

All of that fun is just US$0.99 (or equivalent in other currencies). Buy now from the App Store.

The app is on Facebook as well, and we’d love it if you could ‘like’ our page:

Newspapers Are Killing Themselves

Tuesday, June 8th, 2010

Yesterday saw the removal of all of my iNewz apps from the Apple app store. Not something I really wanted to do, but something that was forced on me by the very people who stood to benefit the most from the apps: the news organizations who publish the news.

Yesterday was also the day that another RSS based news app, Pulse, was removed from the store despite being praised & shown on stage at WWDC by Steve Jobs. Why? Because the New York Times complained that the app contained the URL for their RSS feed. Quoting from the letter Apple received from the Times:

I note that the app is delivered with the NYTimes.com RSS feed preloaded, which is prominently featured in the screen shots used to sell the app on iTunes.

The same argument was made by Apple to me for the recent rejection of an update to iNewz (and a few more news feeds were cited as problematic too).

more…

App Store Roulette

Wednesday, May 19th, 2010


This week I have been presented with something of a dilemma regarding what to do with my iNewz applications for the iPhone, iPod touch and most recently the iPad. As is often the case with apps for these platforms, the cause of the problem is nothing technical; it began with Apple’s review process, or more specifically the inconsistent way in which it is applied.

The Rejection
Like most app developers, I’ve had rejection emails from Apple before (actually called “feedback”), and they have normally been for things that are simple to address, even if not always things I agree with the need for.

This one was different though. Here’s the key paragraph of the email:

more…

Twitter xAuth – The Missing Docs

Saturday, May 1st, 2010

The recent decision by Twitter to turn off support for Basic Auth soon means a lot of Twitter apps are now racing to implement either full OAuth support, or the cut down xAuth designed for non-web apps. The iNewz apps fall into this last category, and an initial look at the work involved made it seem as though switching from basic auth to xAuth would be pretty straightforward. Sadly, and mostly because of poor documentation and what I consider bugs in the Twitter API implementation of OAuth, this took far longer than it should have done. Hopefully this blog post will help others looking to make this switch by providing a more complete, step-by-step description of the xAuth process. It may also help those trying to make full OAuth work, but I haven’t tried that yet.

more…

Multitasking & Battery Life

Thursday, January 28th, 2010

One thing that has annoyed me for the longest time now is this myth that multitasking somehow reduces battery life. The iPhone multitasks today, it just doesn’t allow multiple third party apps to run concurrently.

I’ve written a lot of software, both application and system level (right down to the lowest levels of an RTOS), and believe me, if it is written properly a background app does little or no harm to battery life.

Many of the applications that people would like to see running in the background would spend almost all of that time waiting for a system event. That waiting state doesn’t harm your battery life; only when the application is actually processing something does it really consume power. The push mechanism on the iPhone today might actually be worse since it has to load the app each time, a far more expensive operation (in CPU, and therefore battery) than just switching to one that is already “running.”

Consider the IM app example that is so often used to support the claim that background apps kill battery life. Sure, if you run the IM app (background or foreground) and stream messages at it continually, then it will reduce the battery life. If you just have it sitting there in case somebody tries to start a session though it isn’t doing anything most of the time (occasional presence messages perhaps). I ran an IM app all the time on my Nokia N95, connected over AT&T’s network 24/7. My battery life was unaffected, as expected.

Another example of a well behaved background app is the daemon that we wrote for the jailbroken version of Devicescape’s app (before the SDK and app store existed). It made no difference to battery life because it spent almost all the time blocked waiting for a system event. One that only happened when a new Wi-Fi connection was made. We run in the background on Nokia, Windows Mobile and Android (not to mention Windows XP/Vista/7 and Mac OS X) today without impacting battery life.

So what will affect battery life? Well, an app that continues to do something in the background, rather than waiting for an event, one that polls for an event rather than blocking until the OS tells it about the event, or one that requires a power-hungry piece of the hardware to be on all the time (e.g. GPS). But even those apps have their place. Imagine a background image uploader: it will do something in the background while it is needed, and then exit or wait for a new photo to be taken. Or an app that checks your location every 5 minutes. It is my choice to use the battery that way, so why restrict it? Just make sure it is reasonable for the application, explained to the user, and under my control (can be checked as part of the review process).

These types of apps don’t take any more power than they would if I left them running in the foreground, but letting me push them to the background allows me to choose if I want to watch them work, or read my email etc.

Above all, please stop spreading this myth that multitasking or background processes will harm battery life. Only badly written apps would do that.

App Store Economics

Wednesday, July 29th, 2009

There’s a lot been written about how amazing the iPhone app store is, how many apps it offers and how many downloads (a somewhat deceptive number since it includes updates) there have been. But recently there has been an increasing amount of noise in the developer community about the problems with the app store, and in particular its long term (or even medium term) viability. Why is that? Aren’t developers reaping the rewards of all those downloads and becoming rich?

more…