nikf.org

The Essence of Wearable Design

Nik Fletcher — Tue, 14 Apr 2015 19:45:00 +0000

Over the last few months, I’ve spent a fair bit of time working on Clear for Apple Watch, trying to get my thoughts defined about wearables, and thinking about what our focus should be.

Apple’s interaction window for each Watch app is incredibly short: a matter of seconds. That’s not to say that you can’t use the app for longer - it’s just that for an app to have meaning, you’re needing to be incredibly focused on enabling these short bursts of interaction.

To build something that matches the usage window requires discipline, and plenty of careful work. We’ve learnt a lot building Clear for Apple Watch - and it’s been fun to consider the things we’ve taken for granted even on the smallest of iPhones (for example: the ability to easily notice a changing label in a table view, when adding or changing a reminder in Clear). For me, however, the over-riding theme of building for a wearable is slightly more philosophical, more complicated than simply saying “let’s distill the core features to aid the short interaction window and ship it”, and involving every decision across every discipline. It goes something like this…

The mobile phone lives in our hands. It’s at the end of our arm , but only when we choose it to be - it’s an optional extension of ourselves. While we might like our mobile phones and all that they offer, it’s still an extension of ourselves that we explicitly choose to interact with. When it comes to wearables like Apple Watch, it’s very, very different. We’ve moved from technology on-demand, where we’ve mastered the art of taking the mobile phone out of our pocket, to having technology remind us that it’s a part of our being.

Our apps are about to become a part of everyone’s being on a far deeper level than before, and with that comes an even greater responsibility for respectful design and development, and a heightened appreciation of the people who wear our creations. It’s time to consider the subtle but important change from “the user” or “the customer” to “the wearer”.

Some Notes on Twitter’s App Download Tracking

Nik Fletcher — Wed, 26 Nov 2014 20:40:00 +0000

Twitter’s news today, buried ahead of the Thanksgiving holiday, is that client apps on iOS and Android will detect the apps you have on your device to aid in the targeting of suggested accounts and advertising.

Kurt Wagner, Re/code:

On iOS, for example, developers can ping a user’s device at any time and recall a list of apps that are currently running on their smartphone. If they ping the device often enough, the developer could piece together a user’s entire app library.

Whilst mostly true, there’s some important details that need clarification.

How Is Twitter Doing This?

My guess on how Twitter is doing this is through URL schemes¹. It’s an important distinction to note (though, as an outlet for a not-necessarily-technical audience I won’t knock Re/code for over-simplifying), as Re/code suggests it’s based on what’s running on your device - when in fact it’s based on apps that appear³ to be installed on your device and have been launched. This obviously changes over time, and my beef is simply with the use of “currently running”.

Specifics

Apps on iOS² can declare a URL scheme that, when they’re launched for the first time, the system registers to the app. This basically means that if a URL starts with the declared URL scheme, iOS will launch the app and let the app know the full URL that the user (or other app) used. By including extra information as part of the URL, you can effectively deep-link within the app to a specific spot.

e.g. Entering twitter://user?screen_name=nikf in Safari will open my profile in Twitter’s app.

Example of a URL scheme with a deep-link

twitter://user?screen_name=nikf

The most important thing about URL schemes, however, is that its implementation in iOS is not one that allows you to ask the system “OK, what URL schemes can the system handle” (unlike on OS X). You have to ask, for every URL scheme your app is aware of, “OK, can you open a URL like twitter://user?screen_name=nikf?”.

It’s worth noting that the UIKit method that apps can use to see if a device is capable of opening any given URL arrived in iOS 3.0 in 2009, and other apps have used it on a smaller scale to personalise sharing options (in the case of Clear, we use URL schemes to unlock themes if you have certain other apps installed). URL schemes are also used in things like Notification Centre’s Today widgets to launch an app when tapping on an item.

What Can Apple Do About This

Honestly: it’s hard to know. URL schemes are widely used (for everything from app-launching to handling web-service sign in). If Apple wanted to prevent wide-spread use of app detection like this, it could ostensibly require apps to declare the URL schemes the app intends to launch in the app’s configuration (alongside the URL schemes the app itself offers to the system). Similarly, Apple could prevent apps from launching URL schemes for apps that aren’t from the same developer. There’s also, most probably, smarter options that I haven’t thought of.

However. Any of these approaches, whilst shoring up privacy would deal a substantial blow to many apps’ benign workflows. URL schemes are useful to detect specific contextually-relevant actions for the apps on your device - even with the arrival of extensions in iOS 8 - and even web-services that you use in Safari make use of them to open apps.

In short: what Twitter is doing (more than likely) isn’t new - for example, it’s how Facebook switches you to Messenger when tapping on the Messenger item in the tab-bar. It still (more than likely) requires Twitter to build up a substantial database of URL schemes and maintain them - something both handleopenurl.com and Twitter’s own ad products can help with. But that doesn’t make it any less controversial.

Update: One thing I deliberately overlooked was the use of private APIs to detect the currently-running apps. It’s certainly possible with private APIs. But it seems unlikely that any half-serious developer would try slipping this through App Review (if it even got that far).

Update 2: A peek at the contents of Twitter’s “TwitterPlatformResources.bundle” within the iOS app reveals a JSON file containing over 2,500 app URL schemes and their Apple App Store ID.

Update 3: This feature is no longer part of Twitter for iOS.

Twitter provides a guide on how to use URL schemes as part of your app in combination with their “App Cards” product. ↩
OS X also supports URL schemes, as you’d expect. However it’s not as neatly abstracted as on iOS. ↩
I say “appear”, as URL schemes that developers add to their apps are intended to be unique but aren’t enforced as unique. So, an app could register another app’s URL scheme. If URL schemes collide, then bets are off as to which app iOS launches. ↩

Some Observations on the iPhone 6 Plus As Someone Who Owned One (Briefly)

Nik Fletcher — Fri, 26 Sep 2014 21:35:00 +0000

I owned an iPhone 6 Plus for a short period this week. It’s a stunning device - certainly polarising, and an incredible feat of design. I returned it about 24 hours later for an iPhone 6 (which I have no regrets about) as the device isn’t for me. That’s not to say it’s not the perfect device for you, but I couldn’t adapt and found it simply didn’t fit my needs.

In my 24 hours with the device, a few of things struck me:

It’s definitely a new class of device - as big a change for the iPhone as the iPad was.
The possibilities for software are exciting, particularly given the blurring between iPhone and iPad apps I discussed last night. The 6 Plus sits firmly in the middle here, which will be fun to watch.
I loved the landscape dock (and wish this fluidity in Springboard were on the iPhone 6 also).
The 6 Plus surprisingly felt more like an iPad than an iPhone.
Despite feeling like an iPad more than an iPhone, the software is still iPhone-driven. In landscape mode, the Photos.app deletion confirmation felt odd being in a UIActionSheet instead of a Popover (as the iPad does it) and again in the Photos app, the deletion-confirmation UIActionSheet’s locality to the Delete button felt like a stretch despite having both hands holding the device.

