I have nothing but the highest praise for Tuple, it blows all the other tools in this space out of the water. Used it for several months while working on a compilers project back in college, and over many many hours of usage it was rock solid. The latency is so low you practically feel like you’re in the same room as the person you’re communicating with. And the UI/UX is very thoughtful and intuitive, making it easy to point things out to your pair, take control when necessary, etc.
I can only agree. Used it for a couple of weeks when live co-coding was indispensible. You cannot even compare this to similar features in Teams, Slack, and the like. The tool works seamlessly and has a super-smooth usability. I did not notice latency either.
You can share screen and keyboard and work on the same codebase as if looking at the same screen and having a keyboard one for each. Audio worked extremely well. Did not use video for long because the fans spun on (2017 MBP). Without it, resource consumption was reasonable.
Made us super-productive back then. Can definitely recommend it.
When working alone remotely from home, I simulate pair programming with a methodology I call "The Stranger". I sit on one of my hands until it becomes numb and tingly, and then it feels like somebody else is typing and moving the mouse!
In places I've worked in, there's very little pair programming culture. If a dev needs help, maybe the reaction is "push your code to a special branch and I'll take a look later" or if it's really urgent "use screen sharing" instead. A lot of that comes down to different environments: some use Emacs, others use Vim, yet others use VSCode, and remote control isn't really effective because of all the different shortcuts and UI and customizations. That's before even different personal preferences for different tools: I want IDE-like integrated error messages right beside my code, they want error messages in a separate terminal window, etc, etc. Simple screen sharing and dictating things to do is good enough in that case. And if both persons are at least somewhat familiar with the language, you wouldn't be dictating token-by-token.
Until recently, I spent the whole pandemic exclusively remote pairing. We always did driver/navigator and never did any controlling of each other screens. If we switched roles we’d just pull the branch and work on our own machines. Tuple is nice for doing that quickly as you can just take over sharing without having to ask the other person to stop first. Its markup tools are very nice and simple, too.
Having a way to ping things or draw on screen is super useful even if everyone uses their own environment. No more "no, not this line, the 4-th one from top, well now its on bottom, wait don't scroll".
Ha, ya. Tuple's are perfect as it gives you the "draw quick attention to this spot" and then the pen tool auto-disappears with a setting to make it stay forever with a quick shortcut to erase everything. I actually almost exclusively use the pen now, though I use to make a lot of use of the ping.
I can tell you how Pivotal solves this problem (or used to; my time was years ago): Standardize the configuration. If some special tool is making you more productive, share it with the team and get everyone on board. Don't try to be a special snowflake.
IMO this is the right way to do pair programming. It tends to bring everyone up to speed with the latest tools, and it keeps eccentrics out of the weeds. It's not to everyone's taste, of course. But neither is pair programming.
Cater to your own needs. "Special snowflakes" would include disabled folk that need special setups. If you need a special setup to avoid RSI or to be more productive, do it.
Folks with disabilities would not be considered in the snowflake category. If a team member needs a certain setup then you have to support them, of course.
Snowflake behavior is being the person who just can't use the terminal if it isn't "set -o vi" keys. Or insisting that Caps Lock be mapped to Ctrl/Esc/etc.
But if you are used to Caps Lock being mapped to Ctrl/Esc/etc and then suddenly it’s not it is actually pretty jarring. I don’t think that’s special snowflake. The problem is that it’s not absolutely trivial for whoever’s currently using the keyboard to put it in whatever mode they’re used to.
Or that people are sharing a physical keyboard and having this problem at all. You can pair program with more than one keyboard.
'Dealing' with Esc for Vim would fall under RSI prevention in my book. Using Vim almost necessitates some form of easier switching modes; swapping Caps Lock, `jj`, etc. are all considered valid and 'normal' for the general Vim community and to say only one or even none of the options are "okay" in the company, well, unless it was my preference this would be an immediate resignation from me. That or the company better be shelling out and allowing time for employees to configure programmable keyboards they can pop in with their keys hardware configured.
The Pivotal sharing station has separate keyboards and mice for each developer. Many people bring their own keyboards and pointing devices. That's fine.
"I can only be productive in emacs" doesn't fly, unless you happen to be paired with the rare snowflake that feels similarly.
Team, not organization. A big team might be 5 pairs. There was no hard rule that everyone had to use the same setup - you'd occasionally see pairs in vim or whatnot - but since you're switching computers and pairs almost every day, you tended to homogenize quickly.
My team standardized on JetBrains. Even if someone is unfamiliar with the IDE, pairing gets them up to speed fast. Humans can learn any dev environment.
Hi there. I don't do pair programming and I'm pretty wary of it, but I checked out the site and watched the video and I have a suggestion.
Suggestion: market this to remote teams regardless of whether they do "pair programming" per se!
In my last job we had our team spread out over continents and time zones and home-offices and office-offices: bandwidth for meetings was super unpredictable.
Thus anything with a live video component was hit-or-miss, and if you had something very technical to discuss, you often had to sync up to make sure everyone was reading the same page on Jira or whatever.
I realize your tool is probably only for 1:1 conferencing, but even then, I think it could be compelling to have really good screen sharing with some annotation and the resolution control. Even if (especially if) it's only going to be used by two people at a time.
(Maybe this needs a different kind of license though. If I have 10 people on a team and expect 5 of them will use it but I don't know in advance which 5 or when...)
Also I would absolutely want something like this in a startup, even for managers, just to be able to go over stuff like AWS consoles (shudder) together.
It's a brilliant tool! Picture quality is excellent - I guess due to peer-to-peer - and the quality of the product also generally feels high. I recommended it to a new team just today.
But the audio connection seems to keep going for a few seconds after you close the pairing screen. Could be seriously embarrassing if someone utters something after thinking they've ended the call.
Lol I'm not lying to you! I almost always hear an end-of-call sigh from the other person that I'm sure they aren't expecting to broadcast because they think they've ended the call, but nothing embarrassing yet!
I'll try to screen-record my next interaction and show you. I think the problem is closing the window shuts down the screen link but not the whole pairing session, but people don't realise they need to separately end the call.
> I think the problem is closing the window shuts down the screen link but not the whole pairing session, but people don't realise they need to separately end the call.
Ah hah! This is totally it. Closing the screen share does not end the call (intentionally). I can decide I don't want to see your screen any more, but still want to talk to you. Definitely a debatable design decision, though. It actually used to work the other way.
They doesn’t really seem like a bug then, it should be possible to close the screen sharing without ending the call. Maybe you want to continue chatting.
I adore Tuple and my team used it really effectively. It’s the best tool out there for remote collab as far as I’m concerned. And with a colleague on a 4G connection the way it’s economical with bandwidth is really appreciated. But we have a few teammates on Linux and we just had to drop it. Is there any possibility of a Linux version?
I just about closed the window and dismissed you entirely based on this on the pricing page...
Do you support Linux and Windows?
Not yet! We're Mac-only for now. If you'd like to hear when we launch support for those OSs, please drop your email in this form.
If you have something in beta or coming soon, you should update it to send people to that more actionable link instead.
I've been working at pairing culture companies for a good number of years now, initially in-person, but then increasingly remote with offices distributed in several cities. Tuple was such a great find, even in the earlier times when sometimes we had to wait for connections to establish (presumably from rapid growth/adoption). It is still amazingly good at what it does and each little new feature seems to be reading our minds about bothersome things. It's a clear sign that it's used internally and also that feedback is really used. I always try to fill out the end-of-sesson form/rating if I have anything specific to comment on.
The best improvement was the clunky 'observer'-party that wasn't easily able to become the 'driver'. I think I actually received a reply on that one, plainly stating that it's a well-known issue that's being actively worked on, and not long after it began working seamlessly. I was about to ask about shortcuts, as moving the mouse to the menubar to temp-mute (or hang-up at end of call) can be a bit awkward if your screen is the one being shared--I just looked and there are Hotkey settings, just no defaults. Great stuff.
There used to be some issues where leaving Tuple running for days/weeks(?) sometimes could have it consuming CPU while idling. I don't recall the OS-version specifics, but I've got into the habit of exiting and restarting it every day or so. The problems may have been fixed but I haven't tried leaving it running to find out. If there's a way of submitting diagnostics specifically for these sorts of issues, I'd like to know.
It all it's as close to a perfect product as I use on a daily basis. Even with one team member's internet that can get slow at times, dropping to 1080p makes the text a bit chunky but still readable and able to follow along.
Tuple is great! It would be crazy cool if we could share multiple screens at the same time. What could be cool as well is if I can share a viewable only screen to the person I'm pairing with while they share with me their regular tuple screen.
Also, Tuple is waaay better than what we use when interviewing people with. Maybe some sort of hot seat feature where we could get people to download Tuple and interview/pair with them there.
Looks like their faq under pricing says you can do this now! I wonder if it would work for interviews that have more than one interviewer? I might check this out for some of our needs too.
Looks very cool - first time I've heard of this one. Minor feedback note: in your demo video, the top menu bar is mostly cut off (viewing on Chrome on Mac M1 Monterey), so when you are explaining the menu bar, I can only see the bottom sliver of it. I can use my imagination to figure it out, but ideally the video would be showing the whole menu bar. Other than that, looks great!
The toolbar looks cut off in the demo video - this is what I see when the presenter says "you can see the icon has gone red" (cursor is from the video): https://imgur.com/UzpbGxS
Indeed! The bulk of the work to support Linux has been separating out a cross-platform real-time engine that the UI layers of each platform can plug into. Toppling the Linux domino will make Windows much easier.
Not a single screenshot on the homepage? The number zeroth thing I want to see is a picture of the thing. Maybe even a gif or a silent autoplay video. I saw there's a video but it's a guy who's gonna talk. I just want to see the product.
I believe 0:19 would make for a better thumbnail than the current. Shows the video is actually a product demo and not fluff from a talking head
As far as a screenshot for product? Not sure, it really stays out of the way which I like but that makes it difficult to convey visually. Which you seem to have realized :)
Funny thing is, this is a pairing app. It's actually better if it gets out of the way. But I agree, that thumbnail with both screen and speaker would be better. I think something with more on content on screen than just a dropdown from the contact list would look better. Either code or that fancy network monitor (plus the speaker).
I didn't even realize there was a video, but I certainly wouldn't have watched it, that's just not super thoughtful design, and the thumbnail kind of looks like a chatbot sort of thing, which in 2021 is something I ignore like banner ads.
I realize that watching a video is maybe how a lot of product companies wish potential customers made decisions, but much like an elevator pitch, if I can't scroll the website and have a glance at what the product looks like, I ain't gunna watch a vidya bud.
I've been using Tuple for the past year and a half or so, IIRC. It's just a really well done Mac app. One of those tools that "just works", is thoughtfully designed, and mostly just stays out of the way and does its job without doing anything annoying.
We don't pair program as a regular thing, but we have junior engineers on our team, and often when they need help, or we're working through some bit of architecture, etc. I'll pair with them. Tuple is the best tool I've found for doing that (remotely). I'm not teaching full time any more, but if I were, I'd absolutely be using Tuple to do remote 1:1 sessions for that as well.
Finally, I've interacted with Ben, the CEO of Tuple, and came away with a great impression of him and what he's trying to do.
I've worked at companies with 20 employees, and companies with 100,000 employees, and not once have I ever been asked to participate in pair programming. It would have been immensely useful in college, but VS Code already has a built-in tool that would do the job... and VS Code works on operating systems that I actually use.
Who is using this? What do you use it for? I don't mean to be facetious, I have just never been exposed to pair programming in a professional space.
They are excellent for mentoring. As a remote senior engineer I'm not able to simply stand over someones shoulder but I can offer to drop into a peer programming session and help someone through a problem and be able to take the keyboard and show them different approaches etc.
Without these tools I don't think I could do my job effectively.
I have worked in FAANG and in 10 person startups and have paired in them all. VSCode is fine if you're all using VSCode and don't need to screen share anything outside of VSCode. If everyone is on mac though, there is nothing better than Tuple that I have used. If one party uses IntelliJ and another uses vim, and you need to have a db client or browser or something open as well, Tuple is fantastic.
There are plenty of programmers that don't/can't use VS Code, for one. I'm an iOS and Mac developer, so VS Code is of little use. I'm in Xcode all day. Tuple makes it so I can pair with Xcode, but also see/use the iOS simulator over the pairing connection.
Pair programming isn't inherent to good engineering culture. I would say that my employers have had phenomenal engineering culture, and the first couple had the best mentorship experiences I could have ever asked for.
Have you practiced it extensively though? You said you haven't professionally, so that leaves just personal experience. I would say it's not entirely critical, but I'd be very skeptical about a company's engineering if they didn't pair program. It would make me look closely at their other practices or lack of
I very much get a cargo-cult vibe from this statement.
In a 30-year career, I’ve pair-programmed under 100 times. Usually to get someone up to speed on a confusing part of the code base.
In fact, I’d go as far as to say that if pair programming is a recurrent need, you need one or more of better engineers, better documentation, or better code reviews.
Thanks for the N=1. In my 5 year career I've pair programmed across the spectrum of experience roughly 500 times.
I don't see it as only as a need to unblock someone. It's a great way learn and share from in a junior:senior dynamic, and also speaking strictly remotely, a nice way to socialize
Nice one. One suggestion. While you open the shared URL on the pair's browser automatically, there are still a bunch of steps involved in copying the url, pasting it in the app, and then hitting open, before the URL opens in the pair's browser.
Instead, build a chrome/firefox extension that allows 'pushing' a tab into the pair's browser session. I find something good, I right click on the tab and click " Send to Pair" or similar.
This looks cool, but I don't use proprietary operating systems for my work environments. Is there any planned support for X11 or Wayland based desktop environments?
Using Linux, I, and one other, was therefore not able to participate in a lot of work. Coworkers would pair with others because of familiarity, and because between macos and linux, there was more friction.
This caused a severe schisma in an already disfunctional team.
Management then disallowed tuple, because it was making things worse. But the practice continued. I quit. Not because of Tuple, but the entire distinction, of which Tuple was an ingredient.
The choice to not support an important part of the developer community is understandable from technical perspective. But socially, in times of isolation, home offices etc, it is doing harm out there.
Nobody is forced to use Tuple. If you blame anyone blame that company for allowing anyone to use Tuple in the first place, or the asshat engineers that held it against the Linux people.
My point is that any company that makes a co-operation product, but which excludes a demography from co-operating, should know they are causing harm.
Imagine if slack excludes Android. Or Google Meet excludes Apple devices. That is not only a poor product, it causes minorities to be excluded. Or divides the companies or teams using it. This is what Tuple is doing.
I'm blaming both Tuple for not including Windows and Linux up-front, just as well as management adopting such tech that has these clear limitations.
In this practical case, the Linux (and Windows) users joined later into an "mac-only" team. Tuple, however, was the major cop-op tech: they refused Slack, accidentally used Telegram (!?) and email, and when using Google Meet all engineers refused to turn on webcams. So as a non-Tuple-using person you were really kept out of the loop.
Tuple’s audio quality really is good enough to feel noticeably different to Zoom or other VC. Much more like your pairing partner is in the room talking into your ear.
I wonder how many programmers don't like pair programming. I love programming because it's me and the computer, working at my pace. When collaborating, asynchronous work better I feel.
Live Share is great if your pairing session is extremely code-focused. But if you're jumping between the browser, terminal, IDE, docs, Xcode simulator, etc., you begin to want to see your pair's entire desktop.
So far it seems that this is intended as a type of remote KVM instead of a per-application collaboration. I've looked around on the site but haven't really seen any obvious screenshots. Maybe I've seen to much marketing pages and completely miss the 'click here to see how it works' link...
Edit: and as I suspected, on second pass on the homepage it's right there in the middle in the purple bar. And it does seem like it's "TeamViewer but for developers". I suppose in the spirit of 'pair programming' that makes sense, but I'm not sure how streaming an entire desktop is better than streaming only application state if you just want to work together on the same thing.
It is useful to stream the whole desktop because you don't only look at code while pair programming. We look at the stories in Pivotal, read slack, google stuff, read documents and so on, all of that needs to be shared also.
With Live Share you see their text selections, but not mouse movements. (except inside the Draw.io integration [0], then you see a remote mouse that is drawn by the extension itself). It's a bit like Google Docs or Etherpad, but for code.
Also: other editors could implement the same protocol perhaps, it would be cool.
Live Share lets you see which files your pair is looking at and what they have selected. You can also share a terminal session if you'd like. At work we mostly do Live Share + a Slack Huddle for audio. I think it works pretty well.
Ben, one of Tuple co-founders cohosts the https://artofproductpodcast.com There is a lot of information about building and running this business, including the rationale for a lot of product/business decisions. I really enjoy it.
Every time I have demonstrated Tuple to a colleague they have been left gobsmacked and short-changed by all other audio call and screen-sharing utilities. Clear sound is so critical and pairing with everything else feels like you're in a Christopher Nolan film with no idea what's going on.
Yes, it works well, but the only reason we used it instead of Tuple was that it's free right now. Tuple's pricing is rather absurd ($25/user/mo.) unless your org pairs so often you can justify it on the basis of 40 hour/week use. Pop's free tier lets us pop on actual controlled sharing when simple screen sharing isn't enough.
Every company has different budgets, which I get, but you're basically arguing it's only worth ~$0.16/hour (based on 160 hours/month), which seems pretty suspect given that developers (in the US) cost around $100/hour all in.
Based on that cost structure, if it saves the average user 15 minutes per month then it has paid for itself.
I make this argument solely because when it comes to developer/professional tools, tens of dollars per month is a fairly trivial cost.
Anecdotally, I suggested Tuple to my boss (also co-founder of the very small company I work for) when I discovered it, and it took him all of 2 or 3 minutes to learn about it, decide the money was worth it, and sign up for a team account for all the engineers at our company. We've used it regularly in the year+ since. Whether or not $25/user/month is expensive is pretty situational.
Perhaps it's just a value comparison thing. My company pays $5/user/mo. to GitHub for private repos, storage, and GitHub Actions. Every developer uses it every day to accomplish business critical project work. A pairing tool feels more optional to me, especially when Slack's built in screen sharing accomplishes 50% of what we need as part of another service we pay another per user per month fee for already. So a tool that's 5x the cost of GitHub that serves as an optimization for what we do is hard to justify. As a company we could afford it, it would just be a difficult sell, especially when a competitor is still free (turns out "for the duration of the pandemic" is a lot longer than they thought, oops). Of course, if we had a culture that paired on a regular basis, this might be easier, but it's more of a when you need help or want to work together thing, rather than being required.
Additionally, as others have mentioned, I think some of the issue is the lack of a free or low cost personal tier that has some set of restrictions. What those would be for an arbitrary pairing tool I don't know, but it feels really pricey if I just want it available for one-off pairings.
Now, personally, I could sign my OSS project up for a free version, but since I don't need (or want, lol) to pair with most contributors, that feels a bit wrong.
On the flip side, I don’t think it’s pricey, $25 per user, per month for something that will make developers more efficient is well worth it. Sent to my Tech Lead to see if he wants to sign up.
ScreenHero, IIRC, went from free to roughly that same pricing, and crashed and burned because everyone had gotten used to free. I absolutely loved the software, but it wasn't critical to our workflow at my job at the time.
Unfortunately Teams, while terrible, is sufficiently usable that I don't see being able to persuade my current environment to adopt Tuple either.
I think, if I actually paired outside of work, I'd be willing to spend $5-$10/month just for casual non-commercial use. I'm not sure when I'd ever take advantage of such a pricing tier, sadly.
We don't have a strong pairing culture, but we're trying to create one! It's a little harder to justify the price because we don't know how many people will use it yet. Besides, programmers are often not the ones who are in charge of approving expenses.
In any case, Tuple is really great. For us, I think it would become a no-brainer if it had a seat-based model. e.g., we pay for 4 pairing seats a month, and a max of 4 developer can use Tuple at any given time.
For me personally, I'd pay $99-$149 flat plus paid updates if I liked it. But I know what they say about asking your potential customers what they're willing to pay ;)
I'd rather just make this free. In fact, if you email support@tuple.app and say you want to use Tuple for educational purposes, we'll make you a free-forever account.
Isn’t this a fraction of a percent of what most programmers are worth to their employers, at least in the US? I don’t think it needs to provide much benefit to justify the price.
I really like using tuple, but there’s a couple of things I’d really like to see:
- an idea of how much bandwidth it’s currently using or needs. I often find if I’m on a patchy connection it’s unclear how changing the settings will have an effect
- make the video face stuff more prominent, especially for multiple monitors. I work 100% remote so when pairing I like to put my Co-workers full size on my second screen while I work on the primary screen, which helps us feel more connected.
+1 on making video better. The janky video feature feels like such an afterthought compared to the impeccable screensharing/pairing feature. I've had to resort to using Tuple with Zoom just for the video sometimes because the webcam freezes for no reason.
I'll also offer one related piece of feedback: the "calling" metaphor for initiating a session is quite awkward. Compared to Zoom, where you share a link/code once and then you're free to join/leave the room, in Tuple you have to ask the other person to call you every time you drop; this in particular does not play well with the forced version upgrades -- you ask the other person to call you out-of-band, and you answer, except oops, you need to upgrade Tuple, so you upgrade and restart Tuple, and now Tuple has forgotten about the last call so now you have to ask the other person to call you out-of-band again! This is a UX wart that I'd love to see fixed!
Kinda weird to get your product featured on front page of Hacker News mid afternoon a couple of days before Christmas - not sure developers are fully focused right now.
Blame me. I just came across it for the first time and thought others might appreciate it. And if I didn't submit it right then and there then I'd forget to do it later.
Would it be cheeky to take this opportunity to ask how the Linux version is going? I'm still looking forward to it and it's the main thing holding our team back from adopting it last I checked.
It's going well! We're inviting a new cohort in early Jan. We've got the app going in Flatpak and that lets us target a lot more distros. Hoping to ramp up invites pretty quickly if things go well.
With Microsoft M365 and Google Workspace available for startups, it’s a serious shame sites want to make you store additional credentials with them instead of getting started on security right leveraging SSO.
I've been using Tuple professionally for a year and change and it's miles ahead of trying to share with Zoom or Slack. I love that it's not tied to a specific IDE, too! Being able to flip between terminals, IDEs, browsers, being able to paste directly into my pair's buffers, and take mouse control really make pairing remotely as great as possible. Almost as good as pairing with a shared workstation!
I used to watch many of Ben Orenstein (CEO of tuple)'s Vim tutorial videos. His enthusiasm was much appreciated and helped me improve my vimming skill. [Improving Vim Speed - Ben Orenstein - YouTube](https://www.youtube.com/watch?v=OnUiHLYZgaA)
Well, after reading all the high marks about Tuple in the comments I installed it and paired with a co-worker this morning. We got up and running in a matter of minutes. It just... worked. Such a more pleasant experience than a google meet.
As an added bonus were able to understand and solve a bug that's been plaguing us for weeks now in our first session :-)
I really like how it just stays out of the way.
I threw out the link to the rest of my team to see if others will try it out as I want our team to get more comfortable with pairing.
Well done and congrats on building a focused sustainable product!
As a junior engineer who started career in 2019, I pretty much owe all my knowledge to Tuple, which I've been using to pair program with senior engineers since pandemic started in early 2020!
At my company, we have a pairing buddy system for junior engineers. Each week a senior eng was my official "buddy" to help me in whatever I needed, then we would pair via Tuple. This was really great in order for me to grow.
This seems super interesting and I could totally see using it. At the same time, it's kind of funny that they couldn't get someone to pair with on the demo.
Using it at my current company and it’s great. Especially the little things like the ship it reaction! Super hilarious when I saw it for the first time. Thanks for that.
Some constructive feedback: could not get my webcam (canon eos utility) working. But tbh nothing big because we never use Webcams.
Pivotal Labs is/was all Macs and has been "pivotal" in the pair programming era.
Building apps is hard, period. Many thousands of hours go into making commercial products. Many thousands of hours go into learning how to do so. It isn't something you just stumble upon over night.
Tone the language down a bit ("stupid fanboy"), it is unnecessary and doesn't work to convey your point at all.
> it's really not like it's hard to build cross-platform apps nowadays
An app that shares screens and mouse pointers with simultaneous audio/video transmission is not the same kind of cross-platform undertaking as a to-do app.
The entire point of this app is to share control of someone's computer, as well as drawing on their screens, having another cursor and this sort of stuff. It's a textbook example of an app that _would_ be very hard to build cross-platform.
Build a native app and you get complaints about cross platform. Build an electron (or other cross platform toolkit) app and you get complaints about resource usage and non native ui.
Seems to me that they know their target market (large tech shops with lots of devs on macos) and preferred to optimize for resource usage and user experience by going native. For another company, this could very well be the wrong choice, but they should look at the numbers and decide what makes sense for them.
> Build a native app and you get complaints about cross platform. Build an electron (or other cross platform toolkit) app and you get complaints about resource usage and non native ui.
This. I am currently making a productivity app and I had to actively unbias myself from the hackernews/prosumer mentality that I must write independent apps for at least 3 operating systems/GUI systems, and 2 more if I want to go mobile.
It's a shame that interoperability has been an anti-priority from the OS providers (mainly MS, Apple and Google - if there was any standard Linux would follow). Even more sad is that the popular opinion is blaming developers for the situation.
There’s a whole thriving ecosystem of paid apps for MacOS, most of which are native and have a look and feel that can’t be done cross platform without compromises.
I’d highly recommend checking it out.