[dman]

Am curious why some vector rendering products (Amadine, OmniGraffle, Paper 53 etc) end up being Mac / iOS only? Are there some APIs that are Mac only? Why would devs who take an effort to write such a substantial app not ifdef away the rendering bits to make the app work on Windows.

[eddieh]

Because Mac applications are more than just rendering APIs, its about the windows, menus, controls, and a complete cohesive UI that works like all the user's other applications. As a Mac user I'll always pick a Mac only app over any cross-platform app.

The second reason is that Mac users pay for software. You can sustain a business as an independent software vendor by targeting only Mac users. Linux users tend to want all free & open source software. Windows users tend to steal apps. A disproportionate number of Windows users I know are happy to steal all their commercial software—I'm not just talking about students and economically disadvantaged people, I'm talking about 6-figure salary software developers.

By building a cross-platform app you will decrease the amount of paying Mac users while increasing the number of Windows users willing to steal from you. The amount of work required to support Windows and all the missed Mac sales may not be worth the effort.

[kitsunesoba]

Cocoa provides exceptionally good graphics APIs that make it surprisingly fast and easy to churn out powerful graphic editing apps. Nothing else quite compares. The closest would probably be Skia or Cairo, neither of which is as easy to work with or does as much out of the box.

[Gene_Parmesan]

Well, if it's Mac-native, it's likely made using ObjC or Swift with Cocoa. Porting this to Win32 would be a very substantial amount of work -- right of the top, you wouldn't be able to use Swift -- and that's work that's likely not worth it if 90%+ of your customer base are Mac users.

[pvg]

The entire UI is OS-specific. If this was a matter of #ifdefs, we wouldn't have 50 page weekly discussions on the merits of various cross-platform technologies.

[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.

[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.

[floatingatoll]

Much of the substance depends on OS-provided convenience APIs that, if you use certain aspects thereof, can’t be replicated on Windows without developing them from scratch.