From the start, the iPad has always been rife with potential. This is partly because it launched as a new type of product category, with unexplored use cases prompting users towards a different computing experience. But it’s also because the device’s very nature – a slab of glass that becomes its software – evokes countless possibilities.
To celebrate 10 years of iPad, I spoke to the developers of many of the device’s best apps across areas of productivity and creative work. They’re the people who make that slab of glass into something new, realizing the iPad’s potential but also showing, by their constant work of iteration and reinvention, that there’s always more that can be done.
In sharing their stories from the last decade, the people I spoke with outlined some of the best and worst things about iPad development, memories of their reactions to the product’s introduction, and dreams for where its future might lead. All throughout, it’s clear how much excitement remains for the iPad’s potential even 10 years on.
Universal purchases, which will allow developers to offer an app across Apple’s platforms, are now available for Mac apps. In a short notice posted to Apple’s developer news site, the company said:
The macOS version of your app can now be included in a universal purchase, allowing customers to enjoy your app and in‑app purchases across iOS, iPadOS, macOS, watchOS, and tvOS by purchasing only once. Get started by using a single bundle ID for your apps in Xcode and setting up your app record for universal purchase in App Store Connect.
The feature began appearing for some developers on App Store Connect a little earlier in the day:
Prior to universal purchase, Mac apps were treated as separate products by Apple’s stores, which meant developers had to either charge separately for apps and, in some cases, jump through complex receipt-checking hoops to bundle their apps. This change should make the process of charging a single price or signing up for one subscription for apps across the Mac, iOS, iPadOS, watchOS, and tvOS much simpler and will enable cross-platform In-App purchases too.
Way back in 2016, in the era of iOS 9, I laid out the tentpole features I wanted to see come to iOS and the Mac. Now, three years later, so many things from that wishlist have become a reality that it’s probably a good time to revisit the topics that haven’t yet come to pass, and plan a new wishlist for the years to come. I originally planned this list to have a Developer/User split, but it became clear that the two go hand-in-hand; if you’re doing complex things on iOS today, using the various automation apps, you are but steps away from needing the same things that developers do.
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.
In writing about Workflow (then) and Shortcuts (now) for a living, at some point I realized that if I wanted to build more complex shortcuts to either deal with web APIs or store data in iCloud Drive, I had to learn the basics of parsing and writing valid JSON. The format is behind most of the web API-based Shortcuts I have shared here on MacStories and is one of the techniques I recently explained on Club MacStories when I built a shortcut to save highlights from Safari Reading List. The beauty of JSON is that, unlike XML, it’s cleaner and more readable – provided you have a dedicated viewer that supports syntax highlighting and/or options to navigate between objects and inspect values. There’s no shortage of such utilities on macOS, but this is the kind of niche that still hasn’t been fully explored on iOS by developers of pro apps. That changes today with the launch of Jayson, created by Simon Støvring.
Readers of MacStories may be familiar with Støvring’s name – he’s the developer behind one of the most powerful and innovative pro apps of 2018, the excellent Scriptable for iOS. For this reason, it shouldn’t come as a surprise that Jayson, a project that was born out of Støvring’s personal frustration with the lack of a modern JSON viewer for iOS, has that same spark of innovation and integration with native iOS functionalities that set Scriptable apart last year. If you do any kind of work with JSON on your iPhone or iPad, you need Jayson in your life, and here’s why.
Fascinating deep dive by Craig Morey on whether it’s possible for a front-end web developer to get their work on an iPad Pro in 2018.
It’s a highly technical read, and ultimately Morey doesn’t believe an iPad Pro is ready for this task yet, but it’s worth pointing out that many of the issues outlined by Morey are applicable to anyone who uses an iPad as their primary computer today. For instance, the problem with Files APIs, introduced in iOS 11 and still not widely adopted by third-party document-based apps:
I’ve already posted about the messy landscape of options for moving and accessing files in iOS. The only way apps should be doing it currently is with iOS 11 style file APIs, but many apps have either legacy file solutions, bespoke (ie, confusingly different — and differently-abled) file pickers or would rather pull you into their own cloud platform.
Apple need to evangelise the right way to do this before basic file management turns off the potential users before they get to the inspiring parts of iPad usage. But to really make it work, app developers need assistance to update older apps to the latest APIs. Many app devs spent huge amounts of time building custom solutions before any good options existed, only to see little in terms of revenue to encourage them to rewrite their app as new APIs came along. The iPad Pro marketplace needs to be turning a corner in terms of viability to bring these apps back into the modern iOS world.
Make sure to watch the videos in Morey’s piece – I love how he detailed every single step of the workflows he tried to build on his iPad Pro.
To help developers take advantage of the latest features of the iPad Pro and Apple Pencil, Apple has posted two new videos to its developer portal. Even if you aren’t a developer though, the videos include interesting insights on some of the unique features of the new iPad Pros.
The videos cover development and design issues that should be considered when adapting apps to the new iPad Pros like using safe area insets to avoid crowding content into the rounded corners or under the home indicator. Another consideration to take into account is that unlike the previous iPads, the 11” iPad Pro doesn’t have a 4:3 aspect ratio, which means apps hard-coded to those dimensions will have areas cut off at the top and bottom.
Also, apps that don’t link against the iOS 12.1 SDK will run in a compatibility mode when multi-tasking, which will add an inset at the top and bottom of the screen for both apps instead of running them fullscreen. Apple says that making sure iPad apps can handle the inset compatibility mode will also help with bringing iOS apps to the Mac in 2019.
The Apple Pencil has a set of default double-tap settings that we covered in our iPad overview, but developers have the option to customize the double tap action in their apps. Apple also encourages developers not to hide functionality behind the gesture or turn custom actions on by default.
The videos cover the iPad Pro’s new USB-C connector too. The iPad Pro supports HDR 4K up to 60Hz and external displays up to 5K as well as USB audio devices, Ethernet, and MIDI. The iPad Pro can also send simultaneous USB-C outputs, which permits uses like connecting a DSLR Camera and 5K display to the iPad Pro at the same time.
The new videos are available as part of Apple’s Tech Talk series.
You can also follow all of our Apple event coverage through our October 30, 2018 hub, or subscribe to the dedicated October 30, 2018 RSS feed.
In a brief post on Apple’s Developer news site, the company announced that it is adding support for app bundles to the Mac App Store. According to the post:
…now, you can create app bundles for Mac apps or free apps that offer an auto-renewable subscription to access all apps in the bundle.
The post points to developer documentation on creating app bundles that that has been revised to mention Mac apps. The process for setting up a bundle, which will allow developers to offer up to 10 Mac apps as a single purchase, appears to be the same as it is for iOS developers. Unfortunately for those developers with iOS and macOS apps, it does not appear possible to create a mixed bundle of iOS and Mac apps.
Last week we linked to Marco Arment’s article critiquing Apple’s watch faces and calling for Apple to open up watch face design and development to third parties. By the next day, Steve Troughton-Smith had an Xcode project up and running that uses SpriteKit to simulate custom watch faces. Troughton-Smith posted pictures of the watch faces he created on Twitter, which drew a lot of interest from other developers.
Troughton-Smith uploaded his watch face project to GitHub, and in the days that followed, developers, including David Smith, who’s been making Apple Watch apps for his health and fitness apps since the Series 0 was introduced, began playing with Troughton-Smith’s code. Writing about the experience on his website Smith said:
There is something delightful about solving a problem that is superficially so simple and constrained. The constraint leads to lots of opportunities for creative thinking. Ultimately you just need to communicate the time but how you do that can take countless different forms. It reminds me of the various ‘UI Playgrounds’ that have existed in app design. For a while it was twitter clients, then podcast players and weather apps.
I spent the weekend following along as Troughton-Smith, Smith, and others designed all manner of personalized watch faces. The experience reminds me of the flurry of activity and excitement during the first months after the iPhone was released when developers reverse-engineered Apple’s APIs to create the first jailbroken apps even before there was an App Store. Let’s hope that history repeats itself and Apple opens up watch face development to third parties like it did with apps.
Below and after the break, we’ve collected tweets following Troughton-Smith’s work and showing off some of the designs that have been created over the past several days.