This Week's Sponsor:

Copilot Money

The Apple Editor’s Choice Award App for Tracking Your Money. Start Your Free Trial Today

Posts in stories

Five

It’s easy to look back at five years of iPhone and say that it was just about technology.

Five years ago, the original iPhone launched in the United States to much hype and a slightly different world. Apple was a much smaller company; Obama wasn’t President of the United States; R.E.M. were still together. The interface design behind the iPhone was, too, a little different than the bits we touch and swipe today. Both Ars Technica and Macworld have published solid retrospectives about the past five years.

The iPhone has created an economy that’s spurring the creation of jobs and new positions all over the globe. It reignited the mobile phone industry, and, in one fell swoop, turned competitors upside down as they struggled to keep their eyes open to the new wind blowing in their direction. The App Store didn’t launch until 2008, but its numbers are the very example of the software revolution spearheaded by the iPhone.

Unlike most inventions of modern history, though, the iPhone created a culture. And that’s because – unlike the ATM or the cordless telephone – the iPhone brought people together. By allowing developers to craft software for consumers willing to pay for it, the iPhone took down the wall between creation and consumption – the virtual barrier that normally separates an inventor from people using a product.

Both sides affected by this change – developers and users – ultimately became the starting point, the goal, and the focus.

The iPhone is about the people.

Like any other company looking for a profit, Apple has always needed to make money with the iPhone. But, after five years, I like to think that there can be a good cause behind profit and industry strategies – that there can be a purpose to “make great products”. And maybe I’m wrong, but I believe the iPhone has proved to be one of those major changes that have made people’s lives better. By combining breakthrough hardware design with the human touch, iPhone didn’t just change the way people communicate, work, and play: it saved lives, improved workplaces, told stories.

Sometimes there’s more to progress than just technology.

[image credit: Flickr]

Different and Familiar

Ted Landau speculates on what might happen with the next version of OS X:

This means limiting software on Macs only to apps that come from the Mac App Store (possibly also allowing Gatekeeper-approved software from elsewhere, but I doubt it). It would also mean cutting off end-user access to the Mac’s operating system (a trend begun with Apple making the user’s Library folder invisible in Lion, but which would vastly expand in 10.9). It would mean the ejection of any third-party software that “tweaks” the operating system. Apple would also remove its own system-level utilities, such as Terminal (Apple doesn’t permit anything like Terminal on iOS devices). It is even possible that the Finder would be eliminated (as I previously considered). Finally, it would mean that the software used to develop software (e.g., Xcode) would no longer run (just like you can’t now develop software for iPads on iPads).

In his speculation about a possible OS X 10.9, Landau envisions a Mac ecosystem where Pro machines (MacBook Pro, Mac Pro) will run the “real” OS X, with consumer products (MacBook Air, iMac) left with a “simpler” version of the operating system that’s basically iOS with a keyboard and Mac apps. I think this speculation is misguided.

Apple knows that Mac users are loyal to the platform because it is different from iOS devices. Mac hardware revenue may not be at the same level of iPhones and iPads, but in the last quarter, it still represented 13% of the company’s revenue with 4 million Macs sold. Not to mention that, as Tim Cook himself has noted on several occasions, the “halo effect” has helped Apple transition iPhone and iPad users interested in a similar, yet different platform to the OS X ecosystem.

The key is familiarity. By refining the feature set and enabling new functionalities across Mac and iOS devices, Apple is ensuring an iPhone user can have a basic understanding of a MacBook Air, and vice versa. “iOS-ification”, as this process has been called for convenience numerous times in the past, has really turned into the simple strategy of allowing familiar features to act the same across devices, while leveraging the differences of each device to make it intuitive and easy to use. Notification Center works the same on iOS 6 and Mountain Lion, yet on the Mac, you get support for Hot Corners. Familiar, but also unique.

If users wanted an iPad with a keyboard – because that’s effectively what Landau is proposing – they’d get an iPad with a keyboard. The problem is, this possible scenario has already been addressed by Apple: at the Q2 2012 conference call, Tim Cook famously noted how some would like to converge a toaster and a refrigerator – with unpleasant results for the users. People have different requirements: millions of customers decide to buy a Mac every quarter, and it’s very likely that the majority of them already owns an iPhone or iPad. They know the differences, but they also appreciate the familiarity.

