App store pricing is done in tiers, you can’t just set an arbitrary price for your app, in app purchase, or news stand subscription, you have to pick one of the predetermined price points. That still leaves you with quite a bit of flexibility though, because there are 87 of them, 88 if you count free as tier 0.
In US Dollars (at the time of writing), Tier 1 is 0.99, Tier 2 is 1.99, Tier 3 is 2.99 and so on all the way up to Tier 50 at 54.99 where the gap increases to USD 5 for a while, jumps USD 10 Between Tiers 60 (99.99) and 61 (109.99), and 61 and 62 (119.99), USD 5 between 63 (124.99) and 64 (129.99) then settles down to USD 10 all the way up to Tier 77 at USD 249.99. Then you get USD 50 increments up to Tier 82 at USD 499.99 and then USD 100 increments all the way up to Tier 87 at a whopping USD 999.99…
I’m coding an ObjC application that I want to do a number of things in parallel using a GCD dispatch queue, but I want to limit the maximum number of tasks that can be running on the dispatch queue at any one time. Mainly because the tasks are going to be hitting up someone else’s web server pretty damn hard and I want to be able to throttle it to some reasonable number so as not to be rude.
I've tried to cover a full range of topics as an introduction to iOS design.
Lots covered, and links to even more in depth coverage of a whole load of important iOS design background. Great stuff and a must read.
Contemporary mobile voicemail is an amazing technology. Even the humble answer-phone tech from which it evolved is pretty damn clever, not just technically, but conceptually. The essence of the concept, and the thing that makes it so great, is that simply by swapping a synchronous communication for an asynchronous one it offers the opportunity for turning a failed effort at communication into a fulfilled one.
For an added bonus, the asynchrony also offers productivity benefits : the caller knows their message has been delivered and will be received and can move on to the next task. The callee, safe in the knowledge that communication has been received and stored while they were unable – or unwilling – to engage in a synchronous communication can pick up the message later and prioritise and schedule a response.
And that’s just the model with the answer phone. Throw in modern mobile communications networks and it just gets better. The computer at the phone company will not only patiently store the message, it will then diligently hunt me down wherever I happen to be in the world and make sure I’m notified that there is a message waiting.
There is literally no way for me to miss a message. Unless, of course, the caller doesn’t leave one. Which, of course, happens around 99% of the time…
In part 1 of the ‘App Store Noob’ series, I chucked out some big old aggregate numbers, and in part 2 I’m going to chuck out some more.
As noted previously there are 155 App Stores, and between them they employ a total of 20 different languages and 24 currencies.
Distribution wise, these lean heavily towards English and US Dollars, as you can see from the following rather cak handed Excel charts. Better charts later, I promise.
It should be noted that the languages and currencies employed by the various App Store web fronts are mostly not the languages and currencies native to the host countries, so this shouldn’t necessarily be taken as an upper limit on any localization efforts you might need to make to get into various markets.
It does rather suggest that your first non English localization target should probably be Spanish, being as it’s the second largest App Store language. People using those 18 stores are probably going to have a much better first impression of your app if the language in your App Store copy and in your app is the same as the language used in the store, primarily because they won’t have to do any cognitively expensive context switching.
Next time, I’ll briefly outline the pricing structure before we get onto pulling some more interesting numbers. To be going on with, here’s some charts and tables.
If you have an Apple laptop of some kind, or you use a magic mouse or trackpad on the desktop, you can use gestures to zoom in and out of web pages in Safari.
If, on the other hand, you have some kind of non standard setup – I use a hefty MS Sidewinder multi button mouse and a Saitek Cyborg illuminated keyboard jacked into a Mac Mini, for example – your zoom option is : you can press [command] and [+].
But I missed my zoom wheel, so I stuck with Chrome until the flakiness of the wheel zoom add on I was using made me stabby and I finally sat down and figured out how to hack mouse wheel zoom into a Safari extension.
Last time, I said I’d be writing a series of posts linking to various stuff you’ll probably want to know about the App Store if – like me – you’re an App Store noob. If you’re an indy trying to write a business plan, the first thing you’re going to want to know is stuff like market size, total market revenue, etc. These numbers aren’t especially hard to come by, but to kick off the series, here they are gathered together.
Later on, we’ll see that by themselves these aggregate numbers might not be quite as helpful as you might imagine, but you’ve got to start somewhere. As of May 2013, the officially available bignums are as follows.
I have a whole series of posts coming up on the Apple iTunes App Store, starting with a great big dump of links that you can use to start figuring out what all the important numbers are, what kinds of analysis people have done on them so far, and how you can do some of your own.
To be going on with, here’s a teaser trailer. Question : How many of the top grossing apps in a given store are using the freemium, in app purchase, or iAd revenue models ? We’ll ignore the effect of rank for now, more on that later. How can we get some rough figures ?
Over at scripting.com, Dave Winer discusses RSS readers with Brent Simmons.
I can scroll back to the point where I hit something I seen. Quickly. My memory is perfectly capable of telling me I've seen something before. You can rely on it, people can do this.
No. No you can't. This is UI design 101, lesson 1. I mean that literally. This was in the first lecture of the first year class on Human Computer Interaction I took in the hazy days of uni. The more cognitive load you place on your user, the worse their experience of your interface is going be, and the approximate memory span of the average human has been extensively studied since the cognitive psychologist George A. Miller published his landmark paper The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information in 1956, which you will find cited in the first chapter of any HCI book you pick up,
There may well be specific subsets of users for whom this is not an issue, but the general case is the exact opposite.
For some reason, I often find myself getting tangled up with UIViews. A sure sign that I need to spend some time getting my head around their conceptual framework.
One thing that keeps tripping me up is that I start off by doing loads of setup in the
viewDidLoad method of the root
UIViewController, and it turns out that this is spectacularly bad practice.
One thing I find myself doing on a fairly regular basis is looking for a list of the various iOS device screen resolutions. I’m actually 100% sure that I’ve seen one in the Apple docs somewhere, but I’m buggered if I can find it again.
So naturally I end up googling, but the hits that come up top on google aren’t massively helpful. Hopefully, this will percolate its way up the SEO rankings and be of help. Probably just in time for it become obsolete.
I’ll keep it updated when new hardware arrives, in the mean time, if you’re reading this and spot and error or omission, please do leave a comment so I can fix it.