It’s an online tool that will convert your web app into a desktop app. It’s super-straightforward and, hopefully, it just works.
I’ll be doing a broader release next week but looking for some feedback first from bootstrapped first.
Everything should work. You can build an app for Mac and Windows at the moment (Linux coming soon). If anybody wants to try it out then just let me know and I will refund 70% of whatever you paid. Of course, if you’re not happy or it isn’t what you expected then I will refund 100%.
Would love some feedback on the landing page, pricing and product. Any feedback that I’ve received so far suggests that pricing is too low, so particularly interested in that.
The site looks slick, but it’s not clear to me how this works, and I’d need the technical details before paying anything. Does it just open up a chromeless browser window (which browser?) on my site? Does it try to bundle all the files in with the installer? If so how do I deal with updates? etc.
The preview on the Window Dimensions page shows the base HTML of my app (https://reviewable.io), with no images or styling. This doesn’t inspire confidence that things will actually work.
Some of the features promised on the home page don’t appear to actually exist in the build flow. “You can edit […] the window frame UI style/colours. You can even edit how the installer looks and how it installs your app (e.g. would you like your app added to desktop by default?)”
Don’t make me pick between platforms. If I wrote a web app, it’s clearly because I want it to work everywhere. Raise the price ($100 seems reasonable to me) but include all the installers.
Just my 2 cents. I actually had a couple users request a desktop version of Reviewable, so if I better understood how ToDesktop works it’s quite plausible I’d pay up and get it done.
First up, this is excellent feedback and it’s exactly what I was looking for. Thank you so much.
It uses Electron under the hood. So it basically bundles its own standalone web browser based on Chrome. This adds a little bit to the application weight (The installer file will be ~40-50MB) but it gives consistency of experience. It doesn’t bundle files for your app, it fetches them remotely, it basically works exactly like it would in a web browser.
I’m really sorry about this, I’ll get it fixed. Technical Details (click to expand)
Your site contains the response header x-frame-options: DENY, this is actually very common and it’s a good practice. What this means is that the <iframe> used to preview site is blocked. This is usually fine because ToDesktop has a fallback mode where it will proxy the request for your site on the backend. This requires doing some jiggery-pokery to the <base href="x"> tag, your site already has a <base> tag, again this would usually be ok because I have some code to deal with this situation but it is not set up to deal with domain relative paths like you have. It’s an easy fix, thank you for reporting.
You’re right. I should have made it clear that these features weren’t implemented yet when I posted this. If you have any specific requests then I’d be happy to do a custom build for you.
Yes, I think I agree with you. I’ve got similar feedback a number of times.
If I better understood how ToDesktop works it’s quite plausible I’d pay up and get it done.
There are some CORS restrictions with the CSS font files on your server so it won’t look exactly correct but it should mostly work ok. I’m going to fallback to taking a screenshot on the backend for cases like this but it hasn’t been implemented yet.
I tested building your website by the way to make sure it was ok. Here’s what it looks like on Mac.
Thanks for the response Dave! Here’s some more feedback:
You need to offer some means of contacting you on the site, preferably via email. If I had landed on your home page cold I would’ve bounced hard because I had all these questions and no obvious way to answer them.
You need to provide way more technical detail on how this works and any limitations. Basically, the price you’re charging is a rounding error for an established business, but what I can’t afford is time to troubleshoot and deal with customer issues. At least half the value (if not more) of your offering is that you’re packaging your expertise in deploying a web app to the desktop: provide evidence that you’ve thought things through and I don’t need to worry about it.
What if I do run into issues – what kind of support do you offer? For how long after the initial purchase? Again, there appears to be no point of contact for this, which is a red flag for me.
What if I need to update the icon or URL in the future for the same app – do I need to buy again?
More technical questions: If Chromium is bundled with the installer, which version and how does it get updated? What happens if the app tries to open a new tab? Does Electron support workers (service, web, shared)? For shared workers, what’s the sharing scope – i.e., will new tabs share the workers? How about localStorage and IndexedDB?
In general, what are the technical questions that I don’t even know to ask? Every technology has limitations and as the expert it’s up to you to warn me about them ahead of time. If I don’t see any limitations listed I get suspicious.
Basically, to get me to buy you’d need to 1) ease my mind that offering the desktop installers won’t create more debugging / maintenance work for me, and 2) get the Linux installer done (since my customers are developers I have way more than average Linux users).
This is an absolutely fantastic list of issues @piotrk. Some of them I have in my pre-launch todo list already but not all, particularly around explaining the technical side of how this works. I will do better!
To answer some specific questions that I haven’t documented on the site yet:
I offer email support for 12 months from purchcase. There will be a subscription version eventually which offers support for the duration of the subscription. Existing once-off customers will receive a discount on the subscription version if they decide to switch (details are TBD). Of course, the app will work forever whether you are on once-off or subscription version.
Currently, the solution is to send me an email and I’ll sort you out. It’s on my todo list to have a technical solution that doesn’t require anything manual but this won’t be ready for launch. I will document the “email me” policy in FAQs and terms though.
Chrome/69.0.3497.106. Currently, it doesn’t update. You would need to build a new version (and pay for it). Subscription version will auto-update in the background (just like Chrome).
By default, new tabs will open in a new window within your app instance if the domain is considered “internal”. If the domain is “external” then it will open in your default browser. “Internal” domains are any domains which are on the same second-level domain as your app’s URL. This will be configurable but configurability is not available right now.
Yes, all workers, localStorage and IndexedDB are supported. Sharing scope is exactly the same as Chrome in all cases but not shared with Chrome (i.e… Chrome and your desktop app are completely isolated instances and you have no access to workers running in the Chrome browser).
At the moment, the main one is the auto-update functionality for the underlying Chromium/Electron instance but you have flagged this already and I have a solution in the works.
Another caveat is that browser autofill isn’t implemented yet. Cookies persist between sessions though (just like every other browser), so depending on how you handle login this is probably not much of an issue.
This is very clear. I will get to work and I’ll tag you in a post on this thread when I feel like the product meets your needs.
Finally, your feedback has been invaluable. THANK YOU!
Thanks Dave, happy to help and sounds good! However, please add auto-updating of Chromium to the must-have list; I can’t afford to have non-updating instances out there, since my app pretty much assumes evergreen browsers.
Also, one extra random idea for you: how about offering ToDesktop as a desktop app itself, so prospective customers can try things out hands-on?
I should explain this a bit more just in case it makes any difference to you. The client-side auto-update functionality is already there and working but the backend server infrastructure is not (yet). What this means is that the app will look for an update but the server is currently telling it that there is no update available. When subscriptions and the auto-update backend are available/implemented then it will be as simple as switching over to the subscription plan and all users of the existing app will auto-update seamlessly.
Yes, already on the todo list, it will come after subscriptions/auto-update.
As you can probably tell, I’m hugely focused on getting this to market and getting feedback + validation ASAP. Perhaps a little too eager. I’ve been burned by my previous startup where I took too long making things perfect and not getting validation that people actually wanted it.
Gotcha. I think that makes it reasonable to adopt ToDesktop before the auto-update server is ready, but there’s still some risk (how much will the subscription be? what if you never get around to building the server?) that would need to be balanced against the earlier benefit. In my case I think the trade-off falls on the side of “wait”, but I’m totally in favor of launching early and iterating. The first version of Reviewable was seriously embarrassing.
Thank you for the feedback. I wonder what you think a good price would be for a monthly subscription when I introduce auto-update (of the underlying browser engine) functionality? I think that auto-update is a requirement for a lot of the more valuable users of ToDesktop.
Yes (it uses Electron which is based on Chromium/Chrome). Views are cached in the same way that chrome has caching. If you want more aggressive caching and more “native-like” responsiveness then you can use something like service workers.