New look for modals in iOS apps
With iOS 13, Apple brings a new look to modals, i.e. when you need to focus your user’s attention on making a choice or performing a task other than their current task. Going forward, the ‘sheet’ presentation style – right-hand screen in the screenshot below – will become the default design, and the recommended style for non-complex tasks.
While the top edge of the underlying content remains visible, all uncovered areas are dimmed to focus the user and prevent interaction with them. Users can still tap a button to dismiss the card and return to the previous screen, but they can also do so by swiping down.
What can I do?
While this won’t bring any dramatic changes, take the opportunity to make sure you’re delivering the best user experience. Keep the following tips in mind:
- Only use modals when there’s a clear need or benefit.
- Keep modal tasks simple, short and narrowly focussed – don’t forget a clear title
- Always include a button that dismisses the modal view, even if the user may also swipe.
- To help users avoid data loss, ask confirmation before closing a modal view.
- Make sure the modal view coordinates well with your app.
- Choose a transition style that makes sense in your app and keep the transition style consistent.
- Remember that alerts interrupt your user’s experience, so use them sparingly.
Android catches up on restrictions to background activity
With Android 10, apps running in the background will no longer be able to start activities.
This brings Android more in line with Apple’s strict guidelines for how and when apps can run in the background, the goal being to minimise interruptions for users and give them more in control of what’s shown on their screen.
If your app only starts activities as a direct result of user interaction, then most likely your app won’t be affected by this change.
However, apps with alarm functions will be severely impacted, since the alarm functionality will no longer work unless the app is opened in the foreground.
What can I do?
If your app needs to start in the background, create a notification to let the user know what’s happening or what they need to do.
And while this may require changes to your app, remember that it also brings benefits from both a user experience and app developer perspective:
- A heads-up notification that lets your user answer or reject a call, or dismiss an alarm, means that the user keeps control over what’s on their screen.
- Your incoming call or alarm respects the user’s Do Not Disturb rules.
- If you provide a full-screen intent, this is launched immediately if the device’s screen is off.
New foreground services attributes for android 10
When your app uses a foreground service to let your users know about activities going on in the background, e.g. a data sync for Fitbit or location tracking for a running app, Android 10 needs to know the type of foreground service.
What can I do?
Make sure to include the foregroundServiceType in the service tag of the AndroidManifest. Available types include phoneCall, mediaPlayback, location, dataSync, and connectedDevice.
Apple takes your privacy to the next level
Privacy is one of the hottest topics around, and Apple has recognised that control over our own data and information is critical to today’s users. The new ‘Sign In with Apple’ option, and changes to location permissions are two features that need to be on your radar.
Sign In with Apple
Apple has developed a unique approach to compete with social login, i.e. using existing information from a social media account like Facebook, Twitter or Google+, to sign in to a third-party app or website.
With ‘Sign In with Apple’, users can use their Apple ID to sign in to iOS apps and websites. Using this option, apps can only ask for a user’s name and email address – no more sharing friend lists or date of birth. And going one step further, users can even request that Apple creates a unique ‘burner’ email address that forwards to the user’s real one, keeping real email addresses out of spammers’ hands.
As of iOS 13, apps in the AppStore that already provide third-party login will have to offer ‘Sign In with Apple’ as one of the login options, and app updates will be rejected if this is not the case. Note that this will also apply to webview login for iOS apps.
Changes to location permission settings with iOS 13 put the user right back in the driving seat when it comes to determining just what location information is tracked and when.
- Location in foreground: In addition to the existing options ‘Don’t allow’ and ‘Allow’ (while the app is in use), apps will also offer ‘Allow Once’.
This permission will be stored during the session (and a limited time after) and will let the app access the user’s location. When the user closes the app, the location permissions are set to ‘not determined’, and when he/she reopens the app, the same pop-up will be displayed, asking once again for permission to use the location.
While of course you would like your users to grant more permanent permissions, this one-off chance lowers the bar for them to give your app’s location features a try. And if they like what you do, maybe they’ll be back!
- Location in background: Any use of the user’s location in the background triggers an alert that gives them the option to change their permission from ‘always allow’ to ‘only allow while using the app’. Users are also shown a map that clearly indicates where and when the app was tracking their location.
What can I do?
First of all, take the opportunity now to review your location code to make sure you’re only requesting this data when it can bring real value for the user. And where the user experience really can be enhanced by sharing their location – or conversely, be greatly limited by not sharing – help your users understand this by being open with them, and explaining it to them (well, the main points!).
They’ll be much more likely to grant permission – even if the first few times it’s only ‘Allow Once’ – if they trust you and believe in the benefits. If you don’t take action, the introduction of the map feature could result in users seeing worrying amounts of location tracking, and subsequently, revoking permissions.
Also, keep a careful eye on the ‘Allow once’ feature – make sure that the OS doesn’t change the location permissions to notAuthorized instead of notDetermined after the session. If this happens – or if in the future this evolves to ‘Allow only once & don’t ask again’ – location access would be denied after the first session, and the user might not even be aware of the limitations.
Again, make sure your users understand how sharing their location benefits them!
Ready, set ... Go!
Are you ready to embrace the changes that iOS 13 and Android 10 are bringing? Not quite?
If you’re looking for extra support on any of the features mentioned above – or any others that these new releases will bring – don’t hesitate to contact us. Drop us a line at firstname.lastname@example.org and we’ll be happy to arrange a chat!