All in, I’m glad I bought and tried the 6 Plus - and I’m excited to see how the device develops. More than anything, I’m interested in what the form-factor enables: landscape mode finally becomes useful, with a considerable amount more space on-screen with the keyboard up; iPad-like split-views mean that folks who live from their phones can navigate more easily; and above all I’m excited to see what happens to the 6 Plus software in the future. Right now it feels awkwardly stuck between the iPhone and iPad, uncertain which idiom to follow - and as iOS 8.x and beyond appear, I wouldn’t be surprised if it finds more of its own voice instead of simply being a big (though admittedly very beautiful) iPhone.

The Impending Watershed For Device-Specific iOS Apps

Nik Fletcher — Thu, 25 Sep 2014 20:25:00 +0000

The responsive iPhone and iPad simulators that debuted at WWDC this year have been (and continue to be) full of mystery and potential - quite possibly the biggest source of change in iOS 8 itself. Combined with the iPhone 6 Plus’ size, landscape mode and downscaling, there’s a lot of fluidity and responsiveness coming to iOS this year… A quick count:

Ability to set explicit pixel counts in Simulator
Simulator Betas “Accidentally” accepting @3x assets
Ability to set size classes in addition to explicit pixel counts.
Landscape mode, iPhone 6 Plus [a.k.a “Rotate to iPad”]

While the iPhone 6 Plus has been a substantial source of confusion and consternation for developers so far, this (I suspect) is nothing compared to what’s rumoured for the iPad. The substantial blurring of what constitutes and iPhone or iPad app is going to cause headaches for indies who swear by separate iPad and iPhone apps. And that’s even before you start to consider a more appropriate layout iPhone 6 Plus…

Federighi's double middle fingers in the air as he shows the giant iPhone 6 using iPad size classes, forcing us all to be iPad developers.
— Justin Williams (@justin) August 7, 2014

If you’re like me, after watching WWDC 2014 session 216 “Building Adaptive Apps with UIKit” you’re probably equal parts excited and nervous. Some of the cat is finally out of the bag, after a WWDC session so full of “how” and precisely no “why” - and rumours suggest more is coming. The biggest rumour for iOS on iPad so far this year has been “Split Screen” - and Size Classes (covered in aforesaid WWDC session) provide a way to offer just this.

For example: if you were able to (hypothetically) split-screen on iPad ¹ with a 75/25 split, and you opened Clear in the 25%, you may consider it more appropriate to offer a different UI. Previously, if an app launched it’d simply say “Oh, I’m running on an iPad: let’s show the 1024x768pt interface.” Now, it’s a case of “I may well be running on an iPad, but the current size class I’m being run within is a compact-width, regular height view. So in this case it’s probably more appropriate to show an iPhone UI even though I’m running on an iPad”. This is a fundamental change in both how apps detect and then adjust to size changes - not to mention how apps are built and marketed.

Universal, Right?

Among independent developers, there’s a long-standing practice of separate iPhone and iPad apps. It’s understandable: you can’t price a Universal app at device “appropriate”² points. Paid universal apps also find it tougher to climb the charts (so the wisdom goes) because purchases of a Universal app only apply towards charts on the device of purchase… So, indies go to iPhone first - and then release a second, paid, iPad app once the iPhone has established itself.

Apple, of course, has a different view. They understandably want customers who go from iPhone to iPad to have the same apps ready and waiting: they don’t want customers to have to re-discover the apps they already love and use. There’s also I believe a case of Apple believing that doing a separate app isn’t the right course because you’ve barely made a dent in getting your app onto the millions of iOS devices. By bringing out a (free) Universal update - or better still, launching Universal - you’ll get existing customers stoked about the app, helping to spread the word, and the right marketing efforts can help to drive up revenue.³

Business Aside

Whichever side of the economic fence you sit, however, there’s no denying that size classes (and possible split-screen) bring about significant potential change for separate-SKU developers. Some may simply choose to not opt-in to split-screen on iPad; some may simply ensure the iPhone app could run in split-screen conditions perhaps. Ultimately, however, these aren’t ideal solutions. Ultimately, building a Universal app with size class support ensures that no-matter what device or size class a customer places your app into, they’ll get a great experience⁴. Our job is make sure that happens.

Prepare for iOS 8: enable OS X Server’s Caching Server

Nik Fletcher — Sun, 14 Sep 2014 20:10:00 +0000

As you well-know, iOS 8 launches this week, and there’s going to be a lot of app updates flying around. If you’re on a network with more than a couple of devices, a few substantial updates to things like Keynote, Pages and Numbers (not to mention everything else) will likely take a while to download.

So, I thought I’d remind you that OS X server comes with a relatively new Caching server that since OS X Mavericks has handled far more than just OS X and Mac App Store updates. Unlike the OS X Software Update servers of old, Caching server is both invisible, and dynamically used by devices - switching back to the App Store itself when unavailable. No more hassle post-configuration (it’s two clicks), just all the App Store, iBooks, OS updates and iTunes Store downloads locally cached for quick retrieval. We’ve had it set up in the Realmac office for some time, and even though we’ve some seriously speedy internet this has made the software update and installation process far easier - particularly when installing things like Xcode from the Mac App Store.

Best of all: if you’re a Mac or iOS Developer Program member, you get OS X Server as part of your membership. So: take a moment to download and install it on a spare Mac before Wednesday. It’s made life far, far easier in the Realmac office - and with the volume of updates (even when factoring in delta updates) it’s made our lives so much easier.

If you’re interested in how Caching Server works, Fraser Hess has done some sleuthing.

The State of the Apple Developer Ecosystem

Nik Fletcher — Fri, 23 May 2014 09:50:00 +0000

The 10 hours in a metal tube between London and San Francisco provide for some great thinking space. The flights to and from WWDC last year as every year offered plenty of time to take stock of where things are, what could be, and on the way back what it all means. With all the focus on iOS 7’s new aesthetic, understandably the “iOS 7-only” mantra was top of everyone’s minds. But as I sat in sessions eagerly watching talks about all the new technologies on iOS, something bigger struck me. Something that’s taken almost an entire year to fully analyse.

There’s no denying that WWDC 2013 was one of the most exciting in recent years - however, for all the new technologies Apple announced the thing that struck me most - the thing that excited me most as someone building things for the Apple ecosystem - was a single phrase in many of the sessions: “Also available on the Mac”.

“Well sure, the Mac’s the bigger brother - of course things should be on the Mac” you’re thinking - and you’re right. But I think it’s indicative of an important, bigger trend. It’s not about the visible merger of iOS and OS X and their interaction menthods - but the technological re-unification of the two systems which is a more subtle, important and different ideal. As Apple continues to re-normalise the relationship between the Mac and iOS devices, we’re starting to see not one united front in aesthetics and interaction a la Windows 8.1, but something else: the ability to use whatever medium-appropriate input we feel best serves our needs.

