Super interesting, but for the enterprise software crowd I don't think those lessons be applied 1:1, the complexity of such a solution in enterprise apps will b

Super interesting, but for the enterprise software crowd I don't think those lessons be applied 1:1, the complexity of such a solution in enterprise apps will be higher. Why? Conflict resolution is costly and if coupled with a delay can be irrevocable. This means you need as much data validation and associated business logic offline in your app to prevent the user from even saving wrong data in the first place. Some customers will want their users to work disconnected during their whole work day to save on data costs. Again, think global, data plans are not the same between the US and Brazil, for example. Even if permitted to work online, the work environment the user enters might prevent them from going online. Think hospitals, where mobile phone usage is restricted in certain areas or is simply blocked through an active MRI machine in the vicinity. The amount of data needed locally will likely be higher than in consumer apps. A fully offline capable model to ensure maximum independence of connectivity needs a mix of sync mechanisms that should follow their respective business use cases. Conflict resolution and error handling is not exactly simple in such an environment, pervasive logging is key - plus a way to sync down app logs to the online backend. Users can freely fiddle with time/date and locale settings on iOS devices for example, which can wreak havoc on your sync logic - being able to backtrack such events is key when dealing with customer support issues.