Fallacies of the Indie Software Business

Mon, 16 Apr 2012 11:19:02 +0200

1. The market is completely efficient. As soon as an app is released, every user has noticed this, and considered whether to purchase it.
2. Once someone has considered purchasing a piece of software, and rejected it, they will never consider it again.
3. Only people new to a platform buy software.
4. A small indie developer can easily saturate their market.
5. Mac App Store customers are used to paying for software upgrades.
6. Software developers can only survive without upgrade pricing if the platform has hockey stick growth.
7. Software developers rely on upgrade spikes to survive, because — at other times — they have no sales.
8. Software developers earn most of their income from sales spikes associated with an upgrade.
9. Writing a new app is just as fast and easy as adding features to an existing app, so there is no motivation to upgrade software without upgrade pricing.
10. Upgrading an app can only generate income via existing users. There are no other advantages to upgrading an app.
11. It is more useful for a developer to spend their whole life adding features to one app than to develop multiple apps.

Paid Upgrades and the Mac App Store

Wed, 28 Mar 2012 13:35:08 +0200

If you hang around iOS and Mac developer circles enough, you're sure to hear some complaints about how Apple runs its App Stores, and one of the most common is that they don't support paid upgrades. Yesterday, Wil Shipley presented the case for paid upgrades on his blog, with some supporting analysis of Delicious Library 2 sales through the years.

Shipley has had success redirecting Apple in the past, most recently with a campaign to introduce Apple-issued developer certificates, which will make their debut via the Gatekeeper feature in Mountain Lion. But on this one, I think he has it wrong, and I doubt very much that Apple will be shifted. Here's why.

Apple has spent the last 5 years or so cultivating certain expectations in how people purchase digital goods via their stores. If you buy a song in iTunes, it's yours — forever. If you buy an app in the iOS App Store, it's yours — forever. And now, if you buy an app in the Mac App Store, it's yours — (you guessed it) forever. It's part of what has made Apple so successful in this area. One click purchase, instant download, yours forever.

What Wil is asking Apple to do is to break this implied contract with its customers. Effectively, he wants customers to pay twice for the same product, and I don't see Apple going down that route. It could actually be hurtful to developers in some ways. One of the reasons people so readily part with their cash in the App Stores is that they know they get to keep what they buy, and even transfer it to any new devices they acquire. They own their software, they don't rent it.

Wil's blog post goes into some reasonably detailed analysis of Delicious Library sales trends, concluding that offering free upgrades would result in his company ‘...losing a quarter of our revenue'. Fortunately, his arguments are oversimplified and based on pre-App Store sales models. Some of the analysis is also a bit disingenuous. For example, he shows that for the 18 months after the release of Delicious Library 2, 24% of sales revenue came from upgrades. A closer look shows that most of that probably resulted from the spike immediately following release, and that in fact, taken over the full four years since the app was released, upgrade sales would be much less than 24%.

But even if upgrade sales did account for a quarter of all revenue, it is not valid to conclude that revenue would suffer an equivalent drop if upgrade pricing was not available. The Mac App Store does not offer this stream of income, but does offer other streams that in my experience more than balance any losses. I already mentioned that customers are encouraged to buy apps by the ease with which they can do it in the App Store, and by the knowledge that whatever they purchase becomes a digital possession. It's difficult to put a number on how large this effect is, but I am convinced by my own app sales that it is significant.

Giving away major upgrades to existing customers has a second positive effect on sales. Because all of your existing customers get the upgrade free, most will download it, and many will tweet about it, and generally encourage friends to take a look at the app. Word of mouth marketing is an enormous boost to any new release, and the more existing customers actually install an upgrade, the better. This could easily make up for the 24% loss in upgrade sales on its own, especially if you take into account the non-linear sales effects you see as you push up the charts.

Shipley implies throughout his post that making major upgrades free would effectively discourage developers from updating their software, because it would not lead to any extra revenue, in the form of a spike in sales.

But, with free major upgrades, we have this unhappy choice: for the next two years we can work on a brand-new product (call it “Delicious D”) or we can work the next version of “Delicious Library ∞”. If we write “Delicious D” we know you’re going to give us another $40 of your money, because it’ll be so awesome. But if we write “Delicious Library ∞” (and we give away major upgrades) then we’re going to get $0 of your money when we’re done.

