Obstacles to a genuine iPad Pro workflow.
That does the icon above mean? I mean, it started life as a “share” icon of course. But on iOS it has come to mean so much more, in fact it’s now listed as the “Action (share)” icon. It’s the most common point of entry to a secret UI, a dumping ground for all the options that are normally structured and discoverable in a desktop OS.
You might use it to share a picture to twitter. Or you might use it to send a file into another app, create a PDF, reveal extra app settings, run an SSH command, transpile a SASS file into CSS, edit the current document’s filename, tag it in a git repo.
All these options and more are randomly distributed in two carousels (the reason for two is increasingly unclear as the amount of functionality increases), hidden in a pop-over — the UI paradigm of choice where the purpose and scope is unclear at time of design sign-off. And believe me, I’ve committed exactly this sin before now on websites for the very same reason.
The action (share) icon is the most obvious symptom of my frustration with the iPad Pro. It aspires to pro-level workflow but crams it into an OS and ecosystem that without enough examples of what good workflow looks like.
First a definition of “pro” work in my own field. I’m a front-end web developer. In theory all I need is a 1998 PC, notepad.exe and an FTP client. But it’s not quite that simple any more. My Mac tool-chain is a mix of text IDEs, git clients, graphics apps, Chrome devtools and terminal gobbledygook.
On Mac and Windows, what we know as modern pro-app UI came out of early Apple apps (MacWrite, MacDraw), and was fleshed out by the mega brands like Microsoft Word and Adobe Suite. Everything after that was a variation on the theme because people had an expectation of where to find basic functionality and could commit it to chemical memory, getting on with the job of solving creative problems.
iOS has a more bumpy history of UI development. It was developed as a new way of building a small-screen consumer OS with limited inter-operability between apps — for security, stability, battery-efficiency and speed (especially on early ARM chips). Sure, the sidebar, the swipe and the action (share) icon are everywhere, but there exists no pattern for basic functionality that anyone can agree on. Want to delete a file in a list? You figure it out.
Even when it comes to sharing files between apps, an obvious solution isn’t always clear. Before the “files.app” came in iOS11, the iPad’s idea of a file hierarchy was a grid of icons for each app. It was flat, safe and very simple.
Reading that back I wonder why I bother trying to do anything that remotely looks like web development on iOS (and full disclosure — I work on a Mac 95% of the time). But times have changed. The hardware in an iPad Pro is measurably quicker, lighter, more efficient and in some ways more interesting than a mid-spec MacBook. And for about half of the price — or for the newest cheap iPad, a quarter of the price. iOS11 has unlocked possibilities that bring a measure of parity to MacOS in some areas, and even adds a few new tricks too.
But here’s the gotcha. This landscape of hardware, OS and particularly apps is developing in a very fast and a very, very lumpy way. And the resulting environment currently discourages most people like me from dipping anything but a toe in the water.
I’m sure if you’re a writer or a photographer, you might disagree that the iPad workflow is totally broken. Because that’s often how Apple portrays pro work — as visual and creative arts, and those workflows are catered for a great deal. But for the industrial complex that is the web development industry, ironing out a tool-chain in iOS is sometimes comically painful.
What does a good pro-dev iOS app look like?
So it’s not a lack of pro-level functionality within an app that makes iOS fall down as a web-dev platform. On the contrary, I’ve found working inside Working Copy, Textastic, Coda and other apps really very rewarding, and some are developing new functions that rival the best desktop apps at a frightening rate. Sure, we have gaps (good multi-file search-replace, solid auto-suggest, NPM environment, good browser devtools), but even those gaps seem to be closing. Working Copy — now I’ve learnt the UI — might be my favourite git client on any platform, it’s that good.
No, it’s that the grey areas in UI and glueing together apps into a workflow that lets it down, and the large SDK leaps (eg, between iOS9 and 11) mean that the mix of app generations in the landscape just muddles it more.
Some apps are technically bang-up-to-date (eg, Working Copy, Textastic), with great hooks into all the latest APIs. But even then, the UIs between these apps are incredibly inconsistent. Is the file rename function hidden behind a swipe? Or tapping the file name? Or somewhere under the magic “action (share)” icon? Sometimes it’s a combination of swipe and then and clicking the previously hidden action button to open a pop-over. How do I carry out operations on multiple as well as single files, and show which options are unavailable to multiples? Which apps offer a location in the files.app sidebar, which simply store files in a global folder on the iPad, and which have no access at all?
The differences between apps are tricky to navigate with only a few of them. How would this scale with the amount of pro apps I use on my Mac? Will I have 40 app locations in the files.app sidebar in a possible future when they all support file provider API?
Each iOS developer is left to juggle with what is achievable within the frameworks given to them by Apple and what seems correct and doable by their own definitions (throwing in available time, money, experience and aesthetic taste into the pot too). With the extablished goal of minimal UI chrome in iOS, discoverability is already generally pretty low, but the lack of common patterns for similar actions between apps doesn’t help.
I’m sure iOS devs will attest to the amount of support requests for functions that actually already exist in the app, but weren’t discovered — I’m definitely guilty of this (Sorry Textastic & Working Copy…).
Other pro apps, eg the otherwise excellent Panic Coda, have a codebase that grew up before the brave new world of iOS10/11 and therefore only serve to confuse users with massively different conventions. Coda has clever, bespoke UIs and integrations with Transmit to carry out functions that later APIs have brought to apps essentially for free, but they behave in a confusingly different way.
Meanwhile the economics of iOS apps at the pro end offer little incentive for developers to rewrite apps to the latest APIs. Did I mention Panic discontinued Transmit iOS? That’s because they couldn’t afford to keep a developer on it — it just made no sense in a company that has offices and salaries and a future to think of.
Panic is not Adobe, who could probably swallow the cost of a rewriting large chunks of an app as a part of the CC subscription revenue, but they’re also not a one-person-team who often take on too-much for too-little, largely out of love of the journey. All three of these types of publisher need help in lifting iOS as a pro platform for Apple to call it a success.
And Apple need this to work, because MS Surface & Chrome OS are beginning to understand what makes the iPad great, faster than iOS is coming from the opposite direction to break out of being just a consumption device. The Mac alone might not be enough to appease this fickle industry.
But we’re left in this muddle of Apple marketing talking about Pro devices, the iOS team delivering new radical functionality (at least for iOS), with some UI paradigms that are too often left to interpretation, and a bunch of apps that have such a range of different UIs and API capabilities that it’s hard to visualise what an ideal iOS11 iPad app should look like.
How is this mess straightened out?
If Apple want this to work, and with The cross-platform marzipan project I can only assume they want some Pro app crossover between Mac and iOS, they need to work harder on evangelising good iOS pro workflow UI guidelines, alongside shipping the new APIs.
Maybe Workflow/Shortcuts in iOS12 is the key — but I don’t really want another pipeline app handed to me like Automator for Mac — unless it’s genuinely flexible enough to get deep hooks into legacy apps. Because the present reality is that app publishers often don’t have the incentive to update to the crucial iOS11 iPad capabilities, let alone the next big thing. They’re too busy adding notches to their iPhone apps that pay the bills.
But that brings us to the thing that would really fix this problem.
Investing in people.
Apple need to be investing in it’s developer relations team to really reach out and help these independent developers level-up their apps (possibly with actual money or dev-time) to show off their WWDC iOS12 pro iOS landscape with apps that inter-operate in a genuinely productive way. And not just for two weeks in June every year.
There are currently a handful of decent web dev apps out there, many by one-man-bands — this is not a huge investment. Apple, don’t wait for these iOS devs to come to you, spend some of that $trillion on going out to them with UI and technical support, and providing a forum for them to collaborate on what the next gen of web dev could look like. Turn this workflow lemon into a golden egg.
Without support or incentive, iOS on the iPad Pro will never really break out of it’s “luxury internet device” and “Wacom replacement” category it’s created. It will never become a “truck” in Jobs parlance or gain the traction it needs to make pro iOS app economics work. And that’s before we even talk about xCode.
I want a future where I could leave the Mac occasionally for an iPad Pro. To be able to swap-out apps in my iOS tool chain because they have interesting and unique features based on (and yes, extending) common UI and filesystem paradigms, as defined by the class-leading apps that mesh together in an effective flow. One where my cognitive load is placed on solving project challenges, not on solving dev platform UI and workflow road-blocks.
On the back of the iPad Pro I’m typing on right now, it simply says “iPad” in Apple San Francisco type. I sometimes wonder if it’s just too coy to reveal it’s full name. I would like it to be confident enough to spell out it’s full name without any excuses.
PS — as a web dev, forgive my mis-labelling of native app development concepts and APIs… call me a user with just enough knowledge to cause trouble.
