>>>Since my target audience is iPad Mini (which means Safari) I quickly googled for IndexedDB and Safari on iOS and found claims that IndexedDB on iOS8 and 8.1 are buggy. This is bad.
>>
>>I read a blog which claims using the same id in too separate datastores then the record in one gets deleted ;-{
>>
>>> So I need to create a real case of customer data (which is not so easy) to see if localStorage is enough.
>>
>>Do they need *all* of the data from the server for off-line use or could they work with a subset ?
>>
>>> Another approach is to tell the customer that storing locally is not an option and store on the server. Actually I am pretty much convinced that I won't be able to deliver the program that will work in a completely disconnected fashion (that it, with no WiFi).
>>
>>If you can get passed the storage problem then I'd guess that the biggest problem, if multiple users are updating data off-line, would be synchronizing back to the server.......
>
>You see, I am creating an application that will be used by many customers (even though right now only one is willing to beta test it). In my experience every customer will require a different approach. Some may be willing to work with a data sub-set. Others will say, "I want it all and I want it now" :) And as I mentioned, I see so many issues in making the application work off-line (mainly because the pages are all ASP.NET web forms and the code is in the code behind) that I gave up on the idea of working completely off line. I will still store all various lookup tables to the local storage so that the pages load faster (rather then going to the database on every new page). But as far as this particular feature, I am concerned that the data storage will be a problem. This is why I am inclined to store it on the web server. And the user will load it from the server rather than from the local Storage.

Well you could always write a IPad or Android app version - that will give you 4GB for data (more on IPad) :-}