This is patently false, and any developer who has ever released a major upgrade in the Mac App Store knows it. There is a very large spike in sales, which comes from the combined effect of increased word of mouth from existing customers, featuring by Apple, and increased visibility when the app begins to climb the charts. When I released Mental Case 2 — exclusively on the Mac App Store — I saw an order of magnitude more sales in the days after the release than previous to that. It is simply not true that free upgrades do not generate any additional income.

Ironically, it was Wil who once explained how the pool of potential customers was virtually infinite for any indie developer, that you will never even come close to saturating your market. This is exactly the reason why the App Store works, and does not need to include upgrade pricing. There are always many more shoppers out there than you currently have customers. Nickel and dime-ing your existing customers with paid upgrades means they will resent you, and you are taking your eyes off the bigger prize, the enormous body of potential new customers which should be your target.

Wil Shipley has been making money in this industry longer than most of us, and frankly, I think he is falling into the same trap that the music industry fell into when Napster came to town. What worked yesterday will not necessarily work tomorrow. The game has changed, and Wil wants to keep doing things the way he always has, when his audience is moving on.

By insisting old sales models get incorporated into the App Store, he is prolonging the day when customers forget there ever was such a thing as a paid upgrade, and that is hurting the transition for all of us. Rather than trying to move Apple, he should be adapting his software to the new way of doing things. No paid upgrades, but plenty of upgrade revenue.

Wish to comment? Head over to our Tender.

WHY NATIVE APPS ARE HERE TO STAY

Thu, 8 Sep 2011 09:29:01 +0200

I've just returned from the inaugural Update Conf in Brighton, UK. Aral Balkan (@aral) is a popular presenter at other tech conferences, and his first venture in the role of conference organizer was a raging success. Everyone thoroughly enjoyed themselves at the pre- and post-conference activities, and the day itself was a diverse mix of music, tech talks, and onstage interviews, a bit like a Tech Variety Show. Very unique, and I for one thoroughly enjoyed it.

One of the talking points of the conference was a presentation by Jeremy Keith, which was followed by an onstage debate. Keith presented the case that we should forget about developing native apps for mobile platforms, and move everything to the web browser. He is a very good speaker, and his conviction seemed to leave his fellow presenters a bit overwhelmed, incapable of launching a good defense of native apps. Despite the fact that I did not meet anyone else who actually shared his views — not even any web developers — he controlled the debate, and deserves full credit for that. (To be honest, he was so unrelenting that I thought he may be under instructions to play Devil's Advocate, but let's assume for now that he was being earnest.)

Of course, just because someone speaks well does not mean he/she is right. There are actually many good arguments against what he was espousing, and I heard many of them from fellow audience members throughout the conference. I think it is an important discussion, and I want to make a belated case for native app development here.

Keith made a number of key points in his talk. The web, he said, comprised of HTML, delivered over HTTP, with one-way hyperlinking in the form of URLs. He claimed that native apps broke this model, mainly because you couldn't link to them in any universal way. Even if an app does support a URL scheme, linking to it will only work on devices that both support the app and have it installed, whereas web sites will work anywhere (in principle).

He also strongly emphasized the fleeting nature of native apps, and the permanence of web sites. I believe he described native apps as being part of a 'flow', like a stream of disposables with no lasting benefit. Web sites, on the other, will continue to work in future browsers, and in that way contribute to the betterment of humankind in a more permanent way.

Finally, he invoked the ubiquity of the web to implore developers to reach out to a broader audience, and stop limiting their apps to particular devices or operating systems. Developing in HTML, according to Keith, means anyone can utilize and benefit from your app. How could that be a bad thing?

On the face of it, the arguments seem reasonable enough, and it is easy to see why you would struggle to counter them if you were put on the spot, with no forewarning, in front of several hundred onlookers. But the arguments are unquestionably flawed, and conveniently fail to acknowledge many realities of mobile software development.

Probably the biggest hole in Keith's argument is that it artificially partitions web and native apps. By claiming that HTML is integral to the web, he is attempting to segregate native apps, isolating them from the web, when anyone who uses native mobile apps knows that many, even most, are closely coupled to the web. In fact, I would argue that most native apps are 'web apps', despite the fact that they don't use HTML.

In fact, it is wrong to view HTML and the web browser as anything more or less than the most successful cross-platform development environment that we have. A virtual machine, like Java's JVM or Adobe's Flash, it runs on every device, and — in the same vain as the JVM — offers the same lowest common-denominator user experience on all devices. HTML, together with JavaScript and CSS, has become little more than a presentation technology. It only differs from other solutions in its ubiquity, and non-proprietary nature. These factors are important, but should not be confused with any technical advantage.

