This Week's Sponsor:

DEVONTHINK

Store, Organize, and Work the Smart Way

Posts tagged with "developer tools"

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

The Xcode Cliff→

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.

Permalink

Apple Releases Swift Playgrounds 2.0 with Third-Party Subscriptions

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.

Aquarelo: A Beautifully-Designed Mac Color Utility

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.

Read more

Coding on iOS Is More Feasible Than Ever Before

In a series of tweets yesterday, one of the developers behind Codea announced that a new version of the iPad coding app had been approved for release, and this update would enable code sharing for the first time.

Previously we covered the revised App Store guidelines that now permit downloading and executing code inside of apps, but we haven’t seen those changes put into practice before now. With version 2.3.7 of Codea you can now import projects from both .zip files and .codea bundles, making it easy to share code with others.

Although Codea is the first prominent adopter of features made possible by Apple’s newly-granted permissions, it certainly won’t be the last. Other notable programming apps and IDEs like Pythonista and Continuous can follow suit as they so choose. These policy changes, combined with Apple’s own entrance into iOS coding via Swift Playgrounds, all of the sudden make iPad a much more attractive programming environment than ever before.

One excellent example of the power of coding on iOS is a game called Starsceptre. Starsceptre is a retro-style arcade shooter that was coded entirely on an iPad using Codea. Creator Richard Morgan wrote the game primarily during his daily commute on a train. “My work commute is basically the only spare time I have, so I needed a way to make games in that time – on the move, on my iPad.” The game’s trailer is embedded below.

With the less restrictive new App Store policies on coding, and the upcoming power user iPad features in iOS 11, hopefully we will see a lot more examples of apps coded entirely on iPad going forward.

Apple’s App Store Guidelines Now Allow Executable Code in Educational Apps and Developer Tools→

Apple made several changes to the App Store Review Guidelines during WWDC this week, including an easing of the prohibition against downloading and executing code on an iOS device. The ban on executable code remains intact, but rule 2.5.2 now also provides that:

Apps designed to teach, develop, or test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.

The change to the guidelines is limited, but it’s an important signal to third-party developers that Apple will accept certain educational apps and developer tools on iOS, which brings the promise of app development on iOS one step closer to reality.

Permalink