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 "developer tools"
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.
A week ago, Apple sent an email to developers announcing that it would require two-factor authentication for all developer accounts beginning February 27, 2019. The message linked to an Apple two-factor authentication support page that applies to all Apple IDs. The trouble was, the support page didn’t answer many of the developer-specific questions that were immediately raised.
The concern I’ve heard voiced most often by developers is whether someone who uses one Apple ID to log into their developer account would be able to do so using an Apple device that is logged in using a different Apple ID. Today, Apple published a new support page answering this and many other questions. Specifically with respect to the two-Apple ID scenario, Apple’s FAQ-style support page says:
Will I need a trusted device dedicated to my Apple Developer account if I enable two-factor authentication?
No. You’ll need to use a trusted device to enable two-factor authentication for the first time. However, you can use the same trusted device for multiple Apple IDs that are enabled for two-factor authentication. Additionally, if you do not have access to your trusted device, you can get your verification code via SMS or phone call. When possible, you should use a trusted device to increase security and streamline the process.
The document covers many other situations as well including:
- How to check if you have two-factor authentication enabled
- Configuring an iOS device or Mac to accept authentication codes for multiple Apple IDs
- Enabling multiple trusted phone numbers that can receive authentication codes
The support page concludes with a link to a contact form for Apple’s developer team to raise any other circumstances that prevent a developer from enabling two-factor authentication.
Although it would have been better if this level of detail was published when Apple’s initial email went out to developers last week, the company has clearly heard the concerns raised by the developer community and has put together a thorough explanation that should address most situations. By answering the most common questions, Apple Developer Relations will hopefully be freed up to deal with any outlier issues that aren’t addressed in its support documentation.
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.
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.
Paul Miller, writing for The Verge, argues that Swift Playgrounds, while an amazing tool to learn the fundamentals of coding and Swift, ultimately doesn't let kids build real apps:
The Swift Playgrounds fantasy of what ARKit is like is closer to an ad than a tutorial. I’ve actually worked on an app using Apple’s ARKit and SceneKit APIs directly. I got stuck when my API call to Apple’s sound playback system wouldn’t work, despite all my best efforts at debugging. Writing software with Apple’s APIs is a powerful but difficult practice, and Swift Playgrounds’ penchant for hiding true complexity makes it hard to recommend for someone who doesn’t want to just “learn how to code” but instead wants to build something.
Apple would do its learners a huge service by providing them an Xcode equivalent on the iPad. Not because it would suddenly be easy to make applications and release them on the App Store, but because it would give iPad-bound learners a chance to engage that challenge and grow into true application developers in time.
I agree with Miller. I've been crossing my fingers for an iPad version of Xcode ever since the first-generation iPad Pro in late 2015. From aspiring programmers who would have a chance to see their creations on the iPad's Home screen (without using a Mac) to developers who could create commercial iPad software on their own iPads, the iPad needs Xcode. If coding is as important as learning a language, the lack of Xcode for iPad is like not having a keyboard to express our thoughts.
Apple has released version 2.0 of the Swift Playgrounds iPad app. The app provides an interactive learning environment for the Swift programming language. With version 2.0, Apple has introduced subscriptions to playgrounds from third-party creators. According to Apple’s developer news site:
You’ll automatically see new and updated playgrounds in your subscriptions, a content gallery that shows all playgrounds in a single view, new robots, and much more.
Subscriptions can be added by entering a URL or by browsing a gallery Apple has created, both of which are accessible from an ‘Add Subscription’ button in the top right-hand corner of the screen from which you add new playgrounds. As of publication, the buttons for adding subscriptions from the gallery do not work, but they should soon. When updated playgrounds are available, you can receive a notification too. Among the first third parties with subscription-based playgrounds are Sphero, Lego Mindstorms, UBTech, Parrot Drones, IBM, Mekamon, Wonder Workshop, and Skoog.
In addition to subscriptions, the update includes enhanced documentation for the Swift programming language and iOS SDK, and playgrounds can be opened from the Locations button in the Files app.
There are a seemingly endless number of ways to represent colors. Whether you’re a professional designer or developer, or someone who just wants to update a website template, you’ve undoubtedly come across several. The trouble with so many different formats is that it guarantees that at some point, the color value you have won’t be the one you require. Aquarelo is a beautifully-designed new Mac app that cuts through the thicket of formats to help you find the colors you want and convert them to the format you need.