The permanence of web sites is also highly questionable. Most web sites undergo regular design changes, the equivalent of a native app getting an update. In this respect, the two are equally fleeting: the HTML of a site is as likely to change as the controls in an app. Both are in constant flux, and if neglected, will become less useful and may eventually fail to work at all. How many unmaintained web sites do you visit regularly? It's a nice thought that web sites could theoretically survive in perpetuity, but in practice it doesn't happen, and even if it did, would not have any great benefit, other than perhaps for historians.

In any case, what you want to survive forever is not the visual presentation of the web site, but the content it contains, and this is completely independent of the presentation medium used on the device. A well designed web service is many times more useful than a web page. The content is well structured, and can just as easily be presented in a web page as passed to a native app. The data can also link to other resources, whether they be web pages or apps.

To finish off, I want to address the idea that as developers we should be aiming to reach as wide an audience as possible. This is not my own objective, nor the objective of many other developers. Personally, I want to develop the best user experience for my customers that I can. I forego a broader audience to build a better product for fewer users.

Keith would claim that I am doing a disservice to mankind, but that is not the case. I will develop the best app that I can for iOS users; my counterpart on Android will do the same; together we will deliver a high-quality experience tailored to our respective audiences. This scenario is far superior to each developing poorer-quality web apps in an effort to reach as broad an audience as possible. Two wrongs don't make a right. (And, yes, web apps are by their very nature unoptimized for the native platform, and thereby offer a 'poorer' experience.)

This whole discussion is to some degree moot, because the people have already spoken. It may be tempting to suggest that the App Store was a ruse forced upon us by Apple, but the truth is actually completely the opposite: Apple did not want to allow native apps on the iPhone, and was pushed into it by the overwhelming strength of the jailbreak community. People wanted the better user experience provided by native apps, and if Apple wouldn't allow it, they would do it themselves. In a pinch, a browser will do, but it will never supplant native apps, and why should it?

Want to comment? Head on over to our Tender site

Mental Case 2.0 Progress Report

Tue, 11 Jan 2011 09:33:47 +0100

Some of you have been waiting a long time for Mental Case 2.0. No doubt you expect it is vaporware by now, but we are here to tell you that it exists, and now dominates our focus. While we can’t give a definitive date for release, it is safe to say that if it were to come out after the summer, we would be very disappointed. It’s a question of months, not years.

We thought we would release a few details, to help you understand why it is taking so long, but also so that you have something to look forward to. It is worth pointing out that if you purchase Mental Case on the Mac App Store now, Mental Case 2.0 will be a free upgrade. Mental Case 2.0 will only be available via the Mac App Store, and will require Mac OS X 10.6 or later.

We have rewritten Mental Case 2.0 from scratch. Only small parts of Mental Case 1.x have been incorporated. We wanted to take what we had learned from users over the last four years, and make a more rounded, and hopefully much better designed application.

Mental Case 2.0 incorporates many of the most requested features. Notes can be manually ordered, and can appear in multiple cases. There are tags, flagging of notes, and smart cases. You can have formatted text in notes (eg color, font, font size, bold, italic), and in Mental Case 2.0 there is no limit to the number of sides on a note.

You can still include an image, text, and audio on one ‘side’, but we now also have support for video. All data is stored in a more scalable way, similar to how iTunes does it, with media files stored separate to the main database.

The study options in Mental Case 2 have not yet been developed, but the plan is that there will be more modes of study. Not just long-term memory retention, but scheduling to target a particular date, such as an examination, and other variations. In the longer term, scheduling should be the same across all devices.

In Mental Case 2.0, you have much more control over the appearance of slideshows. You can set text size and color, as well as background color. You can also resize the slides any way you like, and run slideshows in windowed mode, or in full screen mode. There will also be a navigation strip for jumping around in your slides. Overall, it is much more flexible.

Initially, we intend only to update the Mac app. It is too much work to update the iOS apps at the same time — it would mean Mac users would have to wait too long. So the Mac app will be released, and after that, we will overhaul the iOS versions to introduce some of the same improvements. In the meantime, you will be able to keep syncing notes to iOS, but with some restrictions, such as only two sides will appear on the touch device.

So we are working on it. And in the meantime, consider saving yourself a few bob by heading over to the Mac App Store and purchasing the current version of Mental Case for Mac OS X. (On the day of publication, there is a one-week half price migration sale beginning.) That way, when Mental Case 2.0 does arrive, you will be first in line, and won’t have to pay a thing.

