This week, News Corp announced that The Daily – the world’s first iPad-only newspaper – will shut down after less than 2 years and this has sparked a big debate on why The Daily failed and, more in general, why magazine apps suck.
Beyond the specific case, most existing iPad magazine apps suck because they offer essentially static content, they suck because they are far away from being interactive. Creating interactivity does not mean embedding some multimedia “bells and whistles”.
Most magazine apps suck because they are basically heavy PDFs with just some interactive elements. Almost all the solutions in the market are PDF-based systems such as Adobe’s DPS (clearly) or Mag+. The reasons are obvious. Publishing world is PDF-centric, people know how to use InDesign, and publishers want to reuse the knowledge and the investment done. So the solution is to create interactive PDF files with InDesign (adding some Flash-like interactivity on the top of the standard format) and to pay for a service that packages them into a bundle suited for distribution through iPad (or to pay for a commercial library for PDF-rendering). Understandable budget reasons (I, too, have developed an app of this category). But in this world a magazine app is a PDF reader.
Another digital publishing world is possible. And just to be clear, not a HTML5-based world where a magazine app is a browser. A magazine app makes sense if it’s a true native app, if it adds value to the user experience in terms of usability and functionality, takes advantage of the capabilities of the device, and makes a clean break from the incumbents.
Many have commented that The Magazine is the model to follow, and it is evident. Everything becomes immediately obvious when you see it. It is certainly the best example of how to distribute publications via Apple’s Newsstand, it is intuitive and immediate, but memorable editorials can not be the only lever to succeed in all situations. When I think of an iPad magazine app, I think of something like an iBook textbook, or an interactive children’s storybook, for magazine publishing. Truly interactive publications with diagrams that readers can rotate and pan-and-zoom, with photo galleries, videos, maps. A magazine should bring articles to life. Readers should be able to truly interact with the magazine, manipulate objects with their fingertips, search for content, highlight text. Magazines should take advantage of the fact that they are always connected to the web, for example with newspaper-specific modules that support polls, comments, photo sharing.
Science fiction? I don’t think so. I wouldn’t be surprised if Apple releases a sort of Newsstand Author. Or allowing the download of XIBs? Or what? Well. When I think of this, I don’t think ad hoc iOS apps, but a framework in which an issue is a bundle of resource files and metadata and the app is a sort of runtime environment that dynamically renders magazine issues delivered via Newsstand. XUL? XAML? Something like that. But there is no need to define a new protocol, the rendering instructions can be expressed in HTML (or its subset). In this way you can have truly native experiences, but also issues easy to produce, and portability. Time to start-up?
What do you think about it? Any opinion or feedback from you are welcome.
Without entering into the controversy on “native vs cross-platform”, you cannot not be interested in building mobile apps with a true native user experience, deploying them to multiple operating systems and managing them from a single code base and a single investment. I am, and I used the Titanium Mobile SDK for a few months working on a few prototype ideas and for a real project (Infostud Mobile).
Here are the main pros and cons based on my experience:
Rapid prototyping. Appcelerator’s Titanium actually “accelerate” the application development because allows you to create in a very flexible way, with a few lines of code and in a few hours what normally would require more attention and a few days. Regardless of the choice of developing by using native or cross-platform toolkits, you could always use Titanium to make a prototype to evaluate the user’s interaction with the UI due to its facilitation for rapid development.
Web-oriented. Titanium mainly helps the development when the app interacts with a web service since the application itself is developed by using web technologies. This had a great impact not only on simplifying the development process, but also on saving the overhead needed to elaborate the information exchanged through the remote communication.
Cross-platform. This is not an automatic, guaranteed feature. You cannot say something like “write once, run on iOS and Android” (to paraphrase provocatively the well-know Java slogan). It’s therefore necessary to base the development of one of the two platforms and then implement the necessary measures to make the app also runs on the other one. But the advantages are obvious – you don’t have to learn two separate languages and you can reach a very high level of code reusability.
Growing community. Appcelerator has built up a community of 200,000+ developers who have used its cross-platform development tool to build more than 35,000 apps; has launched Open Mobile Marketplace for buying, selling and sharing modules, templates, design elements, extensions for web services; has attracted important investments ($15 million in funding for its Series C round) and has recently acquired Cocoafish to implement cloud services and functionality in its platform. Remarkable. Appcelerator is creating a great platform for a growing community and its best days are ahead of it.
Increasing complexity. The development complexities (and costs) rise more than proportionally to application complexity increases. The more complex your applications become, the more often you’ll have to deal with, on the one hand technical issues (random crashes, weird behaviors, annoying bugs, etc.), on the other hand a greater effort (code organization, MVC separation, multi-device support, multi-platform support, code readability, etc.).
No Freemium. Appcelerator provides StoreKit, a module to enable In-App Purchase to Apple’s App Store, but it’s a pain. Buggy, poorly documented and it seems to work only partially. Too unstable for production use. Having to renounce the freemium pricing model (apps that are free to download, but require an in-app purchase to be expanded) is not just a minor inconvenience since 72% of total App Store revenue comes from apps featuring in-app purchases.
Toolkit pain. At first there was only Titanium Developer but since last June there is Titanium Studio, an Eclipse-based IDE built on a modified version of Aptana that allows you to manage projects, test your mobile apps in the simulator or on device and automate app packaging. First of all, I sincerely hate Eclipse, yeah, Eclipse is free and the best open source IDE there is, but offers a very poor IDE experience. Most importantly Titanium Studio can go “crazy”, encounter weird glitches, stop printing console messages, but the worst thing is when the build process start to ignore changes. You have to continually clean your project every time you make changes or restart with a brand new project. A productivity tool that is uncomfortable and unstable is not a productivity tool and a development tool that is unproductive is not a development tool.
Flexibility limitations. All that glitters is not gold. At beginning you’ll love the well-defined Titanium API and you will probably love it even more every time you discover a simple property to enable behaviors that would require several lines of code on Xcode. But sooner or later you will face strange bugs and limitations. For example, if you want to apply a cell background gradient to a grouped table (a very common and easy task with Objective-C) you get that the grouped table becomes plain and the gradient color makes the table slow when scrolling, and you will have to use images… So at first you will save a lot of time but as more complex the project grows you’ll lose the saved time in fixing and workarounds.
Laggy. Obviously you can have the most smooth, fast and comfortable user experience possible only with apps developed with a native development environment. This is an obvious observation, but which cannot be omitted. Keep in mind that a Titanium application is the result of an automatic conversion process from web code to native code. Animations are noticeably laggy and apps are not responsive when return from the background. This is particularly evident with Android devices, less evident with iOS devices (especially those with A5 processor).
Just as in everything else, in every design approach, in every technological decision, there are advantages and disadvantages. During these months I have learned to know both and understand the contexts in which it makes sense to bet on Titanium. For simple, small projects Titanium is a good choice but if you’re looking forward to use it on robust apps choose native development environments. I also suggest Titanium as an excellent tool for rapid prototyping to turn within hours a mock-up into a prototype in order to evaluate the consumer interest or conduct usability tests.
However, the pros and cons must be evaluated on a case by case basis because their weight depends on the specific project that you are considering. Keys aspects to take into account are: benefits, costs, budget, development complexity, how necessary is the multi-platform support, how strategic is the project, how important is performance. You have to weigh each pro/con based on your specific priorities to determine what fits your needs the best. Appcelerator’s Titanium is a great option that should always be considered when you start a new project.
It’s a well-known story. In July 2008, Apple launches the App Store and everything really changes. An assay wouldn’t be enough to take a deeper dive into all aspects (mobile revolution / software-centric model / walled garden / user-focused experience / “right combo of empathy, vision and dictatorship”1 / …). What I want to talk about is a little consideration about mobile software development up to date.
It is fairly obvious, but should be noted that the scenario has changed. Four years ago there was a whole prairie to conquer and colonize. Once created the platform, Apple unveiled an uncontaminated new Wild West. Colonization and gold rush started.
A key point to highlight is that any developer — big, medium and small software companies, independent developers, students, nerds, spare-time developers, etc — can seek his fortune. Everyone has the same opportunities because the distribution channel is the same for all. Ironically a rigid centralized control has imposed an almost “democratic” system. Every developer can distribute his work in a way only giant companies could. Today the App Store gives them access to 150 million potential devices, 200 million iTunes credit card pool, a simple payment processing system, and all the hosting, bandwidth, transaction, delivery, reporting, and several incredibly valuable assets: marketing Apple provides, the App Store’s ease of use and its huge visibility. All included in a simple 30% fee2. But I have digressed too far.
The matter under discussion is that the scenario was a Wild West for each pioneer regardless of the resources, a Wild West without existing competitors (Indians), a brand new market with an explosive consumer demand. In this situation it does not matter HOW, but WHEN you hit the App Store. In this situation your intention matters more that the way in which you put it into practice. It was a gold rush.
Now, let’s get back to the present day. First of all, mobile software development is not a easy game. Many are convinced that the App Store is El Dorado and an app is a little more than an idea. Some success stories do not mean that everyone has become millionaires. “Some” means “a few” cases in thousands. And even when an app looks like an overnight success from the outside it always has years of working away unnoticed preceding it. Angry Birds was Rovio’s 52nd game that they made. Once there was the Plato’s doctrine of ideas, today the development doctrine of ideas. All ideas suck, because they are just ideas. They’re worth nothing. Ideas are just a multiplier of execution.
Secondly (and mainly), there is no longer a borderless prairie, but a borderless metropolis. Buildings and skyscrapers are everywhere (more than 370,000 active apps and about 80,000 unique active publishers). It’s very difficult to find a building plot. Once there was a dozen of review blogs, today tens of thousands (as a parallel business). Once there was an enthusiastic user, today an exigent user who doesn’t care to bet on you and wait until your app improves. Given the way Apple’s ranking algorithm works, the launch (first four day period) is crazy crucial, that means you’ve gotta have a big launch, which means you’ve gotta have a big build-up3.
Now it does matter HOW you hit the App Store. Now it does matter how much carefully and attention to detail you put into execution. It’s a matter of quality. Nothing happens overnight, so you need patience, competence, passion and determination to keep going4.
That’s why software companies increasingly now dominate the ‘Top 200′ lists. Mobile development is not a game. It takes time and resources. It requires different skills (from psychology to engineering). It’s a matter of quality, a matter of high-profile skills, a matter of hard work.