7 ms·

I used to think it'd be easier to just not support Macs at all for most smaller tech companies, and after reading this, I still think that. Apple has not chang

I used to think it'd be easier to just not support Macs at all for most smaller tech companies, and after reading this, I still think that. Apple has not changed its policy in over a decade: they don't care about software devs, they don't want you to release your stuff there, and only the biggest companies who are willing to throw dev after dev at the problem get to participate in the walled garden. Screw 'em, release your software on Windows and Linux and don't look back.

128keaton 3y ago
This is a Qt5 project and not really indicative of the actual development experience imho. Writing native software for native platforms with native UI and bindings is a big undertaking but worth it in the long term
olliej 3y ago
I'm sorry, what is the bit that is hard? * You have to setup the binary to build N times (done automatically if you use the tools apple provides while apparently not caring about developers) * In this case you have to setup a non-standard UI toolkit, which obviously is going to make things harder, and make that build universal as well. Qt claims to support mac and iOS so I'm surprised that doesn't happen by default * Codesign, which is a trivial step The hardest part here is just the "I don't want to make a native app so I'm going to build an entire 3rd party UI toolkit", which is not an argument that apple doesn't care about devs.
- tumult 3y ago
  Apple requires “notarization,” not just code signing. If you code sign your app and don’t “notarize” it, it will refuse to run. Like it will be harder for the end user to run it than if you had not code signed it at all. Submitting for “notarization” requires an Apple developer account with an active paid subscription and payment method. You have to upload it to Apple and wait for it to be approved in an asynchronous process which can sometimes take tens of minutes each time.
  - chii 3y ago
    > sometimes take tens of minutes each time you only do that for the final build. It does prevent unscrupulous malware distributors, since there's now a paper trail linking it back to you if you did bad. Of course, this could be abused by apple to gatekeep, and it doesn't prevent the user from downloading the app and bypassing this security measure (so does not in actual fact stop all malware).
- DiabloD3 3y ago
  If I were to make a normal desktop app with a UI, I'd consider Qt before the rest of the toolkits (at least, until Iced finally catches up). Even on an OSX-only app, I'm sure as hell not using SwiftUI/UIKit/etc. Qt more consistently nails native apps, the so-called-native UI toolkit on any given OS doesn't. You seem to think "codesign" is the trivial step: it is not. Many many times that entire step has made it to the top of the front page on HN, on how many dev teams simply cannot get this to work right consistently, and will break in ways that cannot be debugged using the tool output or the documentation. Nobody has this level of problem on Windows: I just sign it using a valid cert, and its done. I don't need to buy a Microsoft-made computer or need to run Visual Studio or pay Microsoft $100 a year and then still have random reports of Windows users being unable to run my binary; however, HN has popularized countless stories of devs being forced to buy a Mac (which means no OSX in a VM, no OSX build farms, very spotty CI<->OSX integration), having to pay Apple $100 a year to notarize the signing (which they can also refuse to do, without recourse), having to use XCode (at least for the signing step), and they still have situations where the binary is not being signed and/or notarized, or OSX will randomly fail to run the binary, or it actively prevents users from running the binary without telling anyone why, but giving scary messages to non-tech users anyways. I'm sorry, but how the hell is a trillion dollar company getting this wrong? Apple has broken priorities, and shilling/fanboying for them on here is not going to fix the problem.
  - olliej 3y ago
    If I were to make a normal desktop app for Mac I'd use AppKit. IMO, a lot of the UI things apple has introduced in the last few years have been attempting to get the people making apps for iOS to also make them for macOS in a way that isn't just an iOS app running on a larger screen. I guess the alternative is that everyone continues making these horrific apps built on top of chrome wrappers like electron, bring Sun's vision of everyone shipping a single crappy app to every platform. > I'm sorry, but how the hell is a trillion dollar company getting this wrong? Apple has broken priorities, and shilling/fanboying for them on here is not going to fix the problem. I'm sure you have a solution then? One that doesn't require the alternative of "every app must be from a central store that reviews and approves every app"? > shilling/fanboying for them on here is not going to fix the problem. Name calling and personal attacks doesn't help anyone, and it certainly doesn't inspire me to think you're willing to argue in good faith.