iOS and OS X have of course been cross-pollinating for many years: examples such as iOS using Core Animation from the get-go, and OS X receiving QuickTime X in Snow Leopard spring to mind. However many of the bigger changes Apple has made in recent releases (both in OSes and apps) have been seen notsomuch cross-pollination but whole-scale transformation to bring a level of consistency and familiarity to both OS X and iOS. Given the bold new direction that iOS took last year, and with rumours of a new OS X aesthetic swirling, it’s an exciting time to be watching (though perhaps testing time building for) the Apple ecosystem.

Beyond the customer implications for the changes we’ve seen though, I believe there’s a bigger story to tell, and questions to ask about the entire ecosystem that are (I suspect) being asked as much in Cupertino as they are elsewhere.

Philosophy

To look into Apple’s thinking the longer-term game plan and beliefs, I think last September’s iWork releases are a good conversation-starter.

Whenever a particularly contentious product decision arises surrounding Apple, I (like many other, probably more irate, people) find myself considering the decisions that I imagine were raised as part of the development process. Considering the size of the Apple ecosystem, the number of people new to iOS that are joining the ecosystem each year, and Apple’s desire to reduce, optimise (and perhaps simplify) their apps reminds me of a Jeremy Bentham quote:

“It is the greatest happiness of the greatest number that is the measure of right and wrong”

The iWork release was a divisive one - there were (and still are) areas of the apps that were most certainly regressions for the more advanced users. But in many ways, the new apps offered a (much-needed, and in hindsight under-appreciated) set of improvements and considerations for the majority of users. The updates also, I believe, made a statement about Apple’s desire to normalise a suite of much-loved but well-worn apps across its entire ecosystem - most interestingly of all, on the web too. AppleScript omissions (justified, I believe, at launch) were of little initial consequence to the wider audience - AppleScript remains a niche, and isn’t of use on iOS or the web. There were stubs of AppleScript support (deadlines looming, it didn’t make it?) and since then, Apple has by all accounts brought an enhanced and more standardised AppleScript dictionary to the suite. However oddities such as “Replace Image” only being available in Keynote and Pages via the Media Popover showing your iPhoto library, and a file format not entirely friendly with Gmail remain¹.

It should come as no surprise then, that Apple’s approach is to consider both the company’s best interests and the interests of the majority of its users (the iOS-centric user) as a core strategy principle, and that adds an interesting tension between two sets of users.

One other thing that the reunification of iWork questions is that of platform ubiquity and this area that Apple puts so much effort into is a double-edged sword.

Growing Pains

It’s clear that, for all the consumer-friendly new technology in the iPad and iPhone we’re still only beginning to make these technologies consumer-friendly. There’s tension between the old and the new. The technological unification of these platforms has its friction points, and in some regards the Apple ecosystem is still seeing a few growing pains. As iOS and OS X continue to cross-polinate, we’re starting to find the cracks in the plaster, and the discrepencies between the two show more than ever.

At the same time, every headline technology is being brought to both iOS and OS X at the same time, year after year. It’s one hell of a feat, but not without its own potential flaws. As I discussed this piece with my colleague Damien, he made the great point that having technologies on one platform first (as a testbed) has served Apple well - think, Auto Layout - whereas the volatility that comes of shipping a technology or framework across the ecosystem, and then a substantially-reworked just the following years - think iCloud + Core Data - forces developers to divert their attention from building features that delight (Apple’s) customers to that of maintenance.

If you talk with many long-term Mac users, you’ll find that one of their biggest dislikes in recent OS X releases (and one of the biggest areas of coherence between iOS and OS X) is that of app state and Auto Save. The ability (and indeed necessity) to discern the state of an app is diminishing rapidly - especially on iOS. You wouldn’t (or perhaps shouldn’t need to) tell someone to quit an app on their iPhone - you’d suggest that they close the app, return to the homescreen or simply open another app. The introduction of Automatic and Sudden Termination in OS X Lion brought into question the state of apps running on OS X - try turning off the “indicator lights for open applications” option in System Preferences -> Dock and things start to make sense. It’s easy to understand why this would confuse (and concern) long-time Mac users, but it begs the question - do the majority of people need to worry about whether an app is explicitly open or quit? The death of the term “Quit” may still be a way off, but it’s not hard to imagine a “Close App” option in its place - or Cmd + Tab becoming more like the iOS app switcher (though that might necessitate automatically-terminated apps to remain in Cmd + Tab)³.

Regardless of any changes that may cross to the Mac the radical de-emphasis and convergence of app state is a particularly interesting problem, as it symbolises the many friction-points in the reunification of iOS and OS X - brushing up against “the way it’s always been done” vs adapting to more general users’ needs.

Then there’s perhaps the dark horse feature of iOS 7 that adds fuel to the fire: Background App Refresh. The fact that iOS can give apps background time means that the experience on mobile feels more modern, and far faster. Every app has the effect of always being up to date, as if you never left - and you find yourself not needing to dive into apps “just” to see if there’s anything requiring your attention².

Background App Refresh and iOS’s background processes (e.g. Mail, Music) also raise some interesting questions about OS X: why does Mail need to be explicitly opened to ensure the Dock badge is up to date? Why isn’t iPhoto showing my most recent photos automatically, instead syncing with iCloud to retrieve photos when I open iPhoto. Background App Refresh on iOS makes such a night-and-day difference that going back to the Mac feels somewhat old-fashioned. Sure, I could leave dozens of apps open in the Dock all day so that they’re able to refresh - but the Dock (at least for me) is an area that only my most frequently-used apps get placed in as a shortcut to their opening.

The App Store

Back in June 2008, when the App Store (and MobileMe) launched there were “just” 800 apps on the App Store - a crazy number given the scale the App Store runs at now.

For all that the App Store revolution offers in ways that customers buy software, it’s amusing that the App Store behaves in many ways just like a traditional retail store. To anyone who follows Apple, that they’d look to control the sale and support of apps should come as no surprise - the fact that Apple vets apps and offers fast, and courteous support for purchases is one of the key reasons people trust the App Store.

However, the inconsistency in how Apple treats purchases - and the fact that customers have to hit two support channels for support with an app - ruin this experience. Customers shouldn’t have to contact Apple for support with an app, only to be referred to the developer.

Making support options from developers more visible would be a great start - even just a (reviewed, if need be) auto-responder that developers can associate with an app would be a great way to reiterate to customers that you fully support your apps.

Ratings

As I was preparing this piece, David Smith made some terrific points about the App Store. One area that I feel particularly strongly about is customer reviews and ratings. Offering customers a single place to share their opinions is a great feature - but I’ve always found rating an items between 5 different star ratings difficult, with the measurement of worthiness for each star being so subjective as to be meaningless. Writing for magazines in the past, there’s nearly always been a thoughtful guide of what one-star through to five-star means. Here’s the App Store copy for app ratings (capitalisation from the Mac App Store at the time of writing):

