It's that time of the year... both Google and Apple presented their new operating systems, Android 11 and iOS 14. Unlike other years, both developer conferences happened online and what usually are the biggest tech gatherings in the world, this time, we had to settle with video streams.
Both platforms put up a show and presented their latest advances in the world's most used operating systems. Like in previous years, both played catch-up with one another, adding similar features, tightening up security and privacy, and pretty much borrowing ideas from each other.
Android 11
With the June 10 launch of the first Android 11 beta, we could fully uncover what we first got a glimpse of since February when the first developer preview came out. Besides all the great improvements to the power menu, native screen recording, more control over app's permission, conversation bubbles, and context-aware dark mode, for us at Notificare, we are always excited with those features that directly impact our SDKs.
This year, the new iteration of Android will revamp how notifications are shown in the drawer. This will require no adjustments to your apps, but it will have some impact on the way users consume content through notifications. In this new version, communication apps will be able to benefit from the adjustments Google is introducing to the notification drawer with a new section called Conversations. All the other apps' notifications will have a secondary place in the drawer, considerably reducing the space and importance those messages have.
Another important change coming soon in Android 11 will change how your apps request permission for location services. In Android 10, there are already 2 types of location modes you can use, foreground and background. Now with Android 11, background location mode has to be explicitly allowed by the user in the device's permission settings for your app. This automatically affects your apps, and it will require some code adjustments in order to obtain proper permissions. If your app already follows best practices in requesting permissions and displaying an UI for the rationale behind location permissions, things do not change much for your app.
Apps can not request background permission right away, so in general, as a best practice, it is recommended that you start by requesting foreground access to location, this means your app will only collect the user's location while it is being used:
As you can see, there is now also an option for a Only this time permission. This is basically the same as While using the app, but in this case, the next time the app is launched, you will have to ask for permission again. For most apps, this is probably more than enough, but for apps using features like Geofencing, this mode will not suffice. This situation will now require you to rethink how you suggest and eventually prompt the permission rationale for background access. In our current SDK, we already provide you with the means to detect which mode users give you and helper methods to check for if you need to show a permission rationale. In our upcoming release, the default location permission request will be foreground only. However, you will still be able to upgrade the user's permission to background provided that you've implemented a clear explanation as to why this is needed for your app.
If your app targets Android 10 or lower, a device running Android 11 will automatically show the following system dialog when the app requests background location permission:
But if your app targets Android 11, you will need to provide the rationale yourself where you explain the need for background location permission:
After that, in both cases, the user will be directed to the permission settings screen:
One more change that might affect your app is the automatic reset of permissions, including location permissions, after the app is not used for a prolonged period of time. There are options to explicitly ask users to never reset permissions, but in general, most apps won't have that level of trust. Once again, this shows it is important to keep your audience engaged and the messaging features of the Notificare platform provide ample opportunities to keep your apps alive and active.
Once again, users are in control, and you should see this as a great thing. Gaining trust by providing a transparent and clear explanation about why you want to use such functionality is crucial. Once provided, you should also go the extra mile to provide real value to those users that allow your app to use these features.
iOS 14
Last week, Apple showed case all the new things coming to iOS, watchOS, tvOS, iPadOS, and MacOS. There was a plethora of announcements and incredible new things, from a new Apple Silicon chip for desktops to great new APIs and functionality for all their devices. Apple did also take some of Google's ideas and ran with it. Things like App Library, Home Widgets, and App Clips look very similar to what Android already has been doing for some time. Nevertheless, we do see a great opportunity for apps to take advantage and we are definitely supporting some of these ideas in our next release.
When it comes to existing functionality we currently provide, Apple is once again revamping privacy controls for Location Services. In iOS 14, they expand their initial thoughts over location usage in apps and introduce more restrictions to the way apps collect user's location. This translates to a whole new permission dialogue where users can (and will) be able to define a precision level for location updates:
As you can see, a new option is available, allowing users to define which precision level your app can use. If toggled ON, the accuracy of the location you receive in your app will be the same as prior to iOS 14 and features like Geofencing will be available. But users can easily toggle that option OFF and only allow your app to collect a location with a far less degree of accuracy as it usually would, rendering impossible to use features like Geofencing:
Once again, transparency in how you need a certain level of accuracy and a clear explanation about what they will miss will be a decisive factor for users to allow your app to use such features. Furthermore, with the next iteration of our iOS library, we recommend you to make some code adjustments for how you use location updates to provide a great user experience. Pretty much like explained for Android above, you should start by requesting a less intrusive mode and collect location only when your app is being used. Once users give you that permission and you have some time to explain why you need background location for Geofencing or Beacons, you should then prompt users to give you more access.
This effectively translates to adjustments in your location permission flow. You will have to use our upcoming new delegates and helper methods to provide UI elements that remind users when some features are not available due to stricter location or accuracy permissions.
All in all, we do think this move makes sense, since it is crucial that apps earn a certain level of trust and provide transparency in how this private data is used, before they can take advantage of features like Geofencing or Beacons.
Are you ready?
We are a couple of months away from an official release of these new operating systems. As of today, we are entering a new development phase for SDK 2.4, which will contain all the necessary features that will allow you to cope with these changes. So keep an eye in our announcements via web push on this website or by subscribing to our newsletter. As always, we are available via our Support Channel if you have any questions.