session-ios
session-ios copied to clipboard
oxen-io
Session installed from .ipa release hangs at launching screen on devices from BrowserStack due to unsupported entitlements by BrowserStack
Code of conduct
- [X] I have read and agree to adhere to the Code of Conduct
Self-training on how to write a bug report
- [X] I have learned how to write a bug report
Is there an existing issue for this?
- [X] I have searched the existing issues
Current Behavior
This is not a new issue. Session iOS works locally for "normal devices", but always hang on launching screen on managed devices from BrowserStack.
Edited:
- Technically this is not a bug of Session, see the explanation from BrowserStack support.
- At the moment it's tricky to solve because of com.apple.security.application-groups
Expected Behavior
Session on managed devices from BrowserStack should work the same as local devices.
Steps To Reproduce
- Create a new account on https://app-live.browserstack.com/
- In BrowserStack App Live: 2.1. SELECT SOURCE 2.2. Uploaded Apps 2.3. URL 2.4. input an URL of a Session ipa binary release, for example https://github.com/oxen-io/session-ios/releases/download/2.2.12/session-2.2.12.ipa
- Click
iOS REAL DEVICES-> 'iPhone', selectiPhone 13 + iOS v16.3 - BrowserStack will launch a new device and install Session automatically
After launching Session, it hangs at the startup screen. A user can use the "Show Home Screen" button to go back to home screen and use other apps, so the operating system is not hanging, just the Session app is hanging.
iOS Version
iPhone 13 + iOS v16.3, iPhone 11 Pro Max + iOS v13.3
Session Version
2.2.4, 2.2.12
Anything else?
I've reported this issue to the BrowserStack support team at the same time, it would be great if @mpretty-cyro or @RyanRory can provide some insights on this issue so BrowserStack team can better diagnose the issue.
If BrowserStack can be used to test Session iOS, it will be very useful for testing old devices / old systems and prevent bugs like https://github.com/oxen-io/session-ios/issues/819 in the future.
Here is the reply from BrowserStack, I'm still trying to digest what does that mean:
On analyzing the application files, we noticed that the application - "Session" is using certain entitlements which get excluded post the app is launched and this is the reason for the reported issue.
Please find the entitlement details attached.
Since you're uploading your app/IPA file to BrowserStack, we re-sign the app with our own provisioning profile so it can be installed on BrowserStack iOS devices. Unfortunately, our provisioning profile does not include support for some of the entitlements used by your application such as com.apple.developer.icloud-container-environment
- com.apple.developer.icloud-container-identifiers
- com.apple.developer.icloud-services
- com.apple.developer.ubiquity-container-identifiers
- com.apple.security.application-groups
The entitlements that are currently supported in our provisioning profile are as follows:
- application-identifier
- com.apple.developer.team-identifier
- get-task-allow
- keychain-access-groups
These Entitlements of your app are preserved when you install the app via AppStore or TestFlight and hence you do not face this issue while testing the app from AppStore.
Furthermore, if the app is signed with an Enterprise Signed certificate then we have support for testing iOS apps that make use of any of the iOS Entitlements. If you have Enterprise Signed IPA file, you will see a gear icon next to the apps, clicking on them should show you an iOS Entitlement option and you should be able to bypass the app signing process by toggling this button.
This feature is live now and you can enable it for any of your uploaded iOS apps (IPA files) by clicking on the ‘Gear’ icon next to the app’s name, from the list of uploaded apps on the 'App Live' dashboard. I am attaching a few screenshots for reference.
Click here (https://bit.ly/39uQAad) to watch a short video demonstrating the same.
Note: The functionality is only available for uploaded IPA files that have been signed with an iOS Enterprise Distribution Certificate (https://apple.co/2PkQCKY). Apps that are signed with Developer Certificate won’t be able to support Entitlement testing (Difference between Enterprise and Developer Certificate (https://bit.ly/3rE7Wb4)).
In this case, the app is not signed using an Enterprise Signed Certificate and hence you will have to try uploading the app via TestFlight or AppStore so that the entitlements are preserved and then the app should not crash.
Do give it a try and in case you face any issues, please feel free to reach out to us.
Hi @mpretty-cyro @RyanRory
Do you know what does these do?
com.apple.developer.icloud-container-identifiers com.apple.developer.icloud-services com.apple.developer.ubiquity-container-identifiers
https://github.com/oxen-io/session-ios/blob/master/Session/Meta/Signal.entitlements
I don't think Session using any iCloud service to sync data or configs, looks like legacy code inherited from Signal, is Session using any of them? Is it possible to remove them?
com.apple.developer.icloud-container-identifiers com.apple.developer.icloud-services com.apple.developer.ubiquity-container-identifiers
Yep you are right in what these are responsible for (granting CloudKit & iCloud Documents access - needed for storing files on iCloud to be synced across devices)
And yea we don't use them for anything so they would have been left over from Signal, we should be able to remove them without issue
com.apple.security.application-groups
The com.apple.security.application-groups entitlement is more tricky - it's needed because currently we store the database in an "AppGroup" folder so that the share/notification extensions can access it
I'm hoping to do some investigation into alternate approaches to this some time in the future when I have more time as the current approach is actually causing of the majority of crash reports we see, making it harder to identify the severity of other issues (the OS locks the database file when it's being accessed and if the device transitions between the app and one of it's Extensions too quickly it asserts because the OS already has a lock)
Unfortunately it's going to be a bit of a pain to refactor even if I can find an alternative solution 😞
com.apple.security.application-groups
The
com.apple.security.application-groupsentitlement is more tricky - it's needed because currently we store the database in an "AppGroup" folder so that the share/notification extensions can access itI'm hoping to do some investigation into alternate approaches to this some time in the future when I have more time as the current approach is actually causing of the majority of crash reports we see, making it harder to identify the severity of other issues (the OS locks the database file when it's being accessed and if the device transitions between the app and one of it's Extensions too quickly it asserts because the OS already has a lock)
Unfortunately it's going to be a bit of a pain to refactor even if I can find an alternative solution 😞
Thanks for the quick detailed explanation!
Yep can feel the pain. I asked BrowserStack how their other customers resolve the com.apple.security.application-groups issue, and they say:
As a workaround to the issue, our other customers usually opt to test the application via TestFlight or Sign the application with the Enterprise distribution profile.
The reason I like .ipa release is it doesn't require phone number or bank card to install an app. I was hoping to create some shared BrowserStack accounts for the community so any high engagement users can reproducing bugs using a fresh new and reproducible environment on BrowserStack and use the screen recording feature to save a video for the developers. This would be convenient for users with privacy concerns as they can try to reproduce their bugs on our devices with no personal data and record a video without privacy leak.
Now it seems hard at the moment.