Federico is the founder and Editor-in-Chief of MacStories, where he writes about Apple with a focus on apps, developers, iPad, and iOS productivity. He founded MacStories in April 2009 and has been writing about Apple since. Federico is also the co-host of AppStories, a weekly podcast exploring the world of apps, and Dialog, a show where creativity meets technology.
Apple needed to show developers that Carbon was going to be a real and valid way forward, not just a temporary stopgap, so they committed to using Carbon for the Mac OS X Finder. The Carbon version of Finder was introduced in Mac OS X Developer Preview 2, before Aqua was revealed; it acted a bit more like NeXT's, in that it had a single root window (File Viewer) that had a toolbar and the column view, but secondary windows did not. At this stage, Apple didn't quite know what to do with the systemwide toolbars it had inherited from NEXTSTEP.
It had taken Apple four years to find the new 'Mac-like', and this is the template Mac OS X has followed ever since. Here we are, eighteen years later, and all of the elements of the Mac OS X UI are still recognizable today. So much of what we think of the Mac experience today came from NEXTSTEP, not Mac OS at all. AppKit, toolbars, Services, tooltips, multi-column table views, font & color pickers, the idea of the Dock, application bundles, installer packages, a Home folder, multiple users; you might even be hard-pressed to find a Carbon app in your Applications folder today (and Apple has announced that they won't even run in the next version of macOS).
Fascinating read by Steve Troughton-Smith on how Apple transitioned from NeXTSTEP to Mac OS X between 1997 and 2001. The purpose of this analysis, of course, isn't to simply reminisce about the NeXT acquisition but to provide historical context around the meaning of "Mac-like" by remembering what Apple did when the concept of "Mac-like" had to be (re)created from scratch.
Apple is going to be facing a similar transition soon with the launch of UIKit on the Mac; unlike others, I do not believe it means a complete repudiation of whatever "Mac-like" stands for today. The way I see it, it means the idea of "Mac-like" will gradually evolve until it reaches a state that feels comfortable and obvious. I'm excited to see the first steps of this new phase in a couple of weeks.
For the past seven years, I've considered the iPad my main computer. Not my only one, and not the most powerful one I own, but the computer which I use and enjoy using the most.
I've told this story on various occasions before, but it's worth mentioning for context once again. My iPad journey began in 2012 when I was undergoing cancer treatments. In the first half of the year, right after my diagnosis, I was constantly moving between hospitals to talk to different doctors and understand the best strategies for my initial round of treatments. Those chemo treatments, it turned out, often made me too tired to get any work done. I wanted to continue working for MacStories because it was a healthy distraction that kept my brain busy, but my MacBook Air was uncomfortable to carry around and I couldn't use it in my car as it lacked a cellular connection. By contrast, the iPad was light, it featured built-in 3G, and it allowed me to stay in touch with the MacStories team from anywhere, at any time with the comfort of a large, beautiful Retina display.
The tipping point came when I had to be hospitalized for three consecutive weeks to undergo aggressive chemo treatments; in that period of time, I concluded that the extreme portability and freedom granted by the iPad had become essential for me. I started exploring the idea of using the iPad as my primary computer (see this story for more details); if anything were to ever happen to me again that prevented being at my desk in my home office, I wanted to be prepared. That meant embracing iOS, iPad apps, and a different way of working on a daily basis.
I realized when writing this story that I've been running MacStories from my iPad for longer than I ever ran it from a Mac. The website turned 10 last month, and I've managed it almost exclusively from an iPad for seven of those years. And yet, I feel like I'm still adapting to the iPad lifestyle myself – I'm still figuring out the best approaches and forcing myself to be creative in working around the limitations of iOS.
On one hand, some may see this as an indictment of Apple's slow evolution of the iPad platform, with biennial tablet-focused iOS releases that have left long-standing issues still yet to be fixed. And they're not wrong: I love working from my iPad, but I recognize how some aspects of its software are still severely lagging behind macOS. On the other hand, I won't lie: I've always enjoyed the challenge of "figuring out the iPad" and pushing myself to be creative and productive in a more constrained environment.
In addition to discovering new apps I could cover on MacStories, rethinking how I could work on the iPad provided me with a mental framework that I likely wouldn't have developed on a traditional desktop computer. If I was in a hospital bed and couldn't use a Mac, that meant someone else from the MacStories team had to complete a specific, Mac-only task. In a way, the limitations of the iPad taught me the importance of delegation – a lesson I was forced into. As a result, for the first couple of years, the constrained nature of the iPad helped me be more creative and focused on my writing; before the days of Split View and drag and drop, the iPad was the ideal device to concentrate on one task at a time.
Over the following couple of years, I learned how to navigate the iPad's limitations and started optimizing them to get more work done on the device (I was also cancer-free, which obviously helped). This is when I came across the iOS automation scene with apps such as Pythonista, Editorial, Drafts, and eventually Workflow. Those apps, despite the oft-unreliable nature of their workarounds, enabled me to push iOS and the iPad further than what Apple had perhaps envisioned for the device at the time; in hindsight, building hundreds of automations for Workflow prepared me for the bold, more powerful future of Shortcuts. Automation isn't supposed to replace core functionality of an operating system; normally, it should be an enhancement on the side, an addition for users who seek the extra speed and flexibility it provides. Yet years ago, those automation apps were the only way to accomplish more serious work on the iPad. I'm glad I learned how to use them because, at the end of the day, they allowed me to get work done – even though it wasn't the easiest or most obvious path.
When Apple announced the iPad Pro in 2015, it felt like a vindication of the idea that, for lots of iOS users – myself included – it was indeed possible to treat the iPad as a laptop replacement. And even though not much has changed (yet?) since 2017's iOS 11 in terms of what the iPad Pro's software can do, the modern iPad app ecosystem is vastly different from the early days of the iPad 3 and iOS 5, and that's all thanks to the iPad Pro and Apple's push for pro apps and a financially-viable App Store.
Seven years after I started (slowly) replacing my MacBook Air with an iPad, my life is different, but one principle still holds true: I never want to find myself forced to work on a computer that's only effective at home, that can't be held in my hands, or that can't be customized for different setups. For this reason, the iPad Pro is the best computer for the kind of lifestyle I want.
However, the iPad is not perfect. And so in the spirit of offering one final update before WWDC and the massive release for iPad that iOS 13 will likely be, I thought I'd summarize seven years of daily iPad usage in one article that details how I work from the device and how I'd like the iPad platform to improve in the future.
In this story, I will explore four different major areas of working on the iPad using iOS 12 system features, third-party apps, and accessories. I'll describe how I optimized each area to my needs, explain the solutions I implemented to work around the iPad's software limitations, and argue how those workarounds shouldn't be necessary anymore as the iPad approaches its tenth anniversary.
Consider this my iPad Manifesto, right on the cusp of WWDC. Let's dive in.
Introducing Adapt, a show where Federico Viticci and Ryan Christoffel challenge each other to do new things on the iPad. On this debut episode, Federico investigates being productive using third-party software keyboards, then he and Ryan discuss ways they use the iPad’s multitasking system in everyday life.
In the first episode of our new iPad-focused podcast Adapt – which we launched yesterday - Ryan challenged me to get work done on my iPad Pro using custom software keyboards. No spoilers, but I found the experience surprisingly fun and useful. We also talked about the current state of iPad multitasking and the changes we'd like to see in iOS 13.
You can listen below (and find the show notes here), and don't forget to send us questions using #AskAdapt and by tagging our Twitter account.
Warren Buffett and Tim Cook star in a new iPhone game, Stephen and Myke tried the official Twitter app for a week and Federico is exporting his notes. Elsewhere, Mark Gurman has reported on iOS 13 and new versions of macOS and watchOS.
A very special episode of Connected this week, which also includes some details on my Evernote experiment and our thoughts on recent iOS 13 rumors. You can listen here.
Thoughtful take by Jason Snell on the recent discussion around the idea that Shortcuts may be coming to the Mac and what that could mean for macOS automation. Snell imagines a scenario where Quick Actions, introduced last year with Mojave, could act as a bridge between old-school Mac apps and a new breed of Marzipan apps compatible (in theory) with Shortcuts only:
Something funny happened in macOS Mojave. Apple actually brushed off some very old Mac OS X technology, Services, and gave it a rebrand as Quick Actions. Quick Actions are commands you can find in Quick Look previews, the Finder’s new Gallery view, and on the Touch Bar. Some are pre-built by Apple, but users can add their own by saving Automator actions as Quick Actions.
I have no idea what prompted Apple to bubble up Automator actions into more places in the macOS interface with Mojave, but Quick Actions strikes me as a pretty good companion to Siri Shortcuts. Imagine a scenario where apps originating on iOS can support Siri Shortcuts via the same methods they use on iOS. Now imagine that Siri Shortcuts can also use Quick Actions as a source for potential commands. Quick Actions are contextual, those old-school Mac apps can bring their own Quick Actions to the party, and users can build their own Quick Actions to do whatever they want. It would be a simple way to bridge the gap between the two different app types that Mac users will be using together, at least for a while.
As I argued on Connected a couple of weeks ago, I'm intrigued by the idea that a Mac version of Shortcuts could have built-in bridges for old automation tools (shell, AppleScript, Automator, etc.) to at least trigger those scripts from the new app. Quick Actions would be a great fit for this; in fact, I find the whole idea of Quick Actions is well suited the Files app on iOS as well.
It’s been about a year and half since iOS 11 was released into the wild, and with it, the long-awaited system document browser. PDF Viewer was one of the first applications that truly went all in with this new component, and we did this by fully replacing our custom solution with it on devices that were upgraded to iOS 11. This move certainly got us a lot of attention and praise from power users, but it also caused a lot of frustration for others who were unlucky enough to stumble upon the bugs and limitations of this new component. From a developer’s point of view, it was a mixed bag as well. On one hand, it allowed us to stop developing our custom document browser, thereby saving ourselves a lot of valuable development time in the process. On the other hand, it forced us to make do with a system we did not own and couldn’t even “hack” around when there were problems.
PDF Viewer will drop support for iOS 10 shortly, which will get rid of the final remains of our custom document browser, so we thought it might be a good time to take a closer look at how its system replacement is doing and go over the good, the bad, and the ugly.
File management is one of the main sections of an in-depth iPad story I'm working on right now, and the document browser is a key functionality I'm going to describe in detail. Overall, I agree with Bukovinski's take: the document browser has brought consistency and speed to a lot of document-based apps, and I'm happy to see fewer custom file managers in apps these days, but it could use more customization options for developers, and the reliability of third-party file provider extensions is still largely hit or miss.