One Star “hate it”
Two Stars “don’t like it”
Three Stars “it’s ok”
Four Stars “it’s good”
Five Stars “it’s great”

In some regards, the Facebook integration that arrived with iOS 6 seemed like a great idea - I certainly prefer to up-vote the apps I like (be it in person or via Twitter) instead of rating any app I pick up. The problem is this: I very rarely see a single social recommendation in the App Store.

Reviews

App Store reviews are a baptism by fire for developers, and whilst allowing customers to rate your app is a great idea - the frustration at being unable to help folks who genuinely need it is truly disheartening. As someone who started off doing customer support, my desire to help make things right with every customer simply multiplies the disappointment of being powerless to do so. We’ve spent a lot of time discussing this at Realmac, and I’ve distilled my views on App Reviews to a blunt answer:

Apple’s own customers are being actively harmed by the inability to seek help from app developers

When someone leaves a 1-star review, that stings. But the fact that they left a 1-star review for something that a quick email to the developer could either rectify or ameliorate, helps no-one - and to see reviews from users such as this (from a Realmac app) suggest that Apple could be doing far more to improve the feedback loop between customer and developer:

“Unfortunately there is no other way [than leaving a review] to report bugs to the developers.”

Discoverability

The battle for search and discoverability supremacy is far older than the App Store. Tradesmen out-did themselves with alphabetical names (Aardvark Plumbing?) in the phonebook long before the SEO snake-oil salesmen promised to get you listed further up in Google.

Apps Near Me - added in iOS 6 - has been an interesting feature in the App Store. It replaced Genius, and for the longest time showed (typically) two or three apps:

the local newspaper’s Newsstand app
a local transit app (because Apple Maps)
a free to play game

Interestingly, at least for my own usage in Brighton the recommendations recently improved dramatically, and moving even a mile across town provides varied results: at the office Clear appeared in the “Near Me” list, but towards Hove it didn’t.

I have to admit I don’t find Apps Near Me that useful. It’s taken a long time for the suggestions to improve (and even then, there’s a lot of transit apps in the list) and I don’t care for what the swathe of people in the city around me use: I want to know what my friends are using.

A Focus on Editorial

The lack of improvement in App Store search, and reluctance to offer significant algorithmic personalised discovery for apps isn’t (I believe) accidental. Apple remains a company of many small teams, and plenty of the things that Apple is criticised (in this piece, and elsewhere) for not doing can easily be chalked up to the company simply not having got to it yet.

The focus on App Store editorial isn’t one of those things. The App Store homepage offers a critical opportunity for Apple to offer a listing of the apps it believes (and understands) customers find interesting, whilst also serving Apple’s own viewpoint. Apple obviously wants to highlight apps that align with Apple’s own goals:

Choice of high-quality apps
Latest technology adoption (if not iOS 7-only, then using Apple technologies such as iCloud, Game Center etc.)
Localised for territories Apple is targetting (China, Brazil, Russia etc.)

I also think that the use of Editorial is prioritised as Apple still holds onto the App Store charts very closely. It wants to ensure that no app can game or skew the charts (be it through paid app installs, social pressures or otherwise) - and focusing on deep and broad editorial curation of the App Store is key to this.

The Sandbox

For many Mac developers, the Sandbox is a source of understandable consternation. I’ve always been very diplomatic about the sandbox, and as a technology it’s a great safeguard to have. On iOS, it’s never been quite as contentious - it’s always been there - however there is of course plenty of improvement to be made there.

Sandbox? They should call it the sadbox.
— Jon Gary (@recordtronic) View Tweet

Having given it a huge amount of thought, and continuing to work substantially with the sandbox in some interesting ways, I’m still struggling to give sandboxing a firm thumbs up. The benefits are notable (and A Good Thing), but the biggest problem the OS X Sandbox has suffered is something of a chicken-and-egg problem (not to mention, perhaps, a policy bait-and-switch - more on that shortly): the OS X Sandbox couldn’t be implemented without knowing what sort of behaviours need to be codified into it, but without a substantial implementation it’s hard to actually implement and discover which behaviours need be codified.

There’s also the fact that some apps require a not-insignificant amount of work to adapt to the sandbox. To riff on Allen Ginsberg’s “Howl”:

I saw the best minds of my generation destroyed by madness, dealing with the sandbox

Irrational, perhaps, but the economic cost of dealing with the sandbox for small developers who rushed to support the Mac App Store when it launched isn’t to be scoffed at.

I’ve always believed that the deadline for the sandbox (pushed back several times) was Apple’s wake-up call: after all, with hundreds of apps on the Mac App Store, the deadline forced developers to drop their tools and look at the bare-bones sandbox in OS X Lion. It wasn’t until OS X 10.7.3 that persistent file access outside the sandbox become a possibility, but each year Apple has implemented a number of important options in the sandbox. There’s the Assets API (Media Browser etc), for example, and the improvements to AppleScript.

As I wrapped up this article, Panic announced the (to be determined) absence of Coda 2.5 from the App Store. Having spent many, many hours planning, and working through the ramifications of the sandbox for RapidWeaver (our most complex app in terms of sandbox implementation - it‘s got third-party plugins) I can feel the pain. We’ve certainly jokingly toyed around with not launching RapidWeaver 6 on the Mac App Store - but the Mac App Store is an important additional income for many developers. In our own case at Realmac it’s not canibalising our direct sales, but to not sandbox the direct version would be foolish because of the abundence of fantastic third-party addons - we’d rather offer a single environment for compiled plugins to run.

For all the improvements to the sandbox since 2011 however, it’s clear that the OS X sandbox has caused something of a chasm between the Mac App Store and Developer ID apps - and that’s a shame, not only because from a customer standpoint developers would prefer the App Store purchasing experience for our customers, but because the expectation of so many users on the Mac is that apps are aware of the filesystem - it’s one of the reasons why people might prefer the Mac to an iPad.

Talking of the filesystem, it’s interesting that in an age of increasing consistency the sandbox on the Mac takes a different route to that of iOS. On iOS, documents exclusively live within the sandbox - on the Mac, however, developers are explicitly not to save them within the sandbox.

”The container is in a hidden location, and so users do not interact with it directly. Specifically, the container is not for user documents. It is for files that your app uses, along with databases, caches, and other app-specific data.”

Personal gripes about the sandbox aside, however, I have hope -if only because for things to improve in the iOS sandbox means things will improve on OS X too. With the sandbox, Apple is (I very much hope) working on the same problem from both angles. I can’t help but feel that the reunification of the two OSes in this regard might make for some interesting improvements - and iOS could certainly take some cues from the Mac.

A Sandbox Suggestion

Ever since the sandbox launched, XPC (cross process communication) services have been about to help sandboxed Mac apps do things in a safe, defined way outside the sandbox (Wikipedia’s unreferenced article on privilege separation is a good starting point).

