Web app design question.

Am currently designing a new project and after seeing Jim’s progress with his web app, it’s made me think again about my design.

This project will primarily target iOS, then I’d like Android also, with desktop being an additional means of the user interacting with our application. This means I can create a client for platform that is basically a wrapper for an HTMLViewer.

I’ve figured out how to charge for the app, so the user pays once and can access across all platforms, which Apple will allow in their App Stores.

But I’m stuck with the second design decision, a lot of the customers we’re targeting do not have a data contract, and or would be easily be in situations where they’d be reliant on free wifi; which would render the app pretty much useless for a large percentage of our target audience.

So I need for them to be able to edit the data locally; then when they are connected to be able to sync their data. AFAIK this can’t be done with a web application right?

Otherwise I have to create a client for each supported platform and while Xojo is the best tool for this; I don’t want to have to manage several projects and constantly chase Apple, Google and MS, when they break my app once a year.

Any thoughts?

The fact that you are wanting to use an HTMLViewer doesn’t change the mechanics here. That’s simply the UI layer and it’s more complicated than native controls because you have HTML and the Javascript bridge.

Ultimately your host app will need to store data in SQLite/Valentina and manage the presentation layer. When connected to the Internet you can sync back/forth.

The downside to these situations is deciding if you absolutely must have sync. It’s hard to add sync later but it also adds a huge burden to development time if you don’t actually need it. Connectivity is pretty ubiquitous here in the states. More and more we can get by with no offline mode or limited.

For example what about a read-only offline mode? When the app starts up detect if they have a connection. If not then present the UI from SQLite like you always do but mark all the elements read-only. It’s a hack and its not great but it makes the app usable without requiring months of sync development.

Always best to test the market for your application before investing man power in niche or nuanced features for a minority of users.

If you were to literally just point your app to a cloud service well… that’s not really in the spirit of the app stores. Apple may allow it but you run into a dilemma that the desktop app doesn’t add anything useful to the equation.

Also, I read recently (the last 6 months) that Apple said that they would reject apps that were simply a wrapper for an htmlviewer.

Unfortunately, Xojo Web Framework is not suitable for this type of use. There are other tools and frameworks for this.

It would be nice already Xojo could handle short network disconnections: https://forum.xojo.com/13191-server-not-available-client-event

Thanks guys for the info, rather sadly that’s what I though. I guess the best approach is abstraction. Keep all the logic an a few non ui based classes that can be shared but the various apps that provide a UI.

Then basically create a new UI for each platform.

Originally I was intending to use iCloud for data sharing, as that’s pretty simple (he says) and would make it easy for a user to sync and share their data across multiple Apple devices. I might still go down this route for the first version, then look into my own sync solution for a later version.

I hear you, I do have some previous experience in creating syncing, so I’ll probably add the basic required properties to start with, but not actually write the engine.


  • recordUUID
  • userUUID
  • creationDate
  • modificationDate
  • groupUUID // — Right now, I’m not thinking about collaboration, but maybe in the future.

Web design is not exactly the same as native. You can perfectly well have the same UI for iOS and Android, and the same for Mac and Windows. Then you have to decide what to do with iPad, which is neither as minuscule as iPhone, nor as big as Desktop.

Have a look at RubberViewsWE, though. It can greatly help with this kind of fragmentation.