In Expo 29.0 SDK it appears that the NOTIFICATIONS permission does not resolve when requesting Permissions.askAsync(Permissions.NOTIFICATIONS). It is working properly in 28.0.1. Not sure if this effects other permissions as well.
I tried to make a Snack for it, but the 29 SDK was not running for iOS or Android.
The promise did not resolve if I accepted or rejected the permissions. This was through the Expo application if that helps. Also, this issue only occurred when showing the operating system dialog and selecting a response; after that subsequent attempts to call askAsync resolved successfully or failed depending on what choice was made.
I also did not notice an issue with the Permissions.getAsync call.
same here, since Expo 29.0, I’ve noticed the same behaviour as described.
it is only in expo ios and ios standalone app, while in android standalone app it never happened since permissions already given as the app being installed.
When it comes to permissions on iOS (Expo Client) we are aware of an issue resulting in the permissions being handled improperly, we’re tracking the issue in https://github.com/expo/expo/issues/2042.
I am also having the same issue on a recent upgrade to sdk 29
if (existingStatus !== 'granted') {
Alert.alert(`we've asked for permission because status is ${finalStatus}`)
this.events.sendNotificationsAsked()
// Android remote notification permissions are granted during the app
// install, so this will only ask on iOS
const { status } = await Permissions.askAsync(Permissions.NOTIFICATIONS);
finalStatus = status;
Alert.alert(`we've asked for permission and received ${finalStatus}`)
}
on devices through testflight it will not resolve await Permissions.askAsync(Permissions.NOTIFICATIONS)
I will get the first alert but not the second.
on simulator through expo it will resolve as undetermined (as it always has)
this is a new issue with sdk 29
As a note, I am getting asked for permissions on ios, but it never resolved - haven’t tested android.
Another note, I have not detached which i can see is not supported at the moment from github issues. I am using a standard standalone app
if (existingStatus !== 'granted') {
// Android remote notification permissions are granted during the app
// install, so this will only ask on iOS
const { status } = await Permissions.askAsync(Permissions.NOTIFICATIONS);
finalStatus = status;
Expo.Segment.trackWithProperties('push.notifications.final.status', {
status
});
}
We call this after the user logs into our app but we never get the status and the Segment event is never sent.
We’re on 29.0.0 and this is causing a rejection from the App Store. Has anyone fixed this? Does it work if we downgrade to 28?
EDIT:
This is not a detached app. Just a regular standalone expo app.
My sincere apologies it took us so long to fix that bug. The fix is waiting for review and we’ll push it to Turtle builders ASAP so you can rebuild your iOS apps to see the bug fixed.
Let me at least explain what was the problem.
Let’s start with what’s included in every Expo Client or a standalone app at the moment:
an unversioned core, containing Kernel (services helping all the experiences access some specific devices’ APIs, like permissions or sensors manager) and ExpoKit, a central dispatch station for all the events that should be passed to different experiences (that is different applications running on Expo Client, eg.)
To be able to compile different versions of the SDK in one project, when a new SDK is released, we prefix files/classes/constants names with ABI_SDK_VERSION, eg. ABI_29_0_0. This way the compiler doesn’t complain about duplicate symbols and what not.
However, there are some constants values that shouldn’t change from version to version — they should be shared for all SDKs. An example of such constant would be EXAppDidRegisterForRemoteNotificationsNotification.
This is the name of the notification that is posted by ExpoKit on NSNotificationCenter when - application:didRegisterForRemoteNotificationsWithDeviceToken: is called on AppDelegate, so all interested parties (in that case all remote notification permissions managers) know that the user allowed the app to receive remote notifications.
The way we ensured that this constant will be left as it is by the versioning script was an EX_UNVERSIONED macro which did… nothing. See definition, usage example and versioned example.
The problem that caused this bug is that when moving Permissions API to a universal module we forgot about versioning that happens automatically when we release a new SDK version. In SDK 29’s expo-permissions module, EXAppDidRegister…was prefixed with ABI29_0_0 so Permissions was listening on NSNotificationCenter for ABI29_0_0EXAppDidRegister… which was posted there.
The solution was to ensure that the names match in every SDK version. To ensure this doesn’t happen in the future I’ve added k before EXAppDidRegisterForRemoteNotificationsNotification in all versioned and unversioned code. The versioning script won’t bother us anymore!
Sorry for the problems, everyone! I’ll let you know when we release the fix to the builders.
Hey, thanks for the quick response and for the detailed explanation of the issue
Due to the complexity of our login process (and the lack of detailed feedback from Apple) it took us some time to figure out what was happening so it’s actually really nice to know the root cause of this thing that has been causing us so many headaches haha.
)
The fix is waiting for review and we’ll push it to Turtle builders ASAP so you can rebuild your iOS apps to see the bug fixed.
