Every summer, Apple releases new announcements of what’s coming next, and dev shops around the world get to work building the required changes and implementations.

While there are lots of reviews and analysis on what the new requirements mean for consumers, a less common conversation is what the new requirements mean for builders and maintainers of apps.  Whether you build apps yourself, have one that was built for you, or are considering a build in the future, here is SmartLogic’s take on the upcoming changes in iOS 13 and what they mean for you.

Dark Mode

Dark mode, an option to toggle apps to a night-friendly light-on-dark theme, sounds super simple and like a nice usability addition.

But from a design perspective, dark mode potentially adds a lot of overhead, because all of your designs will need to have two versions, and you’ll also need to figure out how to toggle between those states. It’s not yet clear whether apps will have access to system level dark/light status, so it’s also not clear yet exactly what that user interaction will look like.

From a tactical design perspective, dark mode is really only going to be manageable if you already are using a modular, componentized set of interface elements and styles. Even then, though, you’ll need to make extra considerations around any images you use, including transparency and outlines as needed. You’ll also need to build separate interaction styles for dynamic elements in both dark and light modes.

From our initial research, it’s looking like early adoption on dark mode will primarily be limited to high-end apps or apps where the main use case is at night or in a dark space. Many apps that are used in these types of environments have already made the switch to a dark UI (think Netflix in particular). We get the sense that a lot of the design community is in “wait and see” mode, holding off on making the investment in the additional design work needed for dark mode until there’s a clearer sense that this isn’t just a passing fad. To be fair, though, Android has been slowly rolling out dark mode support since the release of Android Pie in 2018, so Apple isn’t exactly on the cutting edge here.

Apple Sign On

OAuth (Open Authorization) is the mechanism that allows you to sign in to an app or service with another existing account, like your Google or Twitter login. As of iOS 13, Apple will be requiring all apps that use OAuth to include Apple as an OAuth provider. They’re also requiring that Apple be listed first in all iOS apps (and your web version — but they don’t actually have any review authority there, so it’s not clear what, if any, ramifications that has).

Clearly, Apple is trying to push their ID service as a competitor to other services that many consumers think of as a primary web identity. They’re also positioning this move heavily as a “more secure” option, following a number of data breaches and privacy violations from other tech giants. While it’s hard to take too seriously a play that ultimately just feels like they want you to give your data to them instead of their competitors, the Apple ID service may be a bit better from a user data privacy perspective. We also suspect it will be integrated with Apple’s on-device authentication, namely fingerprint and Face ID, which will likely be a nice convenience factor for iOS users. Not a lot of details are forthcoming yet, so much remains to be seen on this front.

Assuming that Apple sticks with the existing OAuth standard (and let’s hope they do), the amount of extra work needed to add Apple OAuth is probably similar to other 3rd party login integrations, mostly requiring configuration, rather than extensive development. This move does feel a bit heavy-handed, as they are basically forcing thousands if not millions of app developers to add and prioritize their login option. True to Apple form, they’re coercing participants in their ecosystem to eat the expense on a costly, inconvenient Apple-centric dictate. We’re all going to do it, but we’ll complain about it all the same.

New ‘Allow Location Once’ Option

In previous versions of iOS, location permission was limited to three options: “Always,” “Never,” and “When in Use.” Apple is adding a fourth option, Allow Once, which from a user privacy perspective is overall a nice thing to have. Instead of always allowing location, users can choose each time whether to allow an app access to location data. Before, if a user ever said “No” to a location prompt, the app could never ask again, and the user would have to go through the system menus manually to make that change.

The new Allow Once option gives users the ability to grant permission on an ad-hoc basis, providing more flexibility for both users and app builders.

The additional work this case is going to generate is primarily around any framing screens that app developers have made. It is a good design best practice to prime users before asking for permission, clarifying what the app is asking for, why, and how to answer if you want to allow. Apps that have these framing prompts included will need to update them to accommodate for the new option.

SwiftUI

Swift itself is not new; it is a programming language designed for building iOS applications, and was first released by Apple in 2014. SwiftUI is a new declarative framework for Swift that makes it easier to use to build user interfaces across the iOS platform. SwiftUI is not likely to replace tools like React Native or Flutter that allow developers to build both iOS and Android apps using a single codebase. That said, SwiftUI seems poised to become the new standard for apps designed exclusively for iOS.

iPadOS

With iOS 13, Apple is adding another branch to the iOS ecosystem, iPadOS. While iOS already has a few flavors including watchOS and tvOS, this split between iPhone and iPad has some new ramifications for app developers.

In the past, the biggest distinction between iPhone and iPad apps was scale: developers just needed to ensure that assets were provided at the correct size and that interfaces functioned well at both iPhone and iPad sizes.

With iPadOS, the iPad will now have functionality that iPhones do not, including split screen, gesture controls, homepage widgets, access to external drives, and mouse support. App developers targeting iPads will need to consider these new capabilities and customize their iPad app builds more than they have in the past in order to deliver a quality experience.

Second verse, same as the first

It’s always exciting to hear about the new shiny changes, but ultimately at this point for developers, the news coming out of WWDC is just the latest round of annual updates. While there are a few substantial changes to keep track of, a lot is staying the same in terms of tooling and approach. The way we build apps isn’t fundamentally changed by these new requirements; just tweaked a little.