This speculation is reminiscent of old rumors about a “simpler” iPhone nano – a mythical device capable of running a slimmed-down version of iOS. Why would Apple want to separate OS X into two products when, by default, the OS retains many of the “simple touches” of iOS? The Mac’s greatest strength is customization – Apple puts a Launchpad in your Dock, but you can explore the contents of your filesystem with the Terminal if you want. Putting functionalities on the same level no matter the device you’re using hasn’t impacted the nature of the Mac in a way that has turned OS X into a completely different product. If anything, it made the Mac better.

Apple already makes a separate version of OS X, and it’s called OS X Server. That is an entirely different take on the operating system, with features that wouldn’t appeal to the average consumer (or even professional). But does its existence somewhat justify the theory of new OS X Consumer product?

To paraphrase Craig Federighi, OS X makes it easier than ever to work with the devices we already have in our lives. And that has been possible thanks to an effort to turn the Mac’s nature into a more comfortable and familiar habitat for users interested in a different kind of experience. Landau thinks OS X “Professional” would come without any restriction (“restrictions” can already be disabled in Lion and Mountain Lion) and even drop some “iOS-related features”. How would that help the ecosystem? And why do we keep thinking of “professional users” as weird-looking programmers who don’t like anything Apple has brought to OS X – even going as far as suggesting features should be dropped?

Professional users enjoy the improvements made to OS X as much as the 99% does. I believe that features like Notification Center and Power Nap are additions that will unarguably make OS X easier and more powerful (and they are both iOS-inspired). How would pro users react to an unarguably worse Mac without those great functionalities?

OS X won’t magically become more “professional” by excluding features and familiar elements. The way I see it – and judging from recent statements and keynotes, the way Apple sees it, too – Apple simply needs to keep making OS X a better product by refining patterns and interactions based on decades of computing with today’s technologies and trends in mind. That might mean a Library hidden by default, or a different file save dialog box that makes iCloud front and center in Mountain Lion. There have been bumps on the road (Sandboxing criticism; iCloud issues), but I’d argue that both Lion and Mountain Lion haven’t taken anything away from the pro user, for as much as many have been crying wolf in regards to filesystem access and the Mac App Store (case in point: Gatekeeper is coming to OS X 10.8).

Apple will bring more iOS-inspired features to OS X. Or perhaps they will add OS X functionalities to iOS. The point is, in doing so, I have no doubt Apple will consider the unique traits of each platform, and they will develop the features accordingly. But splitting OS X in two just for the sake of easy profits (“It’s an iPad laptop!”) sounds like a step backwards and one towards fragmentation. Furthermore, we shouldn’t associate Apple’s delay with a “real” update for the Mac Pro line with the future of OS X.

Ultimately, the goal isn’t to forcibly transition every iOS user to the Mac as part of an evil plan blindly based on “money”. It’s to provide a great ecosystem of products that keeps users happy, and Apple profitable. And in a solid ecosystem, differences aren’t seen as disadvantages: they are core strengths if they can work better together.

Why Upgrade Pricing Isn’t Coming To The App Store

The 2012 WWDC keynote has come and gone, and we now know which of the many rumored announcements turned out to be true and which turned out to be false. But there was one unrumored announcement many developers were hoping would be true that failed to materialize altogether: the option to offer paid upgrades and true demo versions for their apps.

Demos and paid upgrades are something that App Store developers (where “App Store” encompasses both iOS and Mac) have long since wanted, as Wil Shipley explained in his blog post “The Mac App Store Needs Paid Upgrades” and as John Gruber and Cabel Sasser discussed on episode 5 of The Talk Show. No doubt there are many Apple users, especially longstanding Mac fans, who would be happy for the opportunity to support their favorite developers and be rewarded with lower prices for new versions of their favorite apps as well (the “99¢ IS TOO EXPENSIVE” crowd need not apply). As Shipley’s post lays out, it would seem there are many good reasons for Apple to implement these. So why haven’t they?