Want to comment? Head on over to our Tender site

Mac’s Law of App Store Pricing

Sun, 2 Jan 2011 14:51:38 +0100

The Mac App Store (MAS) is just around the corner. Time to get in last minute predictions.

One topic that is on every developer's mind is how the MAS will affect app pricing. I predicted in an earlier post that the sweet spot for Mac apps will be about $20. I'm still hoping this will be the case, but at the same time I have noticed that there seems to be a relationship between the average price of apps in the App Store, and the entry level price of the device they are built to run on. It is quite a simple relationship at that.

Mac's Law of App Store Pricing
Cost of entry level device / 100 = average app price

The entry level device for iPhone format devices is the iPod touch, at around $200, giving an average app price of $2. Although the evidence is completely anecdotal, that sounds about right for the average price of an iPhone app. You could say it is the price people would expect to pay for an app.

What about the iPad? Entry price is $499, giving an app price of $4.99. Again, that seems on the money. There are a hell of a lot of iPad apps around that price.

The bad news for Mac developers, including yours truly, is that if this 'law' holds for the Mac App Store, with full entry level Macs starting at $999, Mac apps might be expected to come in at around $10 on average. (I've ignored the Mac mini because it is not a complete system.) That's quite a bit lower than what many Mac developers would be hoping.

Does that mean all existing software must drop to $9.99 to compete? I don't think so. Some may, depending on the market served, but I think most existing developers will play the same game that OmniGroup have played with their iOS app store offerings, charging a premium price for a premium product. I see no reason why this strategy would not work, seen as OmniGroup seem to have profited by it.

So if existing developers won't drop their prices to $10, who will? I think there will be a new breed of Mac app developers migrating from iOS. This type of developer is exemplified by the developers of Reeder, a very popular RSS feed reader for iOS. They are in the last stages of beta testing their new Mac app. What's the bet it comes in at about $9.99?

Want to comment? Visit our Tender

LINES OF CODE IN C SOFTWARE

Wed, 15 Dec 2010 10:47:09 +0100

A post on the Zennaware blog has ignited quite a discussion between developers on Twitter about the merit of the lines-of-code (LOC) metric for measuring code quality.

Zennaware develop Cornerstone, one of the best Subversion clients around. I used Cornerstone for several years, and if I were still using Subversion, probably still would be. It is a very capable and well designed app for Mac OS X.

The Zennaware post itself seems to be born out of a desire to defend their pricing of $59. Personally, I don’t think they need to do that. Quite aside from the fact that it is a pro tool, and $59 is not unreasonable, they have a right to charge anything they like and let the market decide.

But whether the post is necessary or not, it does bring up some interesting facts. The Cornerstone source code is apparently 180k lines, excluding whitespace, comments, and third party code. When I read that, it surprised me. As good as Cornerstone is, I found it difficult to imagine that an app of that kind would require 180k LOCs. My impression was that a codebase that big may not be adhering to the Don’t-Repeat-Yourself (DRY) principle, ie, may not be designed that well internally. (There is no question that the app’s user interface is very well designed.)

Several people, including Uli Kusterer, pointed out that LOCs are not a good measure of the size of a C code base. Whether you put your braces on a separate line, or spread out your method calls, could make a big difference to the number.

I found this an interesting question quite aside from the whole Cornerstone issue: How much do LOCs vary for algorithmically-equivalent code under different coding styles? So I did a test: I took a 1000 line piece of my code. I altered it to be as contracted as reasonable, putting method calls on one line, avoiding local variables, moving opening braces to the ends of lines, and things like that. I then made a second copy, spreading things out as much as I thought was reasonable: braces on separate lines; lots of local variables for intermediate results; method calls over multiple lines; that sort of thing.

And the results? Spread out code came to 798 LOCs (excluding empty lines and comments). Contracted code came to 604 LOCs. So contracted is around 25% less than spread out. That is more than I had expected. It still doesn’t make the 180k of Cornerstone seem compact — even assuming they have a spread-out code base, it would only drop to 140k or so with a contracted style — but it is a useful rule-of-thumb when considering the LOC metric in C-based code.

Want to comment? Go to our Tender.

Why Wait to Go 'Back to the Mac'?

Sat, 20 Nov 2010 14:36:26 +0100

When Apple developed iOS, they had the luxury of starting from scratch, something which is quite rare in the world of software development. And for the most part, they have made good decisions in the design of UIKit, the user interface framework of iOS. Though arguably less powerful than the Mac’s AppKit framework, it is much easier to use in the most common situations, and that makes a big difference to a developer’s mental well being.

Apple have already promised to bring back parts of iOS in Mac OS X Lion, but how it plans to do that is not yet clear. Will UIKit be ported in its entirety, such as I postulated recently, or will they cherry pick bits for inclusion in AppKit? We’ll probably need to wait a few months to find out for sure.

That doesn’t mean iOS doesn’t already have something to offer the Mac developer. I am currently hard at work on Mental Case 2.0, a major revision to our flagship Mac app, and many aspects of the app’s design have been inspired by UIKit. For example, view controllers are used throughout, and navigation controllers are used to control the view stack in some parts of the UI. These design patterns are derived directly from UIKit.

A post on the Cocoa with Love blog lists twelve aspects of UIKit which are ripe to bring ‘Back to the Mac’. This has inspired me to open source a couple of classes which I have developed for Mental Case, and which were inspired by my experience on iOS. The code includes

• An NSImage category that allows you to create ‘stretchable’ images
• An editable WebView that looks and behaves like a NSTextField

The latter does not have a direct counterpart on iOS, though Apple do implement UITextField with a web view behind the scenes. Having a WebView-based text field on the Mac can be useful if it is more convenient for your application to represented formatted text with HTML, rather than the NSAttributedString class. An example of where HTML would be preferred is when you have to exchange formatted text with iOS: although iOS now has the NSAttributedString class, the attributes on the two platforms are not compatible. HTML works on both.

The classes are included in a simple project, and should be self explanatory. To instantiate the web view, you should use a Custom View in Interface Builder, so that the designated constructor initWithFrame: gets called. You can get and set the HTML content using the htmlString property. There is also a textFieldDelegate which can receive notifications of changes to content and editing state.

You can make stretchable images in much the same way you make them on iOS: take an existing NSImage, and invoke the factory method

-(NSImage *)stretchableImageWithLeftCapWidth:(CGFloat)leftCapWidth topCapHeight:(CGFloat)topCapHeight;

You then call drawInRect: to render the image in ‘stretched’ format. In the example project, a stretchable image is used in a custom view class to draw the background. As an added bonus, this background view class is centered in its superview, and snaps to the left and top margins if the superview becomes smaller than the background.

You can download the code here. (Update: The source code is now also on github.) It assumes garbage collection is used throughout, and is released under the new BSD license.

To comment, visit our Tender.

Tap. Swipe. Pan. Pinch.

Wed, 10 Nov 2010 10:09:59 +0100

Apple’s ‘Back to the Mac’ presentation has caused an enormous amount of discussion amongst software developers about what it all means, and where they are headed. I’ve already presented my views on what the Mac App Store means for existing Mac software, but just as big a question is what it means for iOS developers. For now, iOS developers are faced with learning a whole new legacy framework — AppKit — if they want to port their software to the Mac. There may be some brave soles who dare, but I think many will be put off by this prospect. So what are Apple’s plans for luring iOS developers to the platform?

Why Now?
One thing that bothers me about the Mac App Store is the timing. Technically, there isn’t much new in the store over and above the iOS App Store. Apple could have done this a year or two ago. Alternatively, they could have waited for the introduction of Mac OS X Lion next year. They could have used it as a feature to get people to pay for the upgrade. As it is, they are introducing the store in January for Snow Leopard, and that doesn’t sit right.

So what are they up to? My theory is that the Mac App Store will involve a two-stage rollout. We have only been given a glimpse of the first stage, which includes existing Mac software titles, and the few iOS apps ported to AppKit. The second stage would come with the release of Lion, when iOS apps will be allowed into the Mac App Store. The scenario goes something like this

✓ Apple introduce Mac App Store in January 2011, and add existing Mac apps
✓ They release the first beta of Lion, either at WWDC in June or earlier
✓ With the Lion release comes the knowledge that UIKit is supported
✓ iOS developers have 3 months or so to get their apps ‘Mac-compliant’
✓ Apple starts to accept iOS apps for the Mac App Store at WWDC or shortly thereafter
✓ Lion comes out in Spring, and iOS apps start appearing in the Mac App Store

With this in mind, the early launch of the Mac App Store makes much more sense. Apple don’t want to be inundated with all existing Mac and iOS apps at exactly the same time. It would overwhelm their app reviewers. So they get the Mac apps out of the way early, and leave the iOS apps for Lion.

This could also explain why no Lion beta has been forthcoming. Apple usually release betas of their operating system more than a year in advance. Usually developers hear about the upcoming release at two consecutive WWDCs. Not this time. Seems like they will hold it back until the last minute. Why? Most likely because it has things in it that they can’t release at this time, like, say, UIKit.

iOS Apps are the New Widgets
Remember when Apple introduced iPhone, and told developers that they should develop apps with HTML? The idea was that the 3rd party app scene would be just like the Dashboard app scene — iPhone would become a portable Dashboard.

As we now know, it didn’t really work out that way. A completely different system — native apps with app store delivery — won the day in a big way. The iPhone did become that portable Dashboard, but not in the way originally anticipated. And so it is today. Most Mac users rarely visit Dashboard anymore; instead, they pull out their iPhone when they need widget-like functionality.

What if you didn’t have to pull out your iPhone to access those same apps? Dashboard has become a backwater, but what if it could run iOS apps? Immediately, you have access to 250k great widgets, the same ones you use on your iPhone or iPad. Twitter for iPad on your Mac? You bet. Reeder as your RSS viewer? Why not? Sometimes the best apps on any platform are on iOS.

One of the strongest arguments I have heard against this happening is that iOS apps have a different look-and-feel to the Mac, and a different interaction model. I’ll leave interaction for later, but let’s take the look-and-feel issue. The argument usually goes like this: “Have you ever used VMWare? The windows look awful when on a Mac desktop. They just don’t fit. The same would be true of iOS apps. Apple would never do that. Way too ugly.”

Absolutely right — Apple wouldn’t do that. We know that, because Dashboard provides the perfect reference point for what Apple would do. Dashboard widgets don’t fit well with the look-and-feel of the Mac multi-window environment. That’s why Apple put them behind a partition, in their own space. With a modal environment like Dashboard, it doesn’t feel ‘wrong’ when the widgets don’t fit with existing interface styles.

And that is exactly what I think will happen with iOS apps running on the Mac. They will only run in full screen mode, separate from the multi-window Mac space. And because they will run in a separate mode, it won’t grate that they don’t look anything like existing Mac apps. Apple know this from their experience with Dashboard. The prominence of full-screen mode in Lion can’t just be for existing Mac apps, which can already drop into full-screen mode with ease.

Touchy Feely
Now let’s turn to the question of the different interaction paradigms used for iOS devices and the Mac, which is perhaps an even more important objection. The Mac uses a legacy, mouse-driven interface, and the iOS devices use multitouch. Judging by the reactions I got on Twitter, many see these two as irreconcilable.

The fact is, Apple has been busy reconciling these paradigms for several years now. Wasn’t it strange that they added multitouch support to a mouse, and then added a multitouch trackpad for desktop Macs? These devices are quite underutilized at this point in time. Most people use a gesture to scroll, but they could already do that with a scroll wheel. I guarantee very few are rotating photos with their multitouch mouse. So why bother introducing these devices at all?

In my view, Apple is preparing their hardware for apps from iOS. Using iOS apps on a Mac with a traditional single-button mouse is not a great user experience. Any developer who works with the iPhone or iPad simulator can attest to this. It’s doable, but not fun. Even simple things like scrolling feel unnatural with a traditional mouse.

Enter the multitouch mouse. If you could use multitouch gestures in the iPhone simulator, it would be a whole different story. Tapping, scrolling, pinch zooming, panning...all are not only possible, but also quite natural, with a multitouch mouse. What’s more, these gestures are already in use today by millions of Mac users.

In other words, you don’t have to re-learn how to scroll an iOS app with a mouse, because you already do it in your Mac apps. The gesture for scrolling on the Mac is different to the one used on iOS — to scroll down, you drag your finger downwards on the Mac and upwards on iOS — but users are already comfortable with this distinction. It doesn’t confuse anyone. The population has already been indoctrinated.

The Gesture Abstraction
The key to all of this is that Apple have started to move the emphasis away from low-level event handling to high-level, abstract gesture handling. UIGestureRecognizer is a class that Apple added in iOS 3.2. Its subclasses represent multitouch gestures such as tapping, pinching, panning, and swiping. With these basic gestures, you probably cover the needs of 95% of all apps on the platform.

The importance of this abstraction should not be underestimated. If a developer uses gesture recognizers, she doesn’t need to deal with the low-level differences in event handling that arise between operating systems. A pinch gesture on iOS involves two fingers moving toward a centroid. The same gesture on the Mac could be represented by two fingers moving together, with the location of the mouse pointer playing the role of centroid. The event model is completely different, but the two can be readily mapped to the same abstraction, a pinch gesture.

My guess is that Apple will simply advise developers to use gesture recognizers wherever possible in order to port their iOS apps to the Mac. Classes like UIScrollView will automatically interpret the gestures differently on the Mac and iOS platforms to give the expected behavior.

Of course, not all iOS apps will readily translate to the Mac. Some really are married to the multitouch paradigm, and would feel clunky on the Mac. But these apps are in the minority. Most iOS apps use standard gestures, with tap being by far the most common. These apps would need very little adjustment to work on the Mac with a multitouch mouse.

Retro Platform Wars
This is where it all gets a little hairy and far fetched, but I’m going to throw this out there anyway. The overriding question in all of this discussion is “What are Apple’s intentions for the Mac?”. Will it remain a standalone platform, or will it be merged in some way with iOS? Does it have a future in the consumer space at all, or will it be supplanted by iPad and other touch devices?

In my view, Apple’s agenda for the Mac is starting to become clearer, and it may surprise many to hear that I think they are targeting Microsoft. I know, I know, I don’t live in a box, that war was fought years ago, but by targeting a particular segment of Microsoft’s market, Apple have found a way to continue to grow the Mac business even when the PC business itself is in gradual decline.

Apple has something like 20-25% of the US consumer PC market. That’s pretty good, but wouldn’t it be better if that were 50% or 70%? The Mac App Store is Apple’s play for dramatically increased market share. If the Mac runs several hundred thousand cool iOS apps, it will attract consumer PC users to buy Macs in the droves. Apple want to dominate the consumer PC market.

They’ll leave the enterprise market to Microsoft. The demise of the Xserve just confirms that Apple is no longer interested in competing in this space. They just want to dominate every consumer market on Earth, starting with the one that slipped through their fingers in 1984.

Pad’l Boat: iPad in the Bath

Thu, 4 Nov 2010 20:16:41 +0100

I've got a nasty habit: I regularly take a hot bath ... with my iPad. Most people think I'm crazy, but I've been doing it since day 1, and I was doing it with my Kindle for a year before that. I've never had a mishap or even had any fear that the iPad would be damaged.

The secret, of course, is not to bath naked, or at least not to make the iPad bath naked. There is at least one waterproof bag on the market specially designed for the iPad, but I just use standard zip-seal freezer bags from the supermarket. The purpose of the bag is really only to keep your wet fingers off the device, and hopefully keep water out should you accidentally drop it, something which I have never had happen. (When I first tried the freezer bags, I was very surprised to find that the touch screen works perfectly well through the plastic.)

With a watertight bag, you're most of the way there, but recently I've been experiencing another problem: The iPad is small compared to a laptop, but damned if it doesn't get heavy when you're holding it in your hands, and not resting it on anything. (Any lewd suggestions for things to rest it on will be resolutely ignored.)

I thought about a stand or swinging arm, but these solutions seemed difficult to implement, and would probably get in the way of a relaxing bath. Eventually I decided upon a boat. With a few plastic microwave containers and some gaffer tape, I came up with a raft that would make the cast of Lost proud. Meet Pad'l Boat.

It floats like a middle-aged Kevin Costner, and is stable to boot. During my first test flight, I didn't have any fear that it would capsize, though typing is a bit troublesome when every tap pushes your screen a half inch closer to the taps at the other end of the bath.

It's not all rosy though. The gaffer tape was not terribly water-resistant and has already started coming off. I'm already thinking about Pad'l Boat 2, and this time, I think I'll go with fiberglass.

Selling Software in the Mac App Store

Sat, 23 Oct 2010 19:45:47 +0200

Apple's Back to the Mac event last week has left developers with a lot to think about. Mac OS and iOS are clearly on a course to convergence in Lion and beyond, and even more pressing —given that it is due to appear on desktops within 3 months — is the Mac App Store.

Many have been anticipating the Mac App Store for a while, so it isn't really a big surprise, but it does raise a lot of issues for developers, some of whom have made their crust on the Mac for many years, and are used to selling their products in a particular way. There is no question that the Mac App Store will change the way desktop software is sold, but in what ways, and what can developers expect in the transition?

I have given this a lot of thought over the past few days, and have formulated some opinions. I want to present them here, with a morsel or two of salt, and hopefully fuel some discussion.

Apple haven't played their hand completely yet. Many aspects of the store agreement Mac developers will have to sign up to are unknown, and will probably only become clear when submissions open in November.

This hasn't stopped some developers starting to formulate their approach to the store. Some have expressed a hope that Apple will allow for paid upgrades. Many indie developers currently rely on costumers to pay for regular upgrades to make ends meet.

I very much doubt Apple will support this. They have shown no intention of doing so on iOS, and it goes against the simplicity of purchase upon which the App Store is based. I don't think they want the complexity of paid upgrades, for themselves, or for customers. Apple don't have paid upgrades for their own software either, which shows where they stand on the issue.

(I do think we will eventually get all of the options available to iOS developers, including in-app purchase and iAds, but probably not in the first iteration.)

The model generally used to sell desktop software today is to offer potential customers a free time-limited demo. Apple do not support this model for iOS, though they do allow developers to release less-capable (crippled) iOS apps.

Expect to see this policy in the Mac App Store too. Apple don't want to have to deal with irate customers annoyed that an app stopped working and has locked down their data. It isn't going to happen, which means Mac developers are going to have to make changes to the way they sell their products if they want to be listed in the App Store. I'll come back to what I think those changes will be.

I have seen quite a few tweets from well-known Mac developers suggesting they will continue to offer their software in the traditional way, in addition to offering it through the Mac App Store. Most seem to have assumed this will be allowed, but I haven't seen any evidence to that effect. Steve Jobs did say that you will be able to keep selling software outside the App Store, but he didn't say you could do both.

I expect Apple to make developers chose one or the other. The confusion to customers, and accompanying support requests, resulting from having the same software sold under two completely different sets of terms will not appeal to Apple. Neither would it appeal to them to have to compete with other sales outlets that offer cheap upgrades. Expect to see Apple require exclusivity.

This could also put a dampener on the plans of some to offer free demos outside the store. Not only does this go against the whole one-click philosophy of the App Store, it could also lead to customer confusion, as they end up with two different versions of the app. I don't think Apple will find this scenario appealing, and I think it will take a stink from developers to get them to allow it.

All of this has been building to the big question on every developer’s mind: How much should I charge for my app? The issues above — no demos and no paid upgrades — together with the no refund policy of the store, mean that the typical $40 price tag on Mac consumer software is probably going to have to drop some.

But there is an even more important reason I think prices will need to drop: The whole reason we have been waiting in baited breath for a Mac App Store is that a large portion of Mac users, think 90%, have never bought any independently developed software. They either don't know it exists, or don't trust it. The Mac App Store promises to put apps right under the customer's collective nose, in a fenced garden where you never need enter your credit card number. It happened on iOS, and now it will happen on the Mac.

The pool of customers will rise immensely, and the new blood will not be your grandfather's indie software customer. Today, people who buy software are often developers themselves, or fall under the category of 'power user'. The Mac App Store will bring a whole new type of user, one who has never paid $40 for an app. To reach this group, I expect that prices will have to drop somewhat.

Judging by the heated reactions I have received on Twitter, this is not a scenario that many developers are willing to entertain. They are determined to uphold their current pricing structure, and approach to selling. They are missing the transition, and think they are still in Kansas.

So what should software cost in the Mac App Store? Well, as always it depends on the app, but let's assume a typical consumer app sells for $40 now. With no trial demo, no refunds, no upgrade pricing, reduced support costs, and a customer history of purchasing apps from the iOS App Store, I'm thinking about $20. You could charge more, but I suspect you will miss the stream of potential new customers that the App Store will bring.

Another way to estimate the 'right' price is to look at the prices for iOS devices. iPhone software typically comes in under $5. iPad apps are priced higher, in the $5-10 range. The Mac should be higher again, but a jump to $40 seems excessive. The $10-30 range feels about right for most apps. There will always be outliers, just as there are on iOS, but I think this is where most apps will end up, and — more importantly — be most profitable.

Many developers seem determined to maintain current pricing because they fear a race to the bottom like the one that took place in the iOS App Store. I don't think that will happen in the Mac App Store. There simply will not be the excessive supply of apps that are available on the iPhone.

Although I expect a few apps to be migrated back to the Mac from iOS, I don't expect a rush. Developing Mac apps is frankly much more difficult and time consuming than developing iOS apps, and with a smaller market, I doubt many iOS developers will be tempted.

Want to comment? Join the discussion on our Tender.