Ask HN: Develop productivity app first for Mac or Windows 10?

[johnmax]

I want to create a productivity app, which runs in the background, and reminds me to work on my most important tasks, when it thinks that I am not. The goal is to create a Minimal Viable Product which I, and others, find useful. Which of the two platforms has more potential customers? In other words: What is the market share of Mac vs Windows 10 among people who happily try out new productivity apps? My coding skills: I am an experienced backend developer, but have not done a Mac or Windows 10 app yet. I like both OS.

1000 thanks for any thoughts or hints.

[slantyyz]

I'm an ex-Mac user, and current Windows user. I'd say do Mac first. Mac users are accustomed to and way more likely to pay for apps.

Also, people are way more accustomed to buying apps on the Mac App Store than the Windows App Store, so discovery is definitely going to be an issue if you're going the App Store route.

On the Windows side, I pay for apps, but because prices tend to be higher for useful Windows apps, I tend to not buy as many.

When I was on Mac, I'd drop $10-15 on an app without blinking. For more expensive apps on the App store, it was also an easy decision because a $50 app could be installed on multiple machines.

In general, the useful apps on Windows aren't on the App store don't have the liberal licensing that Mac App store apps do. Because I want to run my stuff on at least two machines (desktop and laptop), and because usually there's some DRM that binds a license to one machine, I am much more hesitant about buying licenses.

[johnmax]

Thanks a lot for your feedback - eventually, if it is successful, I would launch it for all possible platforms.

So, getting to paying users is not a priority for me at the beginning.

Getting to heavy users definitely is, and discoverability may be better on the Apple App Store I guess, though eventually I would like the product to be so good, that it also gets word-of-mouth attention.

[ekovarski]

Agree with slantyyz... go for the Mac users first. The users tend to be more vested in the apps and you can get good feedback going. Going for a larger audience is not always the best approach especially if you are testing the waters.

[fbelzile]

I run a bootstrapped desktop productivity software business myself. I'd say the split is somewhere around 70% Windows and 30% Mac (all self-marketing, no app stores). The mobile rush created a huge vacuum in the desktop market that I think enabled people like me to succeed. Not to mention, you're not giving a 30% cut to Apple or Google and can generally charge more than a few dollars for your app.

It's definitely easier for me to develop on Windows. Though, this is mainly because XCode performance is atrocious on my mac mini and packaging apps for outside the app store is pretty tedious. I still use a buggy tool that Apple hides very deeply on their developer portal (it involves installing an ancient version of XCode).

If you require a UI that is pretty heavy, here is my "secret" trick to save time when developing for both Windows and macOS:

1) Buy a basic HTML template online for your app's dashboard.

2) Don't use Electon. Your users WILL notice and complain about performance. Instead, use the native WebBrowser control in .NET for Windows and WebView using macOS to display your UI. Disable right clicking and highlighting using HTML/JS. To the user, it'll feel like any other native app. Add this meta tag to the HTML file to ensure the WebBrowser control knows to use new versions of IE to render the UI: <meta http-equiv="x-ua-compatible" content="ie=edge">

3) Use the built in script calling functions to transfer settings back and forth between the UI and main app in JSON. Do the back end stuff in native code.

4) You can then re-use most of the UI code you wrote to easily port over to macOS. Use the same functions and logic you wrote on Windows to make your Swift functions.

Good luck!

[baumandm]

Don't use Electon. Your users WILL notice and complain about performance.

Is this actually true? Slack and Discord are valued at ~$7B and $2B respectively, and neither have found it necessary to move off their Electron apps. I assume both companies have already evaluated whether Electron's performance impacts their their bottom line, and concluded it does not.

Electron is undoubtedly slower and more resource-intensive than other options, but outside of specific audiences (HN readers) I bet most people won't care.

[fbelzile]

You're right. It's a relatively small, but persistent concern people have emailed me about. After a while, the squeaky wheel gets the grease.

I know this because I'm temporarily using a Chrome-based WebBrowser component for called EO.WebBrowser (for edge-case reasons). I'm working on going back to the native WebBrowser control after getting about a few emails a month of emails asking about RAM usage.

It also shows up in the uninstall comments. Quote from a real comment: "The app works, but it uses a lot of RAM."

Slack and Discord are used for work, which might make users think of it a necessary evil. Paying for software yourself that you don't absolutely need and having it use lots of your RAM is a different story.

[nickjj]