In 2012 iOS too started to take advantage of XPC services - Ole Begemann’s articles (#1, #2, #3) provide a tonne of detail as to how this is done, and this got me thinking about how XPC, remote views, and the existing UIActivity class could be better-integrated to help kick-start better inter-app workflows on iOS

As it stands right now, any developers have to build UIActivity objects for every service they want to support. However the real potential with UIActivity comes through apps declaring the services they can offer to the entire system. Just like Services on OS X, common activities could be made available to any app that requests them from the system. Viewing a webpage in Safari? Pocket’s system-wide UIActivity (complete with UI in a remote view controller for tagging) could allow you to save it to read later. Similarly with Photos.app, sending a photo to Instagram could be accomplished in a similar manner. I use the examples of system apps being extended, because whilst Apple has made good in-roads in supporting services at a System level (Twitter, Facebook, Flickr etc), the use of device-wide “Activities” both minimises the number of services Apple itself needs to support, whilst simultaneously offering users an instantly personalised list of services based on the apps they use. A great UX, and a way for apps to feel even more like they’re part of the system⁴.

iTunes Connect

I think every developer goes through a love-hate-loath-tolerate relationship with iTunes Connect. It’s a huge system - one that powers a not-insignificant online retailer - and has to work for every demographic of developer, from one-man indie shops all the way up to behemoths like EA.

Apple’s made some good progress with iTunes Connect - not least, the iTMSTransporter Terminal utility which allows you to offline-edit, validate and submit your app metadata; and App Store promotional artwork requests through iTunes Connect instead of via email. The reporting module has also seen a substantial update - and the ability to know which platforms your app is being downloaded on (iPhone, iPad, iPod touch) is a useful insight (and one that only Apple can offer).

For all this progress, however, iTunes Connect is a substantial friction point for developers: it’s the very brutal front-end that Apple is willing to provide developers. I say that heavy-heartedly, as after WWDC 2011 a few of us ran into some incredibly smart and knowledgable iTunes Connect engineers in a bar, and they clearly cared both about the system and the apps that go into it: after asking which apps I worked on, the iTunes Connect engineer commented “Oh cool, I believe we’re featuring that this week” - he was absolutely right. However, there’s no denying that iTunes Connect is a system built for offering the very specific set of features and (limited) insights into the App Store that Apple wants to offer.

From the lack of permalinks for deep-diving back to an app, a truly useless trail in your browser history - something I’ll chalk up deliberate obfuscation - its consistently slow loading, and painful bulk-editing of app metadata it’s not hard to find yourself cursing the system.

The first thing that springs to many developers’ minds is no doubt “an API” - and whilst I think anything as substantial as this would be unlikely, I’d settle for a few small embellishments that would make iTunes Connect more useful and developer-friendly. Third-parties have been incredibly quick to build products (and entire businesses) that in many cases will help work around iTunes Connect’s limitations, and though I’m not wishing a Sherlock-ing on any of the services that make up for the shortcoming of iTunes Connect, Apple has schooled us to expect (and aim to build) the best. The same should be true for Apple’s own developer services and reporting. Some immediate things that spring to mind.

Editorial placement notifications. I’ve already written about Apple’s desire to heavily invest in editorial curation for the App Store, so making a point of detailing how you’re featuring a developer’s wares seems like a great way to reinforce the editorial slots. Even just an email to the developer sharing where the app is featured would be a great way to reinforce the value of editorial placement.
Promotional Code status details - Tokens is fantastic and as any other Tokens user will probably also attest, it becomes indispensable in your workflow. It’s so indispensable, however, that its presence highlights the bare-bones nature of iTunes Connect’s support.

All of these small suggestions, however, pale in comparison to the one key hindrance to anyone trying to do the one thing iTunes Connect exists to do: release and update apps.

Releasing Apps

In case it wasn’t plenty obvious, Apple wants you releasing new apps, and free updates to your existing apps. It serves Apple’s interests insofar as it increases the quantity, quality and breadth of the App Store catalogue. But most importantly, because App Store customers are of course Apple’s customers, it makes Apple’s customers happy. We all love it when there’s new features (or apps) to try.

Which makes iTunes Connect’s delay of anything from a matter of minutes to (in some cases) 24 hours to make your app or update available so frustrating. There’s no doubt plenty of technical reasons why it can take a while, but when a developer has to pre-emptively plan to release an update several hours before they’ve set a release time for the media and still rely on good fortune that it appears it doesn’t feel right.

It’s in the interest of Apple’s customers to be able to download an app when reading about it in a news article or a tweet from a friend. When implementation details such as App Store propogation appear in press coverage, it’s a sign that things probably need to change ⁵.

Build and Run

When the App Store launched, it brought with it the notion of “provisioning” - that is, declaring ahead of time which 100 devices can run your pre-release code - with the device list being resettable each year as your iOS or Mac developer program renews.

Six years later, that limit remains in place. Even small developers looking to seed their wares to willing volunteer beta-testers (something folks claim isn’t Apple’s intended use case) will struggle with 100 slots per year - and it’s no wonder that the Enterprise program looks attractive. No device limits, though not quite the same resources available (iAd) as the App Store.

Apple’s provisioning methods ensure no apps for consumer use bypass App Review, and that Apple’s services remain reliable (avoiding the abuse of MapKit’s licenses etc etc). However the 100 device rule has now hit a point where it actively penalises developers looking to ensure their apps are as bug-free as possible. There has long been talk of the device limit being raised, with some developers being able to provision 200 devices, however it’s not a universal option (yet?). With annual hardware cycles quick to use up provisioning slots, and developers’ desire to always ensure that the latest hardware has the highest-quality software, it’d be great to see the provisioning system be creatively re-thought.

Glue and The Cloud

As we move into an exciting, multi-device future, the glue - that is the services that connect the devices - becomes critical to the success of the platform. Particularly when the ease of use of said services is critical to selling high-margin hardware.

iCloud’s developer features have had a tempestuous few years since their initial announcement in June 2011. Each year there’s been substantial improvements for developers - Mavericks and iOS 7 in particular offering some long-over-due (but ultimately underwhelming) improvements to iCloud - and some absolutely fantastic end-user features such as Shared (collaborative) Photo Streams.

There can be no doubt that iCloud has been a considerable success in many regards: a single free service for the many things you’d want to do with an Apple device, at a very large scale. However, Apple’s online services continue to prove polarising.

Document Sync

The core tenet of iCloud is that of “ubiquity”. Apple very carefully, and I suspect very deliberately, eschews mentions of the word “sync” anywhere in iCloud’s marketing pages.

The difference between “sync” and “ubiquity” is basically a whole lot of abstraction. And that makes things tricky to understand from a customer’s point of view.

Because there is little to no filesystem for the user to interact with (there’s an Open panel on the Mac, I’ll grant you), the nuts and bolts of the system and how it works - something that the average user shouldn’t need to care about - make for an uneasy tension between iCloud and the apps that use it.

In my own experiences talking to customers, the expectation of iCloud is that it’s a sync service you directly interact with (in effect, an Amazon Web Services setup). As such, heavy blame falls on the apps who integrate it and suffer its quirks.

However, behind the scenes iCloud is basically a folder that is guarded by the system to allow apps to write to their own sub-folder. There’s also a tonne of services that work on top of the filesystem (for example: iOS and OS X cleverly relays the presence of documents to iCloud so that other devices can be made aware of the fils, and a download of a file can be requested either now or when the device comes back online), but there remains a remarkable amount of similarity with Dropbox. Except for the notable omission on the Mac of any system-wide iCloud sync progress. Remember how I spoke of Ubiquity earlier? That’s the subtle differentiation with Dropbox - by saving the document to iCloud’s location in the Save panel, your document is “in” iCloud. You’ll see a “Waiting…” status for the document in the Open panel if it’s not yet been transmitted to the iCloud servers. But if you quit the app? iCloud is designed to “just work” in the background and users trust that the document has been synced - a contrast to current user behaviour of looking for the reassurance of activity to make sure their documents are synced.

Don’t for a minute interpret this a criticism of the principles that guide iCloud - it’s a typically-forward-thinking way of considering sync. It just, for now, feels ahead of its time and one that cautious customers (some who have suffered sync woes in the past) find hard to trust.

iCloud Adoption

iCloud is obviously available to all iOS apps. There’s no need to adopt the sandbox, and it’s all great. On the Mac, however, again it feels as though Apple is in a precarious position to have iCloud forever play second-fiddle in the document and data-sync war. With apps not always able to adopt the sandbox (and with the Mac App Store being a non-canibalising location to sell software), iCloud adoption has become less important on the Mac. Dropbox’s easily-grokked concept and visibility, combined with it not being tied to the Mac App Store makes it an easier sell - even if you’re only building for Apple devices and selling exclusively on the Mac App Store.

There’s also the not-insignificant ease of testing Dropbox vs iCloud. Dropbox allows you 100 Dropbox users to test your app. Apple in stark contrast makes developers jump through significant hoops to provision only 100 Macs and 100 iOS devices ahead of time. When testing a multi-device sync setup, it’s easy to burn through those slots.

Photos

When iCloud first launched, Steve revealed that Photo Stream was his favourite aspect of the service - and it’s easily my most-actively-used iCloud service too. However, Photo Stream itself has remained relatively unchanged and lack of progress. The confusion surrounding the limits of the service, combined with the fact that Photo Stream remains an admittedly-effective-but-dated-and-glorified conduit for photos, means that what should arguably be a passive service becomes an active, overly-involved one. Given iCloud’s 250-million-strong user-base, the scale of “just” syncing images is no small task (I’ll get to web-services in general later on); however Dropbox’s ferociousness, Google’s forays and Flickr’s new-found inner spirit puts iCloud’s Photo features on the back foot.

There’s areas besides photo services where the re-unification is on-going too. While Aperture has seen plenty of updates (and iPhoto saw a substantial update last year) it’s worth bearing in mind that Aperture 3.0 was introduced over four years ago.

In that time, we’ve seen lots - notably iPhoto went 64-bit and iPhoto & Aperture gain an interchangeable library format. Which, with the benefit of hindisght, makes perfect sense as one of Mavericks’ developer features is an Asset Library interface not dissimilar to that on iOS: a standard Media Browser, and the nuts & bolts to build your own if you prefer. The technological re-unification continues - and one wonders if the same will follow for iTunes (or will it be Music.app & Videos.app?).

iOS 7 offers some seemingly-tempting hints as to where Apple’s photography strategy could go - and the relative silence from the Aperture team hopefully suggests that things are afoot. The intertwining of Photo Stream in “Moments” teases at what could be: deleting a photo from “Moments” also removes it from Photo Stream on all your devices (if the image exists in Photo Stream). On the Mac, there’s no Moments view - and deleting an image locally and from Photo Stream requires two separate actions. Want to edit an image that’s in iCloud? iPhoto will prompt you to use a local version first. Want to add an image from your own Photo Stream to a shared stream via the iCloud area of iPhoto? You’ll need to reveal the local copy in your library first.

Syncing images via iTunes correctly notes that Events and Faces are “From My Mac”, but the label feels aged - almost apologetic, and a reminder that we’re not there - at least, not yet.

In certain tech circles last year, the quest for true photo sync was certainly a hot topic. The plight (and demise) of Everpix illustrated some of the not insignificant challenges faced by getting the millions of photos taken online and synced between devices - and that’s not even to mention the business side of it. Apple obviously offers iCloud as a free service - would it choose to offer one unified (and synced) photo service as part of that? Regardless of the business decisions it’ll be very interesting to see the more professional-user market react to any single-and-synced photo library if it happens.

Backup

I’ve written at length before about the problems facing iCloud’s backup feature. If Apple is as serious about its multi-device attachment and growth as its own webpage states, I truly believe that leaving backup as part of the iCloud storage quota for another year would be a strategic mis-step:

Whether you have one Apple device or five, iCloud takes care of everything.

Platform Consistency

The re-normalisation of our relationship between “computers” and mobile devices is something at the very heart of Apple’s strategy - and it’s got me thinking about the point at which the cross-polination between iOS and OS X pales in comparison to whole-scale experience parity. Remember: Apple sees the iPhone as a gateway product to the rest of the ecosystem, including the Mac. Not every iPhone or iPad user is going to buy a Mac - but making the experience familiar to iOS users seems likes a sure-fire way to help bridge the gap.

iBooks for OS X appeared last year - making me wonder (maybe hope) whether we should be pouring one out for iTunes. The unbundling of iTunes into Music, Videos, Podcasts, and iTunes Store would be a big move, but one that I can’t help feel Apple would want to make eventually if not right now.

The Speed of Progress

I’ve had this tweet from Patrick B. Gibson saved for a while, as I think there’s certainly some truth from a software standpoint - though not in the grander scheme of Apple’s business.

Starting to think that one of Apple’s biggest weakness is that they still only ship updates to their major software platforms once a year.
— Patrick B. Gibson (@patr1ck) View Tweet

There’s no denying that iOS and OS X are evolving at an ever-increasing rate. For people building for Apple platforms, that requires a change in approach - and a begrudging acknowledgement that whilst the software is the soul of the product, Apple is still a hardware company. When you’re heads-down focused on building for a small number of carefully-considered (and, compared to Android, consistent) hardware formfactors it’s easy to under-appreciate that. As a result, Apple’s focus remains on hardware sales and growth. The yearly release cycle can be frustrating (there’s no denying that knowing that API salvation is a year away is simultaneously helpful to know, and demoralising too), and it’s especially frustrating when there’s feature deficiencies in services such as Maps and iCloud. As a result the all-in annual release cycle that serves Apple so well with hardware feels antagonistic towards the nature (and desired) progression of its software products.

OS Support

The evolution of hardware and software is particularly thorny when it comes to OS support. Depending on who you believe Apple is out to prematurely (and deliberately) obselete your iPhone, iPad and/or Mac; or they’re a company setting a terrific example of supporting multi-year-old hardware. As ever, the truth has elements of both opinions - Apple wants you to buy a new device (remember: it’s a hardware company), but its focus on experience and delighting users means that you’ll still get a good chunk of features even in the final OS release for your device.

It’s no secret that supporting older OSes has become substantially trickier - both from a technical and philosophical standpoint.

As a business, you have to constantly evaluate the investment in technologies. With iOS 7 currently at 87% of active App Store users at the time of writing, supporting iOS 6 is a tougher and tougher call. Individual apps no doubt have their own picture of usage stats, but given the auto-update infrastructure and toolchain iteration it’s harder and harder to justify the investment in supporting older versions of iOS (and OS X).

Fighting the Toolchain

When we launched RapidWeaver 5 in December 2010, we supported OS X Leopard and later. This wasn’t crazy: Snow Leopard had just shipped, and there were lots of (particularly educational) customers wanting to ensure Leopard and PowerPC (!) support. However, as the landscape for Mac apps changed (hello sandbox, Mac App Store, and annual release cycles) supporting PowerPC was just a no-go and we finally dropped it in the most recent RapidWeaver 5 update. We’re still supporting Snow Leopard (at least until RapidWeaver 6 drops). But after that we won’t be supporting anything older than Mavericks - and it’s highly likely that we’d support only the latest version of OS X or iOS with new apps in the future.

It’s hard not to feel for the small (but vocal) customers who want to use your app on these OSes: the ability to delight as many customers as possible will also cause you to feel bad. But as a small team, you have to find a balance somewhere. Support too many OSes and you’re fighting the toolchain, throwing money and time at maintenance, and denying yourselves the chance to build upon the newest features in the OS that new customers expect (and offer a gateway to possible App Store editorial placement). You could always progressively enhance - and particularly on the Mac right now, it’s an easy case to make - but the signals seem strong from Apple: “you probably won’t bother supporting the previous major version, and we don’t think you should either”.

Conclusions

So where does all this thinking-aloud leave things? I’ve been hypercritical on many levels - and you’d be forgiven for thinking that I’m angry or of the opinion that Apple is doomed. The answer, as always is much more nuanced. There’s areas where Apple was once the trail-blazer and now finds itself on the backfoot. Competition is stronger than ever - particularly when it comes to services. As a consumer this is great, and Apple can’t afford to be complacent. There are thousands of clearly-very-smart people at Infinite Loop, but at times it sure feels as though Apple is in a funny place in terms of product depth and breadth right now.

I wouldn’t be surprised if we see a few more iWork-esque growing pain moments (though hopefully on a lesser scale) where Apple re-normalises the importance placed on any one platform. And with the potential of adding some further mediums to the mix, it seems likely that we’re far from done with the growing pains.

After so many years of trying to find balance between the Mac and iOS, it finally seems as though the people building technologies and services are doing so in a way that not only brings them to Mac and iOS simultaneously but a way that solves the device-specific challenges for each technology. It’s not without risk or platform volatility, but with Apple’s platforms technologically re-united, the breathless pace of progress in the ecosystem seems like a dead-certainty - and the uncanny knack of deriving shared benefit from cross-device code is something that serves those building for iOS and Mac very well indeed.

Thanks to Dan, Isaiah, Chris, and Hamish for their feedback on this article. Later in the summer once things settle from WWDC I’ll be revisting where things are, so be sure to follow me on Twitter to read the follow-up.

Given the woes with Mail.app on OS X, and this baffling incompatibility with iWork documents, it’s easy to possibly read to much into an Apple-Google rift. But there certainly seems no love lost on Apple’s part by not fully supporting Google Apps. ↩
I’m not normally one to turn on homescreen badges for apps: but I did for Unread. I keep up to date on the small number of feeds I subscribe to, so Background App Refresh and a homescreen badge in-effect gives Unread a great chance of feeling like a first-party app such as Mail. ↩
Old-school power users would no doubt be outraged about this, but I’d love this. ↩
This is all conjecture on my part. I know as little as anyone else, but I like to think this would be a great start. ↩
iTunes Connect, and provisioning, are two areas where I find myself perpetually thinking: “it’s been six years”. Sure, developer infrastructure isn’t glamourous nor does it directly impact end-users. But iTunes Connect is a hugely-frustrating means to an end that now hinders the delivery of apps to Apple’s customers. ↩

Thoughts on the new OS X Beta Program

Nik Fletcher — Wed, 23 Apr 2014 19:45:00 +0000

Apple’s announcement yesterday of a more accessible OS X Beta Program is a surprising, and interesting, move both for Apple and third-party developers.

Apple has been continually (almost weekly, it seems) issuing OS X Mavericks pre-release builds for point-release updates. Given the wide variation in Mac hardware and software configurations, it seems prudent that Apple would want to widen the test base.

There’s been plenty of chatter about what it means for Mac developers having to support pre-release OS X versions, chatter that I suspect falls on deaf ears in the company of iOS developers - and it’s true that by placing OS X betas into the hands of more customers, developers will likely be hearing much quicker about problems. But I think this is a good thing: the end result is continually-improved apps (and OS X to boot). That’s not to say that it’s plain sailing: to pick on one particular problem - the ability of pre-release users to leave App Reviews is something that needs to be considered both on the Mac and iOS. (rdar://problem/9060111)

Then there’s the question of how this plays into another facet of Apple’s strategy: Apple wants you targeting (solely) the latest version of OS X. You’re fighting the toolchain right now if you’re wanting to go back beyond Lion (or even Mountain Lion in some cases). Nudges from paying customers to ensure you’re supporting the latest and greatest OS releases are a great way of forcing you to keep moving forward with the platform¹.

When it comes to the bigger picture though, this is perhaps my final thought… If you were Apple, and there were notable changes coming to OS X² - a platform that has only recently started moving at a similar pace to iOS - that you wanted to ensure that developers adopted, tested against and shipped, in a more timely manner wouldn’t this be the way you did it too?

The most interesting thing about Microsoft’s most recent OneNote for Mac release to me is that it’s Mavericks-only. That seems like a sign. ↩
The rumourmill certainly seems to suggest this one has legs. ↩

Apple’s Mac Apps and the Sandbox

Nik Fletcher — Wed, 23 Oct 2013 18:00:00 +0000

Each time Apple updates iLife or iWork, I always try to take a look at the updates’ usage of the OS X Sandbox. Apple is of course free to do whatever it wants (after all it’s Apple’s platform), and in the past Apple has simply used temporary entitlements to effectively escape the sandbox. However the lack of visible dog-fooding of the sandbox on Apple’s part to date has provided little reassurance to developers who may still be working to adopt the technology themselves.

Visual inspection of sandbox entitlements is a useful check, especially if you're curious about what other apps are doing, and after reading this post by Michael Tsai there’s a very simple way to do this using Terminal:

codesign -d --entitlements - /Applications/Keynote.app

N.B. There’s a space either side of the dash preceding the app path.

So that developers can quickly look at the change I’ve put together a repository on GitHub with all the details for Keynote, Numbers, Pages, iPhoto, Aperture, and GarageBand that launched with OS X Mavericks - it seems there’s some interesting stuff in the iOS updates too, but I’ve not yet taken a look for myself.

As you can see, there’s still some Apple private entitlements in use, and GarageBand escapes the sandbox entirely by using an absolute read-write path for not just your hard-drive but any external drives too:

<key>com.apple.security.temporary-exception.files.absolute-path.read-write</key>
<array>
    <string>//</string>
</array>

If you’re wondering about the sbpl temporary entitlements in some apps, Daniel Jalkut has a great article to explain.

For all the gripes about using these private entitlements (or in the case of GarageBand, an entitlement strictly not available for developers to use) it’s great to see that the iWork apps sandboxed for the first time and as someone who’s still working with the migration to sandboxing it’s reassuring to see Apple start walking the walk.

Update, 16th October 2014: I’ve updated the GitHub repo with the most recent iWork updates.

The Task of Proving Value for Paid Apps

Nik Fletcher — Wed, 09 Oct 2013 20:00:00 +0000

Another common gripe I didn’t touch on in Monday’s article is Apple making its iWork apps available free to new iOS device owners. (As a side-note, I think it would be fair to assume the same will be true of any new Macs that are on the horizon. Remember: one of Apple’s yet-to-be-played cards from WWDC is “awesome new releases for both Mac and iOS [iWork] suites” - but I digress).

Lots of folks posited that as a result of iWork going free, the bar for apps to prove their value has been raised - particularly those paid-for upfront.

I think there’s certainly an element of truth there, particularly in an App Store that expects apps for Free*. After all “If Apple can make their world-class productivity and creative apps free, why can’t you?”.

However, I firmly believe that the risk of devaluing apps isn’t as important to Apple as ensuring the platform continues to extend its reach. Apple’s job is to act in the best interests of the iOS (and OS X) platforms, ensuring the platform and its devices remain best-in-class. Remember how the Surface was marketed as the “only tablet with Office”?

Making the iApps free is an important strategic play - and it’s more important than any implication for paid apps - apps which Christina points out are possibly on life support at this point anyway (at least in certain categories on iOS). iLife has worked wonders to attract people to the Mac. The depth and full-featured-ness of the iApps echoed across each Apple device you buy is a force to be reckoned with - and a force of attraction for the platform that developers should consider to be in their longer-term best interests.

If you’re going to build a paid app, now would be a good hone your marketing plan. There’s still a market - a smaller market, perhaps, but a market nonetheless. The market “just” needs to know more about you, and the app you’ve been building.

“Offers In-App Purchases”

Nik Fletcher — Mon, 07 Oct 2013 19:00:00 +0000

“Offers In-App Purchases”. That’s a phrase that’s become more and more common on the iOS App Store in the last year - and starting with iOS 7 you’ll likely see even more frequently as there’s some interesting new additions to the world of In-App Purchase that will further change how developers monetise their apps.

Before I begin, I would reiterate “freemium” apps aren’t for every market. However it certainly feels as though mainstream apps, in a busy App Store genre, are going to have to adapt to the changing purchasing preferences of millions of iOS users.

Migrating to Freemium

Historically, moving to “freemium” (i.e. free up front, IAP later) was something of a minefield, with two possible ways to do it:

Add a mechanism allowing existing customers to keep their paid-for content, ahead of the app going free.
A new version of the app, freemium from the get-go.

There’s obviously considerations for the existing user base - folks who’d complain about the fact that they paid, and it’s now Free* (that is, Free with In-App Purchases). And the fact that any mechanism wasn’t 100% reliable in ensuring that existing customers got their content.

What’s New?

iOS 7 introduces a seemingly small, but very significant, addition to the IAP world - a digital receipt in every app (free or otherwise) that includes the version number when the customer originally bought the app.

With this new addition, for the first time it’s possible to move an app from paid-for to freemium (or lower-cost-with-IAP), whilst reliably ensuring the customer is able to access the features they originally bought. The receipt - something Mac developers already deal with on the Mac App Store - always returns the original version the customer purchased, even in the event of a reinstall.

It goes without saying that there are more considerations than just setting an app free with IAP. Having the right feature-set or perhaps “feature modularity” and arguably the right type of app are also important. However, with a single addition to the SDK Apple has highlighted the path they think best serves the platform, and the millions of customers who’re using it.

As my colleague Ted also pointed out one lunchtime as I sounded out ideas for this post, it offers the ability for developers to experiment with what works for them - if freemium doesn’t work then you can consider switching back. The only downsides being you need to manage version number logic and retain the IAP for the app, and the fact that even though you’re no-longer selling IAPs your app will remain advertised as offering them. For some, that may be a negative connotation (though how strong, or moot, a connotation is up for discussion).

The Proving of Value

The expectations of the mass-market have very obviously changed, as has the way developers balance the proving of value with running a (hopefully viable) business. Whilst before many apps worked on proving value prior to download / purchase, the mainstream app is facing a new challenge:

“Prove your value to me, and then I may spend my money”

That’s not to say that higher-priced apps aren’t feasible, just that it requires careful consideration as to whether an app would be better served by having a greater-than-$5 price [you have no idea how heavily my heart sank when writing that].

Paid Upgrades. Ish.

Sat in Session 308 at WWDC, it instantly became clear that this is how Apple believes consumer apps will evolve. Buy or download an app, use the features you bought and over time developers should monetise new features based on the new SDK addition.

It’s not paid upgrades in their current form – of course, there’s an argument to be made that the current form of upgrade pricing is being requested “because it’s how it’s always been done”. However this is quite clearly the paid-upgrade-of-sorts from Cupertino - and the option that serves Apple’s goals and customer base better.

In The End, It’s About the Platform

So what’s the part of the platform vendor in all of this? Whilst Apple’s not going to dictate how businesses bring in revenue, it’s very clear that IAP is the way that Apple foresees that mainstream apps should generate revenue. After all, nothing serves Apple’s platform (and Apple’s customers) better than thousands of high quality apps becoming thousands of high quality Free* apps.

A Final Thought

Throughout all of this, the (let’s say old-school, independent) developer community has found itself repeating an old adage (and I’m loosely paraphrasing):

I can’t believe that people with an $800 phone are complaining about dropping $3 on an app they use every day.

I think it’s time we retired this quip, along with paid upgrade gripes because – if I’m entirely honest – it reveals a lack of understanding for how a vast number of people actually purchase an iPhone, and how they might perceive the value of an iPhone somewhat differently.

The majority of customers, I’d argue, see the iPhone a bit like this: the iPhone is a device with little-to-no up-front cost, with payment made for the services that provide value. That sounds familiar…