[dman]

Ive been surprised because in codebases I have worked on, you usually have an abstract rendering api at the bottom with multiple implementations for each platform. Ive been curious why you couldnt abstract out things like window creation, layout, rendering and implement the abstract api for multiple platforms.

[ken]

The very concept of "a window" is pretty different across platforms.

MacOS is the only one with a concept of proxy icons. It has a distinction between the key and main window. There's a responder chain for event handling. Toolbars have a built-in editor. There's QuickLook for easy previewing of sub-files. There are standard popovers, which can be torn off.

On the Windows side, I'm sure they've got their own set of unique features and constraints that the Mac doesn't have. (The Ribbon and keyboard navigation come to mind.) Same with Linux.

Lacking a feature often means you need to design the UI different elsewhere. Without proxy icons, you might need to add a menu item to mimic that functionality, for example. These things domino into each other. There's a reason that good Mac apps and good Windows apps don't tend to look identical.

English and German are fairly similar, as languages go, but you can't just do a word-for-word replacement of English and get a good German paragraph, or vice versa. Not infrequently, you need to re-arrange everything to make it work. The pieces you have to work with are just different.

2D/3D graphics APIs (if that's what you're referring to) aren't like this. For the most part, they're all playing with the same basic pieces. When my Mac traded OpenGL for Metal, I barely noticed, even as a developer writing graphics code. When my Mac switched from Carbon to Cocoa, everybody needed to rewrite almost everything.

[dman]

Completely agree with everything you said but the curiosity that drove my initial question still stands. To be specific do you think Sketch / OmniGraffle are unimplementable on Windows? Why would the creators of those apps after achieving such success on OSX, be unwilling/unable to address the windows market. I am convinced there are good rational reasons for this, I was hoping that someone from one of those companies could comment on this. [It is possible that in their target demographic everyone uses OSX, but is that the case?]

[Chazprime]

If the app is a native Cocoa application, it’s been written in Obj-C or Swift. Cross-platform apps and frameworks are usually written in C++ with a UI implemented in a common framework like Qt.

To port the application to Windows, you’d lose a lot of the Mac-specific features, or have to do a substantial amount of work implementing platform-specific UIs.

[kazinator]

Sure, and we can abstract away a mother's touch with some special "cross-person" gloves that anyone can wear to pat the baby. The little end user can hardly tell the difference!

[dman]

I respectfully disagree. A contrary viewpoint which I happen to share is the following - As a software developer you build productivity multipliers for your users. Users spend non trivial amounts of time, money and energy building skills to master a tool you build. Users use these skills to earn a livelihood and sometimes due to a change in employer / life situation find themselves in a position where they do not have control over the OS that they need to be productive in. I think empathy with your user dictates that you try to maximize the combinations in which they can put their skills to productive use. Taking ideological positions on fit/finish/aesthetics is questionable if your user has to spend time relearning some other tool because you refused to port your software. The port might not be as pixel perfect but if it helps a user carry over their skills into a new job / earn more money then I will sleep well at night knowing I stood by users.

[pvg]

I think a 'user-centric' angle is one of the good ways to think about this but presenting one possible set of user priorities as some sort of high-minded moral imperative and a different one as 'questionable ideology' does not do your argument any favours.

There's a long-running subculture in MacOS (and once Nextstep and now iOS) software development that I'll call 'app craftsmanship'. At its best it produces high-quality, slick apps that usefully leverage the platform's strengths and build dedicated (and typically paying) user bases. So when someone puts out a new Mac or iOS and makes a fuss about how it's fully native and supports the Face Bar™, they're signaling to potential users 'Hey! I'm about to do some App Craftsmanship here, people' and hoping deciated users will flock to them, credit cards in hand. They're not selling to the people who are going to be irritated the app doesn't run on Ubuntu Maimed Mastodon. And that's not a moral failing, it's just market targeting.

[dman]

Now that you point it out, I realize that I should have edited the parts about questionable ideology out. It was needlessly argumentative and distracts from the point I was trying to make.

[pvg]

In that case you just end up with different kinds of user priorities and developers choosing to deploy their finite resources to address some of them. Not much mystery or sleep disruption left in it then.

[mrmanner]

Some alternatives to spending resources on porting your application are adding more features, providing better support, or making the application work even better on your chosen platform. Doing that and letting the small portion of users forced away from your platform learn a new tool is probably well spent resources.

After all, there are good Windows- and Linux specific applications as well, and for most fields learning a new tool for doing things you understand isn’t that hard.

[pjmlp]

Lazy development with race to the bottom.

Your example is how I used to develop portable native software as well.