deleted 3y ago
[deleted]
rvz 3y ago
> I used to think it'd be easier to just not support Macs at all for most smaller tech companies, and after reading this, I still think that. There is only one platform to support: macOS. I can target all supported Mac users 100% of the time. Windows is similar and is also one OS to support and one can target their Windows software to Windows users 100% of the time. > Screw 'em, release your software on Windows and Linux and don't look back. How do you define Linux support especially when you cannot guarantee supporting all Linux users and distros?
- DiabloD3 3y ago
  Best effort. Binary Qt and GTK apps compiled even 10-15 years ago often still work, and do so on almost any distro. Games are a bit more iffy, depending on if it used SDL or not; and Steam on Linux has made great effort to make the (admittedly few) older Linux binaries remain alive (and if Steam doesn't, the community has). I don't see this as an issue. Using Linux implies a level of competency from the customer, and I'd rather help a competent Linux customer try to get my stuff run on their odd distro (ex: Alpine) than help an incompetent Windows or OSX user. One gets me a customer for life, the other just reminds me that hell is other people.
  - lockhouse 3y ago
    > Binary Qt and GTK apps compiled even 10-15 years ago often still work, and do so on almost any distro. That hasn’t been my experience at all. Also, the desktop Linux market is minuscule. It is an order of magnitude smaller than the macOS market. There’s a reason commercial software vendors don’t usually bother with it.
  - rvz 3y ago
    > Best effort. That isn't good enough. It is not a guarantee of full OS support and you are forced to select a limited set of distros that you can support despite them all running a Linux kernel. That is not the case with Windows or macOS which the majority of users have been using for their Desktops for decades. [0] > I don't see this as an issue. Using Linux implies a level of competency from the customer, and I'd rather help a competent Linux customer try to get my stuff run on their odd distro (ex: Alpine) than help an incompetent Windows or OSX user. Why should one always assume that their customers are kernel engineers or know what a compiler is to get their GUI app running on their system? I would not give free or paid support on unsupported systems, especially when the Linux user-base is vanishingly tiny. If your software can be run by tech-illiterate users on Windows / Macs and they are paying for it, that is a much better outcome than wasting hours helping one Linux user run your software on an obscure distro either for free or paid. [0] https://gs.statcounter.com/os-market-share/desktop/worldwide/ https://gs.statcounter.com/os-market-share/desktop/worldwide...
solarkraft 3y ago
I also dislike Apple's software development process (for iOS especially), but for some reason a lot of new software appears on macOS first.
- vachina 3y ago
  What new software?
  - solarkraft 3y ago
    Fancy terminal emulators (Warp?), browsers (Orion, Arc), some machine learning stuff (that Whisper GUI and ollama front-end) immediately come to my mind. Anecdotally any single-platform launch on HN will be on macOS.

128keaton 3y ago

This is a Qt5 project and not really indicative of the actual development experience imho. Writing native software for native platforms with native UI and bindings is a big undertaking but worth it in the long term

olliej 3y ago

I'm sorry, what is the bit that is hard? * You have to setup the binary to build N times (done automatically if you use the tools apple provides while apparently not caring about developers) * In this case you have to setup a non-standard UI toolkit, which obviously is going to make things harder, and make that build universal as well. Qt claims to support mac and iOS so I'm surprised that doesn't happen by default * Codesign, which is a trivial step The hardest part here is just the "I don't want to make a native app so I'm going to build an entire 3rd party UI toolkit", which is not an argument that apple doesn't care about devs.

tumult 3y ago
Apple requires “notarization,” not just code signing. If you code sign your app and don’t “notarize” it, it will refuse to run. Like it will be harder for the end user to run it than if you had not code signed it at all. Submitting for “notarization” requires an Apple developer account with an active paid subscription and payment method. You have to upload it to Apple and wait for it to be approved in an asynchronous process which can sometimes take tens of minutes each time.
- chii 3y ago
  > sometimes take tens of minutes each time you only do that for the final build. It does prevent unscrupulous malware distributors, since there's now a paper trail linking it back to you if you did bad. Of course, this could be abused by apple to gatekeep, and it doesn't prevent the user from downloading the app and bypassing this security measure (so does not in actual fact stop all malware).
DiabloD3 3y ago
If I were to make a normal desktop app with a UI, I'd consider Qt before the rest of the toolkits (at least, until Iced finally catches up). Even on an OSX-only app, I'm sure as hell not using SwiftUI/UIKit/etc. Qt more consistently nails native apps, the so-called-native UI toolkit on any given OS doesn't. You seem to think "codesign" is the trivial step: it is not. Many many times that entire step has made it to the top of the front page on HN, on how many dev teams simply cannot get this to work right consistently, and will break in ways that cannot be debugged using the tool output or the documentation. Nobody has this level of problem on Windows: I just sign it using a valid cert, and its done. I don't need to buy a Microsoft-made computer or need to run Visual Studio or pay Microsoft $100 a year and then still have random reports of Windows users being unable to run my binary; however, HN has popularized countless stories of devs being forced to buy a Mac (which means no OSX in a VM, no OSX build farms, very spotty CI<->OSX integration), having to pay Apple $100 a year to notarize the signing (which they can also refuse to do, without recourse), having to use XCode (at least for the signing step), and they still have situations where the binary is not being signed and/or notarized, or OSX will randomly fail to run the binary, or it actively prevents users from running the binary without telling anyone why, but giving scary messages to non-tech users anyways. I'm sorry, but how the hell is a trillion dollar company getting this wrong? Apple has broken priorities, and shilling/fanboying for them on here is not going to fix the problem.
- olliej 3y ago
  If I were to make a normal desktop app for Mac I'd use AppKit. IMO, a lot of the UI things apple has introduced in the last few years have been attempting to get the people making apps for iOS to also make them for macOS in a way that isn't just an iOS app running on a larger screen. I guess the alternative is that everyone continues making these horrific apps built on top of chrome wrappers like electron, bring Sun's vision of everyone shipping a single crappy app to every platform. > I'm sorry, but how the hell is a trillion dollar company getting this wrong? Apple has broken priorities, and shilling/fanboying for them on here is not going to fix the problem. I'm sure you have a solution then? One that doesn't require the alternative of "every app must be from a central store that reviews and approves every app"? > shilling/fanboying for them on here is not going to fix the problem. Name calling and personal attacks doesn't help anyone, and it certainly doesn't inspire me to think you're willing to argue in good faith.

deleted 3y ago

[deleted]

rvz 3y ago

> I used to think it'd be easier to just not support Macs at all for most smaller tech companies, and after reading this, I still think that. There is only one platform to support: macOS. I can target all supported Mac users 100% of the time. Windows is similar and is also one OS to support and one can target their Windows software to Windows users 100% of the time. > Screw 'em, release your software on Windows and Linux and don't look back. How do you define Linux support especially when you cannot guarantee supporting all Linux users and distros?

DiabloD3 3y ago
Best effort. Binary Qt and GTK apps compiled even 10-15 years ago often still work, and do so on almost any distro. Games are a bit more iffy, depending on if it used SDL or not; and Steam on Linux has made great effort to make the (admittedly few) older Linux binaries remain alive (and if Steam doesn't, the community has). I don't see this as an issue. Using Linux implies a level of competency from the customer, and I'd rather help a competent Linux customer try to get my stuff run on their odd distro (ex: Alpine) than help an incompetent Windows or OSX user. One gets me a customer for life, the other just reminds me that hell is other people.
- lockhouse 3y ago
  > Binary Qt and GTK apps compiled even 10-15 years ago often still work, and do so on almost any distro. That hasn’t been my experience at all. Also, the desktop Linux market is minuscule. It is an order of magnitude smaller than the macOS market. There’s a reason commercial software vendors don’t usually bother with it.
- rvz 3y ago
  > Best effort. That isn't good enough. It is not a guarantee of full OS support and you are forced to select a limited set of distros that you can support despite them all running a Linux kernel. That is not the case with Windows or macOS which the majority of users have been using for their Desktops for decades. [0] > I don't see this as an issue. Using Linux implies a level of competency from the customer, and I'd rather help a competent Linux customer try to get my stuff run on their odd distro (ex: Alpine) than help an incompetent Windows or OSX user. Why should one always assume that their customers are kernel engineers or know what a compiler is to get their GUI app running on their system? I would not give free or paid support on unsupported systems, especially when the Linux user-base is vanishingly tiny. If your software can be run by tech-illiterate users on Windows / Macs and they are paying for it, that is a much better outcome than wasting hours helping one Linux user run your software on an obscure distro either for free or paid. [0] https://gs.statcounter.com/os-market-share/desktop/worldwide/ https://gs.statcounter.com/os-market-share/desktop/worldwide...

solarkraft 3y ago

I also dislike Apple's software development process (for iOS especially), but for some reason a lot of new software appears on macOS first.

vachina 3y ago
What new software?
- solarkraft 3y ago
  Fancy terminal emulators (Warp?), browsers (Orion, Arc), some machine learning stuff (that Whisper GUI and ollama front-end) immediately come to my mind. Anecdotally any single-platform launch on HN will be on macOS.