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.
Posts tagged with "developers"
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 MacStories1 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.
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.
I'm really glad that this year there's finally some pushback against the built-in watchOS faces. They're not enough. They've never been enough. Whether you prefer digital or analog time, the best of the current watchOS faces are merely 'bearable', not 'great' https://t.co/GmrFmMmb3Y
— Steve Troughton-Smith (@stroughtonsmith) October 9, 2018
Apple Watch faces are generally just SpriteKit scenes, or fairly-simple UIKit layouts; I'd love to see some third-parties actually design & build a few — SpriteKit is easy to prototype with on a Mac. Show Apple what they're missing out on
— Steve Troughton-Smith (@stroughtonsmith) October 9, 2018
I found a nasty way to remove the digital time label in a fullscreen WatchKit app, so now I can make beautiful watch faces 😜 pic.twitter.com/YSdmV75ySp
— Steve Troughton-Smith (@stroughtonsmith) October 10, 2018
As so many people were asking, I put my sample Apple Watch 'face' project on GitHub. If you want to use this as a jumping off point to prototype your own Watch faces, go nuts! https://t.co/sQu4UQ9WEy pic.twitter.com/OeogH3bFll
— Steve Troughton-Smith (@stroughtonsmith) October 10, 2018
Benjamin Mayo, writing for 9to5Mac:
Apple is rolling out a new TestFlight feature which enables developers to share a public URL for an app beta. Customers can simply open the link on their iPhone or iPad and automatically enroll into the beta testing group through the TestFlight app.
This feature was announced back at WWDC in June but has only just started showing up for developers inside the App Store Connect interface. Previously to public links, developers had to manually ask people for email addresses and then send out invite in emails to each person individually.
As someone who's routinely testing dozens of apps for review purposes, this sounds a lot more convenient than the current email-based invitation system, both for developers and users. By default, developers don't see the names and emails of users who sign up with a link. I have a feeling this option is going to be frequently used for public betas with large pools of testers.
Many app developers already provide privacy policies and are transparent about the information they collect from users and how they use it. I’m glad to see privacy policies become a requirement though because for some apps it’s not easy to track down how they use your data and there have been too many instances in the recent past where it’s been discovered that an app has used data in ways that users might not expect.