iOS - request PERMISSIONS.IOS.CALENDARS does not return the correct permission status

[mysport12]

Before submitting a new issue

• I tested using the latest version of the library, as the bug might be already fixed.
• I tested using a supported version of react native.
• I checked for possible duplicate issues, with possible answers.

Bug summary

Requesting the PERMISSIONS.IOS.CALENDARS and selecting 'Full Access' from the OS prompt returned a status code of 0 from [EKEventStore authorizationStatusForEntityType:EKEntityTypeEvent] in the completion handler resulting in 'denied' on the TS side. It seems as though for iOS17+ and the new method of requesting access, that the BOOL returned in the completion handler needs to be used to determine permission. I have modified the completion handler (screenshot below) and the request now returns the proper permission status based upon what is chosen in the OS prompt.

Additional Notes:
If I kept pressing the button in my app that calls the request function, after two or three times it would eventually return granted, but further requests to check or request the same permission would be inconsistent. After doing a bit of Google research, other examples of this workflow (requesting calendar permissions on iOS) only use a single instance of the EKEventStore instead of a new one each time a request for permission is made. Not sure if that is something worth exploring??

Other relevant env info:

iOS 18.1 physical iPhone 15 Pro
RN 0.76.3 new arch enabled

Library version

5.2.1

Environment info

System:
  OS: macOS 15.1.1
  CPU: (12) arm64 Apple M3 Pro
  Memory: 113.33 MB / 36.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 23.3.0
    path: /opt/homebrew/bin/node
  Yarn:
    version: 4.5.0
    path: /opt/homebrew/bin/yarn
  npm:
    version: 10.9.0
    path: /opt/homebrew/bin/npm
  Watchman:
    version: 2024.11.18.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/craig/.rvm/gems/ruby-3.3.5/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.1
      - iOS 18.1
      - macOS 15.1
      - tvOS 18.1
      - visionOS 2.1
      - watchOS 11.1
  Android SDK:
    API Levels:
      - "23"
      - "24"
      - "25"
      - "26"
      - "27"
      - "28"
      - "29"
      - "30"
      - "31"
      - "33"
      - "34"
      - "35"
    Build Tools:
      - 28.0.3
      - 29.0.2
      - 29.0.3
      - 30.0.1
      - 30.0.2
      - 30.0.3
      - 31.0.0
      - 33.0.0
      - 33.0.1
      - 33.0.2
      - 34.0.0
      - 35.0.0
    System Images:
      - android-28 | Google Play Intel x86 Atom
      - android-29 | Google APIs Intel x86 Atom
      - android-29 | Google Play Intel x86 Atom
      - android-30 | Google APIs Intel x86 Atom
      - android-30 | Google APIs Intel x86_64 Atom
      - android-30 | Google Play Intel x86 Atom
      - android-30 | Google Play Intel x86 Atom_64
      - android-33 | Google APIs ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2024.2 AI-242.23339.11.2421.12700392
  Xcode:
    version: 16.1/16B40
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.13
    path: /usr/bin/javac
  Ruby:
    version: 3.3.5
    path: /Users/craig/.rvm/rubies/ruby-3.3.5/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.1.2
    wanted: 15.1.2
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.76.3
    wanted: 0.76.3
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Steps to reproduce

1. Install the latest version of react-native-permissions with 'Calendars' specified in setup_permissions (Podfile)
2. request PERMISSIONS.IOS.CALENDARS and log the results

Reproducible sample code

async function requestCalendarPermission() {
  const res = await request(PERMISSIONS.IOS.CALENDARS)
  console.log(res)
}

[zoontek]

@mysport12 Thanks for the reporting.

After doing a bit of Google research, other examples of this workflow (requesting calendar permissions on iOS) only use a single instance of the EKEventStore instead of a new one each time a request for permission is made. Not sure if that is something worth exploring?

It currently uses a single EKEventStore instance. [EKEventStore authorizationStatusForEntityType:EKEntityTypeEvent] is a static method, available without creating an EKEventStore instance.

My rough guess is a race condition occurs in iOS internals.
Just shipped a fix to use granted in v5.2.2, that's should do the trick.

[mysport12]

@zoontek Thank you!!