> Electron is undoubtedly slower and more resource-intensive than other options, but outside of specific audiences (HN readers) I bet most people won't care.

I think it makes even more of a difference for people outside of the HN audience.

A non-technical person might grab a $400 laptop from Costco with 4gb of RAM which is fairly common.

All it takes are a few Electron apps to exhaust that entire system's resources.

[baumandm]

Fair points.

All I was trying to say was that Electron and other technical decisions should be evaluated by their actual business impact, which vary from app to app.

[anoncake]

But will a non-technical person know which apps are to blame?

[nickjj]

They will be able to determine "before I installed this app everything was good but now it's not" and then they will proceed to blame your app (with good reason).

[ww520]

This is great advice. The HTML/CSS/JavaScript with native browser control is spot on.

[johnmax]

Great, thanks for the numbers and the advice.

[softwaredoug]

I would say whichever platform YOU use day to day. You won’t know if it’s useful unless you are constantly using and refining it.

Id also be careful conflating “I want to build a product” with “I want to build a tool for me”. Start with just a tool for you, decide later after it’s useful to a user population of 1 if it’s valuable to invest in finding a market for.

[johnmax]

Yes, I totally agree, I would first build it for me and work with it.

Right now I use a Mac, but I have used also Windows in the past, and - if I decided to code in Windows - then would switch all my work to a Windows machine, too.

Everything I do is pretty portable between those two platforms, so I don't have any problems with switching between the two.

[dmos62]

Let me step back a tad and comment on your use case, i.e. needing to be reminded to work and not procrastinate. I largely solved this problem by adopting the Pomodoro technique. Following it, I subdivide my work time into periods of concentrated work (20mn in my case) and relaxation (3-5mn). This increases my effective work stamina very much, helps with motivation, and has other benefits. Related literature is plentiful.

[enjikaka]

Make a PWA and you cover Windows, Mac, Linux, iOS and Android in one go.

[jjp]

Not sure that a PWA would have the scope of insight to know when you are skipping off the important task, e.g. playing solitaire vs coding, reading HN vs testing your app?

[johnmax]

Interesting - I didn't know about that possibility. Thank you!

[morpheuskafka]

If it needs native integration, use Electron, if not use a Progressive Web App. If it's got to be native go to macOS. The App Store ecosystem makes it way easier to make sales, and there is an expectation of buying quality apps. If you go the Mac route your design needs to be excellent though.

[un-devmox]

I'm not that familiar with PWA's, but how do you monetize them if they are not downloaded from the app store?

[nickjj]

I'd be careful about creating these types of apps because a lot of people (especially developers) value privacy.

What your describing is monitoring everything I do on my computer and then likely transmit it to your site. Even if it didn't transmit anything I would still be reluctant to use it unless it were open source.

To detect whether or not you're working on what you're supposed to be working on, you'll probably end up recording what window is focused every few seconds right? You might want to hack together an auto hotkey script (Windows) to do this. With a bit of AHK knowledge you could probably write a prototype in a day.

[johnmax]

Wow, AutoHotkey looks cool - maybe it is nice for doing a first prototype.

Yes, I would check the focused windows, but also would take screenshots to evaluate (with OCR/NLP) whether the email you are writing really relates to your todos.

