It turns out that this is a very complex problem. In providing data (this is not a security type situation yet, although it may become one due to the aspect of confidence), there is ALWAYS an element of time. As a simple example, what happens if your use locally updates a piece of data. Just before you can completely push data onto some cloud services, etc., He / she uploads it to the toilet. Even if there was a good signal for transmitting data, there is time in the transmission and the time required for the cloud server to respond that the data was received correctly.
As a rule, in ensuring the reliability of the data you really have to work as efficiently as possible. You will NEVER be able to solve all the problems, because there is no data center, no links to the data center, etc .... this is perfect. There is always a chance of data loss. Truly the best you can do is SYNC as fast as data changes, and if there is a loss of connection, as soon as the connection comes back to life.
Now for security. Security alone does not create confidence. If the data itself is something that the client does not want to lose, and this is his only requirement, then security is not needed. If he / she is also concerned that others are getting their data, then you should be concerned about the data in transit (both up and down during synchronization) and the device itself. For the best possible security, encrypt data locally on the device before clicking on the cloud. There are many known attacks that, even when using SSL or other services, can receive data. If you want, encrypt the file locally, then you can still use SSL for some additional security (at this point you will be encrypted twice). You also want to sign the data so that there is little chance of being manipulated along the way, or by the cloud server itself (if the hacker broke into the cloud server). As a rule, to protect data on the device, you can choose to let the user enter a password and set some fairly strict rules regarding how passwords are generated and how many attempts you allow before banning attempts for 30 minutes or so.
You can also save data locally in encrypted form. Thus, if someone receives the device, they still need a password before they can get the data (unless, of course, they can crack the algorithm that you use to generate the symmetric key from the password).
As for the online data service, you can use iCloud, etc. I'm actually not a fan of anything cloudy. I think this is an SO counter of enterprise / patented data, this is not even funny. I think it’s actually almost ridiculous that many of these phone / device manufacturers are based on SOOOOO. I think that they are abandoning large companies, since not a single large company that I know wants to host their proprietary data on a cloud server, THEY DO NOT CONTROL. In any case, I would say that as long as you have a good local encryption scheme before sending data, then you should be fine. In terms of confidence, I would look at where the servers are located in the locale. the reason is that if data confidence is paramount, most large IT installations like to have replicated data centers on opposite sides of the country / world, etc. The reason for this is that an earthquake removes a data center on one side of the country; most likely, it will NOT remove one located on the other side of the country at the same time. If iCloud data centers or everything you can find is essentially in the same region, then you can consider synchronizing with one data center on the west coast and choose a completely different data center (in this case, a company) to synchronize centered on the east coast.
This is a very high level of how you could implement this on an iPhone that we could talk about, but I hope this at least starts to help pave the way.