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.
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 remain1.
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.
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)3.
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 attention2.
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.
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.
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.”
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.
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 system4.
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.
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 5.
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.
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 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.
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.
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.
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.
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”.
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. ↩