While this post is obviously motivated by Recent Events™, it’s completely not got anything to do with employers past, present or future. Dave has posted what next for Agant which explains how that company’s path through the market has gone:
Over the past few years, the App Store has become more and more competitive, and more and more risky with it. Agant’s speciality has been high-quality, higher-value apps, often published in collaboration with our clients. Typically these are paid (rather than free or freemium) apps. Unfortunately, the iOS App Store’s set-up just does not seem to support the discovery, trialling and long-term life of these kinds of high-value apps, making it difficult to justify the risk of their development.
This is not that story. This is my story. It is a different story, though I agree with the paragraph above. It’s a story that doesn’t discuss games because I really don’t know a lot about them.
Something I’ve learned from going to conferences like QCon is that outside the filter bubble of the ObjC conferences I spend a lot of time in, there’s a lot more interest in “the mobile web” (or as we should probably call it these days, “the web”) in the general IT community. This makes sense in the enterprise world: it avoids backing a single horse and tying your company’s IT to one supplier, something they’re rightfully afraid of. Companies that were in the Microsoft camp had to deal with Vista and Windows 8; companies that backed Sun are now Oracle vassals; companies that backed Apple no longer have any servers. Given that mindset, developing javascript apps makes perfect sense. Even if you deliver them now as Cordova apps for a single platform, you’ve got the ability to do something else really quickly if you need to.
This is also something that’s carried over into the world of SaaS apps, where you don’t care what UI people are looking at as long as they subscribe to your service. Whether it’s delivered as a native-wrapped JS app (which is a first-party option for Windows Phone 8 and Windows 8) or a web app (which then lets you add platforms like Chrome OS and Firefox OS), targeting JavaScript lets these developers increase their prospective customer bases from a single code base. Not, perhaps, without some rework of views for different platforms: but certainly without maintaining separate Objective-C, Java and C# projects.
While I’m talking about JavaScript, let me add another relevant datum, particularly for companies working in or with the publishing industry: another word for a bundled JS app is “iBook”.
I think there are also still reasons for having native apps.
Some people want the “most ${platform}-like” experience, and are willing to pay for that. These are, quite frankly, the people who kept Mac software houses going through the 1990s. They’re the people who demanded Cocoa versions of their Carbon apps in the 2000s. You can focus on these people, ignoring the “should be free” masses and getting to the sort of people who buy the Which iPad Format User app of the month because it was the app of the month.
People who have invested money or time into something may be willing to spend a bit in order to increase the value of that investment. This is going to cover both tradespeople and hobbyists. Look at how much you can sell golf swing software for. One of my own hobbies is astronomy: having spent around a grand on my telescope I’m not going to miss £20 dropped on an app that helps me get more value from that purchase. The trick here is not to rely on gaming the “astronomy” keyword in the app store, but to become known in that world. Magazines are more relevant than you might give them credit for, when looking at these markets. Astronomy Now, one of the UK’s astronomy mags, has a circulation of 24,000 (publishers then have an “estimated number of readers per sale” fiddle factor that’s relevant to advertising, so there might be 24-50k monthly readers). These people will read about your product, like it (if you’re doing it right) and will then go out to their user groups and meet-ups and tell those people about your product.[*]
[*] This paragraph owes a lot to Dave Addey, who referred to such audiences as broad niches.
The difficulty is that two forms of advertising no longer work: you can no longer rely on being on the app store as a way to get your app known, and similarly saying to an existing audience “hey, we’re on the app store” is also insufficient. Apps are no longer a novelty in and of themselves, so having a thing that does a thing is not a guaranteed retirement plan.
This points us to a couple of things that definitely are not reasons for having apps. Mass-market apps are now a very hard sell. They can be hard to differentiate on, hard to price reasonably and hard to generate awareness of. This awareness issue brings us into contact with the most powerful businesses in the app market: the platform vendors. No platform is going to allow a “killer app” to surface. Think back, for a moment, to the days of Visicalc. People bought Apple II computers so that they could run Visicalc. That’s fine when Visicalc is Apple-only; not so good when it gets ported to Tandy, IBM and other architectures. It’s also not good when someone else comes out with a better Visicalc for the other platform: 1-2-3 and your customers are gone. Apple (and other OEMs) want control over their customers: they’re not about to cede that control to some ISV with a good idea.
The other thing it’s not a good idea to do is to plug a gap in the OEM software. In smartphones, though not in hi-fis, printers or other electronic devices, the OEM companies are actually pretty good at executing on software features so if you’re doing “the missing ${X} for ${platform}”, as soon as it becomes at all popular the OEM vendor will fill in their version of ${X}. It might not be as featureful, it might not even be better but it’ll probably be good enough to stop the third-party ones from selling.
Notice that I haven’t said “native is better”, or “mobile web is better”. There are apps that you can only build as native apps because the technology limits you to that: this does not mean that you must build them as native apps. There’s no reason you must build them at all. Decide who you’re building for, and what you can offer them that they’d consider to be a valuable experience. Having done that, decide on the best way to build and deliver it.
There is no longer any value in having “an app for that”. There is value in a beneficial experience, which it might make sense for you to build as an app.
