iOS 13 is now out. It’s not wildly different from previous releases, but it’s a significant update which brings many new features, some of which will require some thought and effort to make keep your app working optimally, and other changes which might allow you implement new capabilities in your app.

iOS users tend to upgrade to the latest OS relatively quickly, so it’s important to make sure your app looks and works as you expect on the new OS as soon as possible. Historically about 50% of users upgrade within the first two weeks of the release, and about 65–70% update within two months.

I’ve listed the most important considerations you need to make in order to keep your app up to date and feeling fresh.

Dark Mode

There has been a trend of apps adding dark themes in recent years. Apple added a system-wide dark mode to macOS Mojave last year, and both iOS and Android are introducing system-wide dark modes in their OS releases this year. So users will come to expect that your app supports dark mode too.

There are several reasons why a user may choose to use dark mode: it can reduce power usage (if you have an OLED display), it can improve visibility for users with low vision or who are sensitive to bright light, or it could just be a personal preference.

It is assumed when building against the iOS 13 SDK that your app supports both light and dark mode. The system will do most of the work for you, especially if you are using standard views and controls. Xcode 11’s new Environment Overrides tool makes switching between dark mode and light mode a breeze to quickly toggle between the two modes and ensure your app looks great in both.

If for some reason you need to build against the iOS 13 SDK but haven’t yet had the time to support dark mode, you can opt out of dark mode, but this should only be done as a temporary fix so that your app is still legible to users while you work on improvements to dark mode support.

Sign In with Apple

Sign In with Apple is similar to Google Sign-In and Facebook Login in that it’s a quick and easy way to sign in to apps and websites without having to fill out a form to create another account, choose and remember another password, and verify your email address.

What sets Sign In with Apple apart from the others is that it has greater respect for privacy. Unlike Google or Facebook, Apple doesn’t make money off your information, and they don’t track users as they interact with your app. Data collection is limited to the user’s name and email address.

Sign In with Apple is also a smoother experience. When you tap the Sign In with Apple button, a sign-in sheet is presented showing the user what information will be made available to the app (name and/or email), and if the app requires an email, allows the user to select between their actual email or a temporary email address. All that’s required is to authenticate with TouchID or FaceID. Now your app has a secure, two factor authenticated account.

If your app already uses another third-party sign-in system, you will now be required to offer Sign In with Apple as well (once it is available later this year). Documentation on best practices and implementation details are available on Apple’s developer site, and the Introducing Sign In with Apple talk at WWDC 2019 includes a demonstration on adding Sign In with Apple to your app.

Location

iOS 13 brings in some changes to the way requesting a users location works. Previously you could ask for permission to access a users location when the app is in use. If the user gave permission, you could also later ask for permission to access the users location in the background. Alternatively you could ask for background permission first, but in any case, if the user denied permission, you could not prompt them for permission again later.

Now the options have changed to “Allow While In Use”, “Allow Once”, and “Don’t Allow”. There is no longer the option to grant background use permissions immediately. Instead, if the app requests background permissions, the user will initially be shown the same dialog as if the app only requested While In Use permissions. If they allow access, sometime after the app enters the background, another dialog will be presented giving the user the option to allow in the background as well, or continue to only allow while in use. iOS will choose the appropriate time to present this, and won’t necessarily be shown immediately after the app goes to the background, for example, if the user is switching to another app.

Some users can be very hesitant to share their location with your apps and can miss out on key features of your app. The new temporary use authorisation option will help encourage users to grant location access and make use of those features.

If the user chooses the “Allow Once” option, your app will have access to the users location until the app enters the background. When the user opens your app again, you’ll need to request authorisation again. You shouldn’t ask for this immediately — you should consider what caused you to ask for location in the first place. If the user doesn’t expect you to continue using their location from the previous time — don’t ask as soon as you enter the foreground. Wait until you actually require the users location again.

In iOS 13 if your app uses the background location permission, from time to time, iOS will show the user where the app has accessed the users location, along with an option to revoke the background location usage permission, so now it’s more important than ever to access the users location only when they expect you to.

Design

SF Symbols

SFSymbols is a collection of more than 1,500 symbols that can be used in your app. In the past we’ve used FontAwesome for any icons other than the limited number of icons iOS used to provide.

There are a few advantages that SF Symbols has over FontAwesome. SF Symbols are available in a broader range of weights and scales, they have alternative text labels that improve accessibility for people with visual impairments, they’re the same icons that are used in Apple’s apps — so you can maintain a similar look and feel in your apps, and if you can rely just on SF Symbols, it’s one less dependency you have to include.

Card Style Sheets for Modal Presentations

The new card style sheet is the default presentation style for modals which has been used in both the Reminders and Music apps. The benefit of this is that it gives a little peek of what’s in the background, which gives context to the user.

Cards can be dismissed by swiping down anywhere on the screen which is more comfortable than tapping a back button in a navigation bar, particularly on the bigger phones.

Because this is becoming the default presentation style, it’s a good idea to check your apps and make sure the sheet style uses the most appropriate style.

iPad

iPadOS

iPad has been built on the technical foundations of iOS, but it’s certainly no longer “just a big iPhone”. iPad has evolved into so much more with multitasking like Slide Over and Split View, the Apple Pencil, and external keyboards. This year iPad now runs iPadOS which is designed to take advantage of the larger display.

The most significant addition this brings is the ability to support multiple windows of the same app, which can significantly increase productivity in particular apps.

iPad Apps on the Mac

Last June at WWDC, Apple showed a sneak peek at their cross-platform project that would enable iPad apps on the Mac. It’s called Catalyst, and it’s available to use now.

Ideally your iPad app should already support multitasking, drag and drop, and respond to keyboard shortcuts including common macOS shortcuts.

You won’t get a perfectly working macOS app by just checking the box to enable a macOS build, but with some refinements and optimizations, you can get a natively running macOS app that takes advantage of your existing code base, significantly reducing the amount of work that needs doing.

A Few More Things…

Launch Screens

Storyboards have been the preferred way to implement launch screens since iOS 8. Starting in April 2020, apps that link against the iOS 13 SDK must provide a launch storyboard in order to be accepted in the App Store.

Layout

In the past, if you didn’t update your app to support new device screen sizes, your app would be letter-boxed. Apps built against the iOS 13 SDK will make use of the whole screen regardless, so check your app looks good on all screen sizes — particularly the newer devices with a notch.

TestFlight

Testers can now send feedback about your TestFlight app by taking a screenshot and adding text. They can also send feedback with a crash report after a crash occurs.

Compatible Devices

iOS 13 no longer supports iPhone 6, iPhone 6 Plus, iPad mini 2, iPad mini 3, or iPod touch (6th generation).

I’m excited for the privacy and productivity improvements that iOS 13 introduces. I recommend checking out Apple’s iOS 13 features page, along with the iOS Human Interface Guidelines for more details.