Posts tagged with "developer tools"

The Developer Debrief on WWDC 2020

Weeks removed from Apple wrapping up its first all-virtual WWDC, many of us are still digesting what the conference’s announcements mean for the future of our favorite products.

Federico, John, and I have all shared various takeaways from the conference, and I’m sure we’ll have a lot more to report as we continue using the betas this summer and review Apple’s OS updates this fall. But our perspective is limited to our profession as journalists, so we also wanted to hear from the people this conference was really built for: developers.

WWDC has grown into an exciting conference for Apple users all around the globe, but its core identity is still ultimately an event for app developers. As a result, I wanted to speak with a variety of developers to get their reactions to the conference. These included:

My sincere thanks to these developers for taking the time to share their thoughts, and for their years of valuable contributions toward making Apple’s app ecosystem as strong and robust as it is today.

Interview questions for each developer ranged from the things that most excited them at the conference to surprises and disappointments, their read on how in-touch Apple is with the developer community, the current evolution of software development, and each developer was also generous enough to share a sneak peek at new technologies they’re working to implement in their apps.

Read more


WWDC 2020: All the Little Things in Apple’s New OS Releases

WWDC week is always full of big and small announcements about Apple’s core software platforms. Monday’s keynote only has time for sharing a limited number of details, however, so as the week goes on many new discoveries are made as developers and writers delve into the first beta OS releases themselves. As a result, we always have a roundup of new things to share midway through the week. So today, on top of everything detailed in our overviews of iOS and iPadOS 14, watchOS 7, macOS Big Sur, and tvOS 14, here’s an assortment of extra goodies that will be arriving on your devices this fall.

Read more


Apple Shares Open Source Resources for Password Manager Apps

Today on Apple’s developer site, the company announced the release of new resources for password manager apps:

Apple has created a new open source project to help developers of password managers collaborate to create strong passwords that are compatible with popular websites. The Password Manager Resources open source project allows you to integrate website-specific requirements used by the iCloud Keychain password manager to generate strong, unique passwords. The project also contains collections of websites known to share a sign-in system, links to websites’ pages where users change passwords, and more.

The open source project can be accessed on GitHub.

Apple has continually deepened its investment in the area of password management with iCloud Keychain upgrades in recent years and new APIs for third-party apps. Today’s announcement takes things a step further down the path of openness and collaboration, enabling apps to share important site-specific information with one another so that users have the best, most secure experience possible no matter their choice of password manager.

Permalink

WWDC, A Wish List (2019 Edition)

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.

Read more


(Don’t Fear) The Reaper

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.

Permalink

Apple Answers Two-Factor Authentication Questions Raised by Developers

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.


Inspecting JSON Files on iOS with Jayson

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.

Read more


Front-End Web Development on an iPad Pro in 2018

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.

Permalink

Apple Rolls Out TestFlight Public Invite Links

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.

Permalink