I would not store those data, neither locally, nor transmit them to my servers, as I am very concerned about security (if my servers get hacked, then I don't want to have anything sensitive on them).

[ekovarski]

Privacy issues aside, re: screenshots, that sounds like a lot of work for a MVP esp when most people are quite happy with a better pommodore or similar solutions.

[darreld]

Windows has the most market share at ~85% total (Windows 10 is ~54%). If your target is enterprise users, then probably it's Windows but Mac users have been thought of as more willing to spend money on indie software they use.

[johnmax]

Thanks a lot for the numbers.

Do you have any view on whether those percentages still hold, if you only look at (e.g.) startup employees or freelancers or other customer groups, which may probably like such productivity apps?

[bronak1]

you can do both with https://electronjs.org/

[johnmax]

Will definitely need to check this out.

I come from the mobile world, and my experience is, from myself and others, that cross-platform solutions always brought more pain than joy.

The latter solutions were great in theory, but created huge problems, when a little bit of a custom behaviour had to be implemented, maybe dependent on the target platform.

Also, when developing natively, there seems to be much more usable open-source code.

[a_wild_dandan]

Yup, target Windows, macOS, and Linux all with one codebase (and be within epsilon of targeting mobile with Cordova). All with JS. Or preferably TypeScript.

[deca6cda37d0]

and here comes the discussion about why electron is bad :P

[neospice]

In a world where VSCode runs on electron is there even room for this discussion anymore?

[nickjj]

> In a world where VSCode runs on electron is there even room for this discussion anymore?

Opening a 1.5mb markdown file with VSCode idles an i5 3.2ghz quad core at 50%+ CPU and uses 800mb of RAM with only a few extensions loaded.

Also the input latency while typing in an empty file with no extensions is substantially higher than apps using other UI frameworks.

I think there's plenty of room for discussion, especially considering that VSCode is over the top optimized compared to most other Electron apps (which are WAY WAY worse than VSCode).

[sirjaz]

VSCode is highly optimized and has tons of engineers behind it. If it were me I would do .Net Core and Avalon UI: http://avaloniaui.net/

[rygxqpbsngav]

Looks like Avalon is in beta. Are there any stable alternatives that are production ready?

[scarface74]

And you could also gouge your eyes out. But neither would be pleasurable.

[pjc50]

Obvious dependencies: you need a computer of the relevant type if you're going to go native.

Are you going to sell it as a product? How? Mac store, Windows store, online from your own website, Steam, something else?

How are you going to acquire customers?

What apps are you competing with (hint: there's a lot, on all platforms)?

Which native platform are you most familiar with/want to become familiar with? (Note that Windows has several platforms within it; UWP is the obvious modern choice, but maybe you want a WinForms app)

[pengo]

From my own experience I'd consider a development environment that lets you cross-compile. c or c++ work and, old hat though it is, I've had good success writing cross-platform utilities in Lazarus (Object Pascal) and compiling for MacOS, Linux and Windows. The only issues in all cases has been the need for platform-specific libraries to manage GUI components like rich text editing.

[leowoo91]

You have to study your decision depending on your audience/budget/vision/tools, there is really no specific answer to that. Also remember, even cross-platform development has its own disadvantages, and worst decision is at least a "mile" ahead, rather than spending too much time on best solution.

[fredley]

I wouldn't rely on anecdata from HN posters, who may or may not be representative of your potential market. Try and gather some data and see what it says, e.g. spend $5 on some facebook ads for your not-yet-existant product, and see the breakdown of OS's that hit your landing page.

[slantyyz]

> I wouldn't rely on anecdata from HN posters, who may or may not be representative of your potential market.

Well, if the OP gets 100 actual responses (as opposed to secondary discussion posts), then that anecdata actually is data.

Given:

* the nature of the described app

* that its functionality appears to be scratching an itch the OP has

* that the OP is a member here

* the OP asking the question here

..it doesn't seem to be far fetched to think that the posters here are at least somewhat representative of the potential market.

[johnmax]

Yes, it's a good point to do such market research. Will need to carefully structure the ads, to not skew the results (e.g. because users from one platform are cheaper per click, and thus will be preferred by Facebook)

[douglaswlance]

Web first. It's cheaper, more people can use it, and you can find product-market fit more efficiently.

[tonyedgecombe]

How are you going to get a web app to run in the background and notify you when it sees you are reading HN instead of churning out code?

[mushufasa]

any solution that I could think of could also be called malware...

[robjan]

The market is quite saturated but people in the Apple ecosystem tend to be more likely to pay for apps.

[hodder]

Who is the obvious target market in your mind? Is it programmers, artists, musicians, small business people, mega corporate conglomerate employees, millenials, boomers, rich people, North Americans, Europeans, Chinese? The answers to these questions will guide you.

[bluedino]

Simple, the Mac. Huge bonus of being able to have it on the App Store and sell it for a couple bucks.

[slantyyz]

>> sell it for a couple bucks.

I would disagree with you on that point and say charge premium pricing ($10+) if the app is good.

People in general seem to think that they are entitled to a lot of support from App Store apps, even if the price is a buck (or to use the overused cliche of "less than a cup of coffee").

IMO, the higher price can help get rid of high support/low revenue users who can suck the life out of you.

[tonyedgecombe]

The App Store is awash with productivity stuff, I'm not sure it's as big a bonus as you think.

[slantyyz]

If I were building a Mac App store app, I wouldn't rely on the App store for discovery. On the other hand, the App Store is easier for handling downloads, updates, purchase transactions and licensing.

If you are doing a Mac App and want people to try your app, it would probably be worth spending the several thousands of dollars it takes to get a sponsored post on a site like Daring Fireball.