This diffs enables usage of App Groups in NotificationService and Comm so that they can securely share files - e.g. SQlite Database
Details
Details
Not testing plan for this diff. Its child will introduce functions that use App groups to share SQLite database between NotificationService and Comm that will have testing plan.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| native/ios/NotificationService/NotificationService.entitlements | ||
|---|---|---|
| 7 ↗ | (On Diff #12494) | Can you link any resources for how to determine this name? It seems a bit strange that the TLD is group here |
| native/ios/NotificationService/NotificationService.entitlements | ||
|---|---|---|
| 7 ↗ | (On Diff #12494) | This doc suggests that app group name starts with "group." on iOS: |
| native/ios/NotificationService/NotificationService.entitlements | ||
|---|---|---|
| 7 ↗ | (On Diff #12494) | The docs mention a "group name", and you've opted for app.comm there which is our bundle identifier. Is that a standard practice? Can you link some docs to show that it is a standard practice? |
Comment Actions
I found this piece of apple docs: https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_application-groups?language=objc, which suggests that developers are not restricted to any particular group name scheme. However I have also found docs for two iOS 3rd party app extensions:
https://doc.batch.com/ios/advanced/app-groups and https://documentation.onesignal.com/docs/ios-sdk-app-groups-setup that use the following schema to share data with the main app via app groups: group.<bundle id>.<3rd party extension name>. Therefore I would assume that it is a good practice to name app group like group.<bundle id>.<extension name> if it is meant to share data between app and app extension. Based on those findings I could change group name from group.app.comm to group.app.comm.notification_service, but on the other hand the reason we are creating this app group is that we want notification service to share SQLite database with the main app. If we ever use another app extension that would need to access sqlite database it should also be in this group so group.app.comm.notification_service will no longer be valid. Renaming this app group would be troublesome as we would need to implement another SQLite migration. In conclusion I suggest that we name this app group with something like: group.app.comm.sqlite_dependent. @ashoat @palys-swm let me know what you think.
Comment Actions
Great research!
Do you know if one app can be a part of multiple app groups? E.g. our main app and notification service extension would be one group, our main app and other extension the second, etc. If that's the case we have greater flexibility in choosing the name. Regardless, I don't have a strong opinion but I don't see a good reason for not choosing group.app.comm. It looks like any other app we will add, could also require access to the same db, so it's quite universal. Having a name that specifies a dependency sounds risky, because if there are more common dependencies, we would need to update the name. From the examples you provided, it looks like the groups are used for third-party extensions - if we ever introduce one (unlikely), we will create a separate group for it.
Comment Actions
Thanks for that research, @marcinwasowicz! Agree with @palys-swm's reasoning – I think group.app.comm is probably fine, but am curious if it's possible for an app to be part of multiple app groups.
Can you clarify why you planned changes? I was going to accept the diff, but I'm not sure if I should now.
Comment Actions
Answering two questions here:
- https://developer.apple.com/documentation/xcode/configuring-app-groups?changes=latest_minor, This doc explicitly state: "Apps can belong to more that one app group".
- I hit "plan changes by accident". I intended to do for diff D3370 after rebasing it and made silly mistake since it begins with the same word "Enable".