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.

EXPLOITING Human Imperfection in Your hUMAN INTERFACEs

Sat, 16 Oct 2010 15:19:20 +0200

In my recent bid for fitness, I've put in quite a few hours on the bike, and watched a lot of videos on my iPad to kill the time. A great source for entertaining and educational videos is the TED app, which has just appeared on the iPad, but which has been on the iPhone for some time. The talks on cognitive science — how the brain works — are particularly good.

Many of these talks allude to the fact that the brain is easily fooled with optical illusions (1, 2). In short, the brain receives an ambiguous signal from the eyes, and in order to interpret the signal, it has to make a number of assumptions based on past experience. If you generate an image that deliberately violates the assumptions of the brain, you cause it to perceive things wrongly.

The TED talks introduce a number of interesting examples, from misinterpreting colors to classic vase-or-face images, and even 3D models that send your brain in completely the wrong direction. All great fun, but it doesn't seem very useful other than as a tool for learning how the brain works.

At least, that's what I thought until last week. Understanding how to trick the brain is actually essential to anyone working with visual media. Web site designers, for example, have to know that exactly the same color on light and dark backgrounds will appear differently to an observer. They have to deliberately make the colors different to ensure that they are perceived to be the same.

I've always been taken by the picker wheel that Apple built into the iPhone for choosing dates, and anything else that is cyclic for that matter. The wheel feels like a round 3D cylinder. I used to ponder just what technologies they might be using to make the rows of information rotate in the third dimension.

Last week, I wanted to have a similar effect in one of my own projects, and I realized that the whole thing is an optical illusion — a simple trick. If you cover a standard flat table view with a gradient that begins dark at the top and bottom edges, and becomes fully transparent as you move to the middle, your eyes perceive it as if the rows in the table wrap around a cylinder (see screenshot). It is quite amazing, but even when I look closely, and know the trick, I can't convince my brain that the rows are not rotating as they approach the edges.

For the iOS developers in the audience, a simple way to do this is simply to add a CAGradientLayer on top of a standard UITableView. You can literally copy Apple's picker with less than 20 lines of code, and you don't need to go through any geometric gymnastics to do it. Here are the lines I used:

// Prepare colors
CGFloat alphaValues[] = {0.9, 0.6, 0.35, 0.2, 0.1, 0.01, 0.0, 0.01, 0.1, 0.2, 0.35, 0.6, 0.9};
NSUInteger numberOfValues = sizeof(alphaValues) / sizeof(*alphaValues);
NSMutableArray *cgColors = [NSMutableArray arrayWithCapacity:numberOfValues];
for ( NSUInteger i = 0; i < numberOfValues; ++i ) {
CGColorRef color = [[UIColor colorWithWhite:0.0 alpha:alphaValues[i]] CGColor];
[cgColors addObject:(id)color];
}

// Gradient layer
CAGradientLayer *gradientLayer = [CAGradientLayer layer];
gradientLayer.colors = cgColors;
gradientLayer.zPosition = 10.0f;
CGRect layerFrame = tableView.layer.frame;
gradientLayer.frame = layerFrame;
[self.view.layer addSublayer:gradientLayer];

The CAGradientLayer is almost opaque black at the top and bottom, and becomes quickly transparent as you move to the middle. This non-linear drop off in shade is what makes the brain think it is looking at a round object.

I put this code in the viewDidLoad: method of the view controller responsible for the table view, but you may even be able to put it in a table view subclass. I didn’t try.

HIIT for NECK BEARDs

Thu, 30 Sep 2010 09:56:52 +0200

I’ve struggled with my weight through the years as much as the next guy. I’ve dieted a few times; it usually works for a few months, then your metabolism adjusts to its more meagre intake, and you end up yoyo-ing back to your original weight or worse. Even if it does stick, you are basically stuck on the diet for the rest of your life, which few could maintain, and — let’s face it — why should you?

Quite by accident, I recently came across something that is working for me, at least for the time being. It’s not a diet, it’s a fitness regime. Before you switch off, what I like about this regime is that it takes very little time, and involves a lot of rest.

It’s called HIIT: High-Intensity Interval Training. In all honestly, I’d never heard of it, but it is a system that has been the subject of scientific research, and seems to deliver on its promises. The idea is quite simple: instead of doing continuous, low-intensity exercise, which is what most of us do, you do short bursts of high-intensity exercise, interspersed with periods of rest.

The particular technique I have adopted is called the Little Method, and was developed for a scientific study in 2009 [J Physiol 588 (Pt 6): 1011–22]. It is very straightforward: You begin and end with a few minutes warm up and cool down. The interval training itself involves 8–12 intervals of 60 seconds high-intensity, and 75 seconds rest. That’s all. Go hard for 60 seconds, rest 75 seconds, go hard 60 seconds, and so forth, for around 10 cycles. I use an exercise bike, but you can adopt any form of physical exercise you like.

In all, it takes me about 25 minutes a day, which is considerably shorter than going to the gym. One of the reasons I didn’t exercise in the past was simply that I couldn’t seem to find the time. Now I have integrated the 25 minute routine into my daily schedule, and so far it is all going to plan.

“But I already do 40 minutes a day on the exercise bike. Why would I bother with this?” I hear you say. One of the advantages of HIIT is that you get big benefits from the short time you exercise. Your metabolism increases dramatically, helping you burn fat for up to 48 hours after a session. Three 20 minute sessions a week using the Little Method was shown to be equivalent to 5 hours of standard training.

Weight loss is one advantage of a training scheme like this, but there are others. Fitness training really helps reduce stress, and I use the time I’m on the bike to watch WWDC videos. Mind and body, both.

Best of all, I haven’t changed my eating habits at all, so I can keep eating what I like, making it much more likely I will be able to sustain the regime in the longer term.

Before signing off, I found a little gem on the App Store which is perfect for this type of interval training. It’s an iPhone app call Intervals. If you are going to give HIIT a try, it’s the best $5 you can spend.