Challenges Implementing an iOS Share Extension
iOS is missing the concept of custom background service that apps and extensions can connect to, something that makes such problems simpler to solve on Android. On iOS we are stuck with two separate processes that can’t talk to each other reliably because the main app may or may not be running.
[…]
Luckily Core Data automatically handles file coordination for us, so we only had to move the database inside the shared container. Unfortunately, iOS versions between 8.0 and 8.3 had a bug with file coordination that cause deadlocking or data corruption. This means we had to disable the share extension in any iOS version lower than 8.3.
[…]
If the user hits the cancel button, or dismisses the share extension before that then the sharing process is aborted completely.
The alternative is to pick up the sharing process from the main app, but since there is no reliable way to start the main app automatically, this could happen hours later.
[…]
It is safe to assume that when a user sends content from the share extension, the main app is in the background. Wire’s solution, inspired by these posts [1] [2], is to save the content of save notifications to a file, every time there is a save in the share extension. When the main app comes to the foreground it check if such file exists. It then extract the list of object IDs that changed, and makes sure that the objects are re-fetched from the persistent store to get the most up-to-date information.
1 Comment RSS · Twitter
As a side note and heads up for anyone using Wire (the 'end-to-end encrypted' messaging app being discussed here): be aware that it currently stores your contact list and conversation metadata in plaintext on their servers: https://motherboard.vice.com/en_us/article/secure-messaging-app-wire-stores-everyone-youve-ever-contacted-in-plain-text
