5

How much time do items live in general pasteboard?

Apple's documentation says:

The general pasteboard is persistent across device restarts and app uninstalls.

What I have:

  • Two (or more) apps signed with profiles with different team IDs;
  • Apps have to store theirs custom url schemes in a common place;

What I'm going to do:

  • Use [UIPasteboard generalPasteboard] to store these schemes in order to be accessible from all those apps.

What I need:

  • Those apps need to have access to this common "storage";
  • To be sure that pasteboard items will persist during a long period of time (always :-));

General pasteboard is persistent. That's clear, but is not clear about items lifetime in this pasteboard.

Basically the questions is: can I use general pasteboard as an inter app storage (for long periods of time) ?

Updates:

P.S. I understand that this is not a good (correct) approach but I need that all those apps to know each others schemes, so one shared storage and accessible at any time is required (I can't expect when the user will open all those apps). I need a solution without involving a backend.

Alex Maimescu
  • 230
  • 2
  • 8

1 Answers1

3

can I use general pasteboard as a inter app storage (for long periods of time)

No. The general pasteboard is meant to allow applications to share data in response to an explicit user action. It's not meant to be a common database or repository. In fact, no other application is required to (nor should they) save the existing contents when writing to the general pasteboard. Your URL schemes would be overwritten with the very next copy the user initiated.

MyztikJenz
  • 1,650
  • 14
  • 19
  • If having your apps talk to the network isn't an issue, having them register their schemes on a server someplace is a reasonable solution. Storage persistence is then entirely up to you. If a server is not reasonable and if the schemes don't change all that much, you could have the user drive an exchange of the schemes the first time the app is launched. App A switches to App B to get the schemes then switches back to install them locally. It's not the most idea solution but if it's a one-time thing, not that intrusive. – MyztikJenz Dec 12 '13 at 17:45
  • Actually the problem is that all apps (A, B and so on) have registered their custom (unique) url schemes, and app A doesn't know the scheme of app B. The idea is that all apps need to know about each other (no backend). So regarding your answer, how can I switch from app A to app B if I don't know it's scheme? – Alex Maimescu Dec 12 '13 at 17:56
  • Hmm... good point. Without a common scheme, it'll be difficult for the apps to learn about each other. If the user knows A and B can be connected, perhaps they could provide a "pairing" UI where one app puts a private type on the general pasteboard (containing its scheme) and then instructs the user to launch the other app. Other app then looks for this type on the pasteboard and confirms to the user it learned about the other app. If the ability to connect apps is not apparent to the user, then this wouldn't work... but one could argue that's a problem in its own right. – MyztikJenz Dec 12 '13 at 18:36
  • 1
    How can a common url scheme solve the problem? When we define the same custom url scheme for multiple apps then iOS behaviour is undefined (from Apple's docs: "If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme."). So I can't choose which app to open A, B or other one, iOS will make this choice for me. – Alex Maimescu Dec 12 '13 at 23:04
  • 1
    Sorry, s/common/known/. You are correct that the behavior for schemes registered more than once is undefined, which is very unfortunate. – MyztikJenz Dec 12 '13 at 23:37