Hello,
sorry, if this was asked already, but I didn't find anything.
Is it possible, to make a simple VCL-App with TAdvWebBrowser and load a WebCore-App from the local file system (AdvWebBrowser1.LoadFile(...))? I tested it with a very simple webcore app and get a "... has been blocked by CORS policy".
Is there a way to get it running?
Regards
Harald
A TMS WEB Core application needs by default a web server (http server) to serve the resources associated with the web app (like the form HTML files)
If you do not want to use a web server, you could use the direct form mechanism (but then you can't have form HTML templates)
This is explained here:
This is interesting. I watched the video and am left wondering how this works. It it just for the dev environment? Or does a Direct Form app tow the server along with it when it gets deployed, kind of like a self-serving app? Is it explained anywhere?
Direct forms have nothing to do with development mode or not. It is designed for any WEB Core app if one does not want that the framework by itself will always load (perform a HTTP request for that) a HTML template belonging to the form.
Thank You very much for Your answer. I had found already the video about direct forms - and it would be something to consider. At the moment - for my current project - this is not really what I need. (I'd like to use html templates and bootstrap.)
I tried with an in-process-webserver using sparkle server, but you have to register this server address with the httpsys tool. This would be to complicated for every client just to start my program. So I decided against sparkle server and tried Indy http server and this works fine.
I really would like to only use sparkle but this an another question.
Kind regards
Harald
If you want local access, have you considered Miletus? It packages up the whole thing in a tidy .exe file?
Miletus actually wasn't on my radar. Thanks for pointing it out. It's not suitable for my current project (I want to display a webcore page in a form that is integrated via a dll), but it's good to keep in mind for future projects.
There are always lots of options. I like that Miletus can take a TMS WEB Core app and bundle everything (just like an electron app), and then it is treated like a typical VCL app when it comes to deployment. This is handy in many situations.
Have the host environments changed? I think Miletus only supported Windows and maybe MacOS, but not mobile platforms. Is this still the case?
From the doc
https://download.tmssoftware.com/download/manuals/TMSWEBCoreDevGuide.pdf#page=652&zoom=100,92,145
where you can see the supported Miletus targets.
Given that you've already got MacOS and ARM on there, what are the main challenges in getting the iOS equivalent working? Isn't it just a different wrapper? Even if there was the option to have an Xcode project that we'd have to compile and provision ourselves, those would likely just be a series of easily repeatable steps to avoid you having to do any of the stuff to do with whatever authorization or key stuff to do with the app store, no?
What is the added value to do that, making an app one needs to put in the Apple App Store versus simple direct PWA deployment?
Marketing reach and making things easier for users. If I were to ask a user to add an app to their phone, 99% of them are going to go to the App Store. Here's Grok's take:
When considering whether to publish an iOS app as a Progressive Web App (PWA) or through the App Store, the decision largely hinges on access to users, among other factors. Here’s a way to quantify the relative benefit of the App Store approach in terms of potential users:
User Reach:
App Store: As of the latest data, there are over 1 billion active iPhones globally. This number gives a rough estimate of the potential user base directly accessible through the App Store.
PWA: While PWAs can be accessed by anyone with a modern web browser on any device, the specific reach in iOS users is harder to quantify directly. However, considering:
iOS users might not be as familiar with installing PWAs compared to native apps.
Apple's restrictions on PWAs (like not allowing them to be pinned to the home screen with ease or push notifications without third-party services) can limit their visibility and functionality.
Let's use some hypothetical but reasonable numbers for comparison:
App Store Potential Users:
1 billion active iPhone users.
PWA Potential Users on iOS:
Not all iOS users will use or know about PWAs. Let's estimate that only about 10% (a very optimistic guess considering the current adoption rate and awareness) of iOS users might engage with a PWA if it's promoted well. This gives us:
100 million potential users.
Relative Benefit in Terms of Potential Users:
Calculation:
App Store users / PWA users = 1 billion / 100 million
Benefit Factor = 10
Therefore, in terms of potential users, choosing the App Store could theoretically provide 10 times more reach than a PWA on iOS, assuming the above calculations and assumptions hold true.
Note:
This is a very simplified model and doesn't account for:
Marketing efforts which might influence the discoverability of both apps and PWAs.
App Store's review process, fees, and visibility algorithms which can impact actual user acquisition.
The cross-platform nature of PWAs which might still attract users on other devices or those who prefer web experiences over app downloads.
When making this decision, you should also consider other factors like development cost, maintenance, feature set, user experience, and strategic goals for your app.
When pushed a bit further, Grok was more on-point to suggest only 1-2% of all iOS users have likely installed a web app as a home screen icon.
I appreciate all the work that has gone into making PWA apps work as well as they do, especially on iOS, but the cachet of just being in the app store is far, far more important.
Well, it is A LOT of technical non-trivial/hard/complex work, for the Miletus shell, but certainly also for the developer to deploy it to the app store, just for a bit "cachet".
My use of "cachet" was a bit of a euphemism. Access to 100x the users (or more) is the goal here, along with making it easier for the user by having them do what they're normally accustomed to doing rather than the whole "add to home screen" dance.
That's why I was asking what the technical hurdles were. I figured if you've already got the OSX thing worked out, it seems that the iOS version would follow a very similar trajectory. In fact, in the current version of macOS you can run iOS apps directly. Sadly not the other wy around.
If I recall, one of the iOS challenges was to get around how to create an app that is properly signed and ready to go. So I thought this would be more like creating the iOS app as a project that Xcode could then be used to compile with our own credentials and sign whatever needs to be signed to get it on its way into the AppStore approval process. Rather than TMS WEB Core having to do that dance all by itself.
I think Electron apps used to be able to do this, but I don't know what the current AppStore policies are. I recall the Windows Store once actually accepting PWA apps. I don't think Apple is going to go that route anytime soon.
As I mentioned, it is non-trivial & very complex. Something we can only afford to put all the time/work/cost in if there is sufficient interest.
The CrossOver folks charge a rather hefty up-front fee plus royalties to build a custom version that lets you distribute it as a deployable app. I think that's because they can't lock it down, and users are basically getting a copy of CrossOver that can be used for their own purposes if they know how to do it. I think that has something to do with handling the distribution of updates.
How does Miletus handle updates in the field? Just replacing the app?
Yes, Miletus is just like a VCL app in that regard. an EXE essentially. If I recall, there were some tools available to help automate that somewhat, but the task is basically the same as if you wanted to update any other Delphi app in the field.