I think it comes down to one of Apple’s core values: simplicity.

The fact that Apple chose to name their online retail presence the “App Store” is, I think, telling. Remember that Apple aims squarely for the mass market (much to the consternation of some advanced and pro users) and remember what shopping at a real life store is like for that market.

When most people go to a store, they don’t expect to take home products that catch their eye and try them out for a limited time. They don’t expect to get reduced prices on the latest version of a product they’ve paid for before. The retail model of a typical store from a consumer’s point of view is simple. You walk in, look for something you want, pay for it, and walk out. This is exactly how Apple’s physical stores work, and it is how their digital stores are designed to work as well.

Whether this is the way digital stores should work is another discussion, and one that is certainly well worth having. But if we assume that this is how Apple wants their stores to work, their policies for not allowing demos and upgrades make sense. In Apple’s physical stores, and indeed nearly all retail establishments, take-home trials and upgrade pricing is nearly unheard of. At best they offer demo units of products you can try, but only ones they choose and only while you remain at the store. Try insisting on half-price for the next-gen MacBook Pro with Retina display because you bought a 13” MacBook Air two years ago and see how far you get before you’re asked to leave.

Developers and longtime computer users may be used to the shareware, time trial, pay-full-price-once-upgrade-cheaply-forever model of buying and selling software, but regular people, the mass market that Apple continues to court first and foremost, aren’t. Adding demos (“I thought this app was free, but now it’s telling me I have to pay to keep using it? What a ripoff!”) and paid upgrades (“Wait, I bought this app last year and now I have to pay again to keep using it? Screw that!”) would introduce a layer of confusion and make buying an app a more arduous process, which would result in people buying fewer apps.

At least, that’s the rationale behind Apple’s decision not to implement them. To be clear: what I just wrote is not my opinion of how things should be. This is only my guess at Apple’s reasoning.

So if Apple is basing their digital stores on their physical ones, how should developers like Wil Shipley and Cabel Sasser handle the problem of making enough money from past and future customers in order to eat and make more cool software? I think Apple thinks they should take cues from how Apple handles their own software transitions: no upgrade pricing, just one reasonable price that is palatable to its target audience. Make your software great and easy to buy, and more people will buy it.

Yes, there are edge cases where some unlucky customers will fall through the cracks (those who bought your old app right before the new one came out) and those who won’t be happy to pay again for the “same” app regardless of how much time has passed (two words: “Tweetie 2”). And it would be great for customers and developers alike if Apple implemented a way to stop selling an old app but still let devs provide bug fixes. But Apple knows that while you can’t please everyone, you can make good money by pleasing the majority. And as long as the majority likes affordable, straightforward app-buying, that’s what they’ll continue to offer.

iOS 6: Our Complete Overview

Taking the stage at WWDC, Apple’s head of mobile software Scott Forstall kicked off his iOS 6 presentation noting how, with over 365 million iOS devices sold through March, Apple’s mobile software is doing very well in the market. The latest publicly available version, iOS 5, has been installed on over 80% of available devices. Released in October 2011, iOS 5 has seen exceptional adoption: over 140 million iMessage users have sent over 150 billion iMessages to date, making it over 1 billion on average every day. Directly integrated into iOS 5, Twitter saw a 3x growth increase, with over 10 billion tweets sent from iOS 5. The numbers go on and on.

There’s no denying on Apple’s part that iOS 5 has been a success for developers, the companies involved, and, ultimately, the users. iOS 6, previewed and released to developers as beta today, is a major new release that, with over 200 new features, will take iOS devices in “entirely new directions”.

Jump past the break for our complete overview of the next major release of iOS, shipping this Fall. Read more

Harry McCracken Reviews the Original Apple MessagePad→

Harry McCracken Reviews the Original Apple MessagePad

When Jobs decided to shut down the Newton division, color screens were still unaffordable, touch input was crude and wireless data didn’t get much more exciting than two-way paging. When he launched the first iPhone nine years later, technology allowed Apple to build the sort of devices it wanted to create in the 1990s, but couldn’t. He may have killed Newton, but he didn’t kill the dream behind it so much as press a giant pause button–and after finally spending quality time with a MessagePad, I’m more convinced than ever that he made the right call.

Apple’s MessagePads were devices that were both ahead of their time and poorly executed. It embodied everything Apple wanted to do — its tie-ins with the iPhones and iPads of today are clearly evident — but the Newton platform and the MessagePads just barely teetered on self-proclaimed success before their eventual hiatus. Despite the MessagePad’s lack of sales and its post-designation as a failed product, Harry McCracken re-visited John Sculley’s infamous product, reviewing the original MessagePad while investigating market demand and how the press received the product at the time of its unveiling. The three page article left me with some interesting take-aways about the climate of technology at the time of the early 90s, and how the Newton platform itself contributed to Apple’s later successes in both hardware and software design. A bulk of the article focuses on the technology introduced with the original MessagePad itself, but that insight is used to build a timeline of the product’s evolution whose concepts lead us to the devices we have today.

Image Credit: Time Techland

Permalink

Game In-App Purchases: A Conflict Between Developer Economics & Goodwill

In-App Purchases for iOS games. It’s a bit of a sensitive topic really, not many people like them at all, and quite a few people hate them and the impact they have had on the iOS games market. But today I want to explore the reason for their prevalence and explain why it has become an important part of the market for developers. I also want to reframe the discussion from one of “In-App Purchases are a problem” to one where we consider how they are being used and what developers could do to improve their implementation.

Below the break is Part 1: The Economics, in which I tackle the reason for their prevalence and importance in the iOS games market. Following that is Part 2: “Developers and Goodwill To Customers” in which I discuss how they are being used and perhaps what might be some best practices.

Read more

Using an iPad to Report from Pit Row→

Using an iPad to Report from Pit Row

I upgraded to the iPad 2 over the winter for the weight break and camera, and all has gone smoothly in 2012. I no longer bring my MacBook Air on the road, and am thrilled that the TSA doesn’t require that the iPad be removed from my carry on! Using the iPad for what I do has proven to be efficient and entertaining. And, as usual for an Apple product, IT JUST WORKS. I’ve had to put a baggie over it a time or two in a rain situation, but other than that it absolutely does the job.

Jordan Golson of MacRumors has written a fantastic report on Dave Burns, a Pit Reporter for ESPN who covers NASCAR Nationwide and Sprint Cup series races with his iPad. Burns’ use of the iPad is the focus of the story here, and he does an excellent job explaining how he ended up choosing the gear and accessories that best suited his needs on the track. Not wanting to deal with the bulk of paper, but then having to compensate for sun glare, heat, and occasional rain showers, Burns had to devise a system that helped him stay mobile yet offered the greatest potential benefit. Equally as important as the process that Burns’ shares, the report gives insight into just how adaptable the iPad is. Proven to be much more than a generic business tool, the iPad is being used in unexpected places for unique applications: in this case it’s being used to bring you coverage from pit road in America’s most exciting motorsport.

Permalink

Diet Coda From An iPad Blogger’s Perspective

I am no web developer – I write prose, not code – but I just bought Panic’s highly-anticipated, fantastically-named Diet Coda for iPad from the Italian App Store. I want to show my support to the great independent developers of the iOS and OS X community. Furthermore, I want to help disrupting the long-standing meme that the iPad can only be used for “content consumption”, whatever that has come to mean in 2012. I didn’t know I could still find Diet Coda useful for my iPad-based writing and blogging workflow.

I can’t review Diet Coda – as I said, I wouldn’t be able to fully understand its functionalities and judge its (possible) shortcomings when compared to the (also coming today) Coda 2. But I can recognize software crafted with care and attention to detail. Diet Coda immediately stands out as one of those apps where pixels aren’t just there to fill the screen – they’re the epitome of design enhanced for function.

Take the custom text selection method Panic built. It’s not entirely custom – it’s still fundamentally based on “drag handles” and a “zoomed-in view” of the cursor – but Panic reworked it to allow for faster selection by swiping on the left (where numbered lines are) and to visualize a larger, rounded “zoom selector” (they call it the Super Loupe) when you’re moving the cursor between characters. It feels much better than standard iOS text selection – faster, and somewhat more accurate – albeit it really needs to be experienced “in motion”, rather than through the screenshot I have embedded below.

I wouldn’t mind seeing Apple drawing some inspiration from Panic’s Super Loupe and Hooper Selection for the next major version of iOS.

Or, again, search. Within a document – Diet Coda can edit files on your server with syntax highlighting for languages like HTML, PHP, or JavaScript – you can hit the search icon to initiate a query with options for Find & Replace, Case Sensitive settings, Regex, and Search in Selection. I can’t tell you how many times I wished a text editor would implement search through selected text within a document the way Panic did.

It’s about getting the details right, yet making sure the main foundation is also solid to begin with. Diet Coda features a perhaps not so innovative, yet reliable column-based navigation for browsing folders and opening files; at any time, the column view can be “enhanced” with thumbnail tabs (also called “document shelf”) displaying open files, the main Sites page, and Terminal along the top of the screen.

And if you go back to the Sites page – where you add the servers you want to connect to using Diet Coda – and enter “wiggle mode” to edit the sites you’ve configured, Panic added a nice button at the bottom to confirm you want to exit the wiggle animation. You could stop it anyway by touching anywhere on the screen, but this is a nice extra visual cue.

Same for buttons: the purple ones “glow” when tapped, and the Delete action is, again, custom by Panic, yet incredibly nice to use on iOS.

I may not write a full review of Diet Coda, but I was sure happy to find out Panic’s latest effort will find its well-deserved spot in my iPad writing workflow. Diet Coda, finally, allows me to copy the public URL for images uploaded to my FTP server. That’s a small feature, but you’d be surprised to know how many FTP iPad apps end up lacking it amidst dozens of other “power user options”. I wish Diet Coda would let me upload from the Camera Roll – hopefully that’s coming in a future update. However, together with buttons to copy the public URL and file path, Panic added options to copy an image’s HTML <a> and <img> tags to the system clipboard, making it extremely easy to paste the code into Blogsy, my blogging app of choice. The simple, yet often ignored “copy URL” action will play nicely with Writing Kit’s shortcut for inserting images into Markdown, too.

Even without fully utilizing Diet Coda’s set of features, I’m happy to see the app filling a particular void in my workflow – and even better, with style and prowess.

We will have more detailed looks at Coda 2 and Diet Coda later this week on MacStories; personally, I believe Panic’s latest iOS effort will redefine the category of web code editors on the iPad, proving once again that the platform has moved beyond “consumption” – and that’s just up to users to accept it now.

Diet Coda is now available on the Italian App Store and other international stores (same for Coda 2). Diet Coda and Coda 2 will be available here and here, respectively, on the US App Store in a few hours.

iOS 6 and Files.app

Rene Ritchie thinks Apple should provide direct document access with iOS 6 through a dedicated Files.app:

A unified document repository, modeled after the existing unified image repository, rounded out with more consistent attachment options, could be the best of all worlds. Users wouldn’t have to remember which folder a document was in, nor which app. They wouldn’t have to jump around to edit or share. Users could simply open any app capable of editing or sharing a certain type of app and go to work.

I agree with the notion that the current Open In, app-based document transfer model of iOS is broken. The simplicity brought by iOS freed average users from the complexities of the filesystem; people who like to get their daily work done with iOS devices, however, miss a unified document filing system. Paradoxically, the “simple” iOS, with its “Open In” menu and multiple copies of the same document, requires people to manually manage more.

In February, I envisioned something similar to Rene’s proposed Files.app solution:

So, I had an idea. I think the same iTunes File Sharing feature would work a lot better as a dedicated, native iCloud app for iOS devices (and maybe the Mac too). After all, if Apple is providing an iTunes-based file management utility for Mac users, why couldn’t they build an app that enabled any third-party iOS app to save and import files from iCloud? This app would be built into the system and allow users to simply collect documents, like iTunes File Sharing. Developers could easily add options to their apps to import files from “iCloud File Sharing” and export files to it. Users would have the same feature set of the existing iTunes File Sharing, only with an interface they are already familiar with, because iCloud File Sharing would resemble the existing file management workflow of iWork for iOS or iCloud.com. The only difference is that it would be integrated on a system level, work with any iOS app, and basically be an extension of the “Open In” menu that already allows apps to communicate with each other through supported file types.

After having tried the latest developer releases of Mountain Lion and putting some more thought on the matter, though, I am not so sure about the centralized repository system anymore. Namely, I am not convinced it should be a separate app.

Rene rightfully compares the possible Files.app to the existing Photos.app for iOS. Files could present document folders the same way Photos displays image albums, and it could have the same systemwide hooks to let other apps access documents from the unified repository. However, there is a difference worth noting: Photos.app gets its contents from a primary, hardware-based component of iOS – the camera. A user takes a picture, it goes into Photos. Same for videos and screenshots – the interaction is simple.

What is a file, though? Is it a text document? RTF or .txt? If so, does Files.app come with preview capabilities for those file types? Or is it about PDFs, .zip archives, folders, and .cbr files? And how do you get documents into Files.app?

Even by only slightly mimicking the Finder, Files.app could reset the past five years of “simple” iOS interactions in one big fell swoop. Photos itself, which is extremely straightforward, is criticized for its file management features. Now imagine that applied to the general concept of “files” with folders, views, sorting options, settings, and previews.

Today, I think what I wrote back in September could make for a better solution: inter-app communication.

Why can’t Apple build an invisible layer that lets Elements edit a text document from Evernote and Pages access the same file?

It turns out, a possible implementation of such layer already exists, but iOS won’t let apps communicate with it. Enter iCloud Documents & Data:

The same interface is available on OS X:

And in Mountain Lion, the standard file-saving dialog has been enhanced with the addition of an iCloud option (image via Macworld):

The design is slightly different since the first Mountain Lion Developer Preview that Macworld reviewed, but the concept has stayed the same throughout betas: Apple apps like TextEdit and Preview can “hold” documents into a special iCloud folder (located under Library/Mobile Documents/appname/Documents on OS X); these documents also show up on iOS under Documents & Data; currently, they are not available on iCloud.com, nor is Mountain Lion’s file-saving UI allowing, say, Preview to easily grab a file from TextEdit’s own iCloud “folder”. However, on Mountain Lion, Apple says that you can get your “existing documents” into iCloud by dragging them from the Finder or “other apps”.

If the system Apple has been putting in place is of any indication, I think enhancing the app-based model with better communication would actually outmatch the possible benefits of a separate Files.app. Documents & Data could become a document picker developers can enable in their apps with an API; because apps register file types they support, Apple wouldn’t have to worry about creating a Files.app capable of previewing every single format out there. GoodReader could open a PDF from Pages’ iCloud, and Pages could later access that same PDF with the changes made by GoodReader.

I am arguing that apps should become their own centralized locations that other apps can access and interact with – without creating duplicate files. Apple can’t provide the basic preview/edit functionalities of Photos for every possible format supported by Files.app, but 600,000 App Store apps might have the solution for that. Rather than creating an additional layer of management – disconnected from apps – iOS 6 could turn the interface already in place into a document picker that gives files their proper meaning: the app they belong to. Only with the addition of inter-app access and “universal save” to avoid duplicates.

Making changes to a single file with a variety of apps is something we do every day on our Macs. On OS X, there’s the Finder that acts as a glue between apps and files. By design, the technical constraints of iOS have turned non-destructive editing into a clunky and confusing experience, as we’ve seen with iPhoto. I am arguing that instead of building a “Files.app” or “Finder for iOS”, Apple could leverage the existing iCloud Documents & Data UI, and rework the iOS architecture to allow for changes to the same document from multiple apps.

The centralized Files.app idea is certainly appealing, but Apple has heavily invested in the app metaphor for the past years, and rather than replacing it with a new layer, I wouldn’t mind seeing it get smarter.