20 ms·

Sorry macOS users, but Apple has gone too far for some of us devs

142 points by samcat116 7y ago

tmaly 7y ago
why is dropping 32-bit support even a consideration?
- atroche 7y ago
  Maybe Cogmind depends on libraries which don’t support 64 bit? I agree though, it’s a bit weird. Maybe it’s harder for game-related libraries to switch, compared to the ones I’m used to using in my apps.
  - dmix 7y ago
    Does this mean they are using unmaintained gaming libraries? Or is it just turtles all the way down of people not wanting to take responsibility to switch to 64bit because some random thing they depend on didn’t upgrade so they aren’t to blame? And this chain of side stepping of an obvious issue went on for well over a decade? I know it’s in human behaviour to delay things until they absolutely have to do something. Like we all learned in school doing less important homework. But in software there are always dialing pressures to modernize while supporting backwards compatibility. 10yr timeframes are sufficient here and from there if you want to use old stuff then it’s on both the user or the publisher to use some virtualization solution to provide long term support beyond this.
- kunai 7y ago
  People will mention new libraries requiring 64-bit or to reduce the installed size of macOS but I think both of those explanations are (mostly) BS. Microsoft has an unhealthy obsession with backwards-compatibility due to their enterprise market base. Apple has the opposite problem, where they consistently remove legacy features (in many cases, features that are not even "legacy" in nature but required for normal usage scenarios) without giving users a chance to catch-up. Sometimes this is warranted, as it is with removing optical drives, other times, it is not -- such as dropping 32-bit support when neither Windows nor Linux have any intention of doing so in the near future. This philosophy been accelerating in absurd fashion lately, whether it's dropping the headphone jack from the iPad Pro, the "butterfly keyboard," or leaving the MacBook Pro with no USB-A ports or SD card slot -- two extremely well-adopted technologies that are still ubiquitous nearly half a decade from the release of the all USB-C MacBook Pro.
- stordoff 7y ago
  Old game, potentially (you can't continue to sell them without updating them).
  - crooked-v 7y ago
    Cogmind dates to 2015, it's hardly 'old'.
- EricE 7y ago
  And people like to make lite of the "Y2K fiasco" - here's how Y2K happened...
wjdp 7y ago
Does Apple have to sign games distributed through Steam? I thought that only applied to their own app store.
- rufius 7y ago
  Mojave and Catalina added more restrictions around non-App Store programs where you need to sign and notarize. I know I’ll probably catch downvotes for it but I think this is a good thing for the average user as someone in security. I know it makes it more of a walled garden but I also know that the harder it is to run untrusted code, the better for the average user. The “terrible burden” is a couple of extra button clicks if working in Xcode or you could automate it with a script. I did the latter for the project I work on and it’s been fine. That probably drives a lot of folks to Linux and that’s okay. I’m for diversity in platforms but I’m also for strong protections for the users.
  - kunai 7y ago
    Letting megacorporations decide what you do and do not get to do with your personal property isn't really what I would count as a "good thing" in any circumstance. Apple has gotten away with eliminating user freedoms time and time again under the guise of security. In many scenarios Apple's attitude towards its end-users increases perceived security while causing significant hurdles for actual security, such as how iOS no longer allows you to turn off Bluetooth or WiFi from the Control Center. Somehow I've never really seen an explanation for why this is better for security for the vast majority of people.
    - ldrndll 7y ago
      You are still able to run unsigned (and now unnotarized) software. It requires holding down a single key when first launching it. I’m pretty sure the trade off here - to prevent the average, relatively uninformed user - from downloading and running random software is very much a worthwhile trade off for malware protection etc.
    - judge2020 7y ago
kgarten 7y ago
So the major points are dropping 32bit support and Apple forcing you to sign your executable? The author claims that you need to pay Apple for the signing. as far as I know this is not true. You just need to pay for being on the application stores ...
- dexter0 7y ago
  You have to pay the $99/yr to be in the developer program, to access to the notarization service.
  - jchw 7y ago
    Also I heard that you need fairly new Mac hardware to actually use the notarization service. Now try to integrate it with your CI, because the feedback that the notarization is complete is sent via email. (FWIW: I don’t have first-hand experience, though I still have an Apple developer license. Probably won’t renew.)
    - lstamour 7y ago
      You’re not kidding about the email. It’s email or manual polling, no webhooks. Strange. Well, I can suddenly imagine a lot of CI servers will be running SMTP. ;-) > After uploading your app, the notarization process typically takes less than an hour. When the process completes, you receive an email indicating the outcome. Additionally, you can use altool with the notarization-history flag to inspect the status of all of your notarization requests https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow https://developer.apple.com/documentation/xcode/notarizing_y...
      - judge2020 7y ago
        Electron-notarize polls: https://github.com/electron/electron-notarize/blob/b3156157f8e5e9fbddac9c5b250f97f9e0d7e5f0/src/index.ts#L83 https://github.com/electron/electron-notarize/blob/b3156157f...
    - 7y ago
dickeytk 7y ago
I’m glad Apple is locking down binaries. It’s terrifying what malicious binaries are capable of. For games in particular there should be better sand boxing options.
- falcolas 7y ago
  Signed binaries don't stop malicious binaries. It can help prevent the spread of malicious binaries once they've been identified as malicious, but it does nothing to stop the initial mayhem.
  - qtplatypus 7y ago
    I don't think that the signed binaries are intended to prevent malicious binaries but rather instead to create an evidence trail once an malicious binary has been submitted. Since you have to sign with a key that you have payed apple to authorize. Apple has the payment details that connect you and the signed binary together. In addition the membership has licence conditions that in turn allow Apple to sue you. The intent is a deterrent effect.
  - dickeytk 7y ago
    That’s not true. Apple prevents unsigned binaries from being executed at all.
    - her_tummy_hurts 7y ago
      That’s not true. You can bypass that.
      - dickeytk 7y ago
        Well of course it can be bypassed, but it certainly doesn’t “step in” at some point either as was suggested. It blocks all unsigned binaries regardless of any damage they’ve caused. Though this morning I realized I misunderstood the point of the grandparent here. He was saying you can have a signed binary that is still malicious. I thought they were talking about what apple does in the case of unsigned.
deleted 7y ago
[deleted]
Despegar 7y ago
64-bit support first arrived in Leopard in 2007. Everyone has had plenty of time.
- spsful 7y ago
  That's what I don't understand about this. He's using 32-bit deprecation as one of his main reasons for dropping macOS support, yet his decision to exclusively use the older architecture arguably makes the user experience worse. Of course they would like new features, but a modern 64-bit foundation should not be out of the question. It's almost like Microsoft has incentivized this by supporting the older architecture. I know that probably isn't the case, but it seems like this developer should modernize his program. Edit: take my words with a grain of salt-- I'm not an experienced developer.
- plorkyeran 7y ago
  Also, there was only ever one set of macs released in 2006 which had a 32-bit Intel processor, as the transition to 64-bit happened only a year after the Intel transition. We're not merely long past the point where you have no excuse for not supporting 64-bit; we're long past where it made any sense to support 32-bit. Even in 2010 if you started a port to macOS and decided to target 32-bit you would be making a bad decision.
judge2020 7y ago
Notarization and needing a paid developer account doesn't change the requirement for running software on OSX relative to the previous version. Before, you needed to sign with a "developer ID distribution" certificate if you wanted to avoid having to tell users to "ctrl-click DMG then click open" to bypass gatekeeper. This certificate required a paid developer account. Now you can still distribute un-signed, un-notarized software and tell users to ctrl-click open to bypass gatekeeper. All this does is require notarization (Apple running malware analysis) to have it run without a ctrl-click.
- btown 7y ago
  I imagine Steam doesn't allow Gatekeeper bypasses. Still, notarization is designed to be easy to script: https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow https://developer.apple.com/documentation/xcode/notarizing_y... - so it really shouldn't be an issue.
  - judge2020 7y ago
    The only issue is it can take an hour or more - https://news.ycombinator.com/item?id=21110622 https://news.ycombinator.com/item?id=21110622 polling for the status to finalize would waste build minutes on your CI.
    - Wevah 7y ago
      In my (limited) experience, for non-GB-sized apps, the turnaround time is closer to five minutes.
    - raverbashing 7y ago
      Well but you don't need to notarize all builds, just those that went through internal QA Split the build process so that you can click "version 1.2.3" and have it notarized (this is doable in Jenkins for example)
    - wolph 7y ago
      My limited experience notarizing a hello world react electron app took 10 to 15 minutes. Not that much but a large increase from the 1 minute build time before
gok 7y ago
Yikes. If you can't figure out how to make your code 64-bit safe, or how to make code signing work, you are effective requiring your users to give you root access. Completely unacceptable for a game.
- delfinom 7y ago
  > you are effective requiring your users to give you root access Wait, it's either code sign and you don't get root or don't code sign and get root? How retarded is macOS? Why is there no "no code sign and no root, just run as the user"?
  - povertyworld 7y ago
    I'm pretty sure on Linux if you wanted to run Quake3 you had to run as root due to needing direct access to the GPU. Is Linux "retarded" too?
    - op00to 7y ago
      Please don’t use that term in the way you’re using it. It’s offensive and unnecessary.
      - povertyworld 7y ago
        I'm quoting the guy above me. Go tell him.
        lonelappde 7y ago
        Two wrongs don't make a right.
      - iliketocomplain 7y ago
        What?
    - crooked-v 7y ago
      Plenty of coding practices from 1999 are completely unacceptable today.
olliej 7y ago
Seriously, OS X went 64bit 12 years ago. X86 has been 64bit for longer. Maybe, just maybe, the problem is developers refusing to actually move forward. It’s especially galling given game devs are the group that most prominently complains about OS X being behind the times. As for “needlessly” dropping 32bit: if your poorly written 32bit app starts up you necessarily force OS X (and the user’s machine) to pull in 32bit variants of almost the entire platform. Thanks for that. It also means Apple has to maintain 32bit versions of every framework. I can speak from experience here: maintaining a 32bit version of javascriptcore was a massive amount of work. Every new JS feature needs duplicated JIT work, and needlessly complicates the entire JSC codebase. That aside, Apple manages to do this - and I can’t imagine your game approaches the complexity of an entire OS -so if you can’t make your software work on a 64bit system then the problem is your code, not Apple.
- soneil 7y ago
  The number of 32bit intel macs is surprisingly small, too. Core Solo/Duo models ran from January to November 2006 (bar one mac mini model that survived into 2007). I'd be very surprised if there's a 32bit mac that'll run their game acceptably well. I'd be surprised if it's ever actually supported 32bit macs. So why was it 32bit in the first place?
  - cwyers 7y ago
    It's a Windows game. People are asking him about the possibility of a Mac port.
    - olliej 7y ago
      Ok, but if the game is only a few years old why didn’t it compile for 64bit? I recognize MS insisted on screwing the market by selling 32 vs 64 bit as separate versions of Windows for many years, but even then surely most windows machines have been running 64 by default for a decade? But seriously: if you make a new piece of software in the last 15 years that only works in 32bit, then you made a choice to target an obsolete platform with worse performance (again, game developers complaining about perf while only building 32bit so throwing away 10-20% perf for no reason strikes me as hollow)
DizzyDoo 7y ago
the first commercial downloadable game I released back in 2015, that let me become a full-time indie developer, has done roughly 25% of its revenue over the last four years on Mac. This is adding together the % of copies sold on Steam for Mac users, and the Apple Mac Store, where my game was featured on the main page for three months. Notarization, and 64-bit support, and all that aside, the audience on Mac that you can sell to is massive, especially since a lot of developers just ignore the platform - I'm fully expecting to support as many macOS devices as I can for my next game.
- crooked-v 7y ago
  I feel like there's also something of a snowball effect here because in certain genres the available set of games are good enough to rarely need to reboot into Windows. All the Paradox strategy games, X-COM, a variety of indie games built on Unity, etc. It feels like the only thing I'm ever consistently missing out on is FPS games, and even then there's been workable ports of stuff like Deus Ex.
  - ohithereyou 7y ago
    Anything requiring more than Intel integrated graphics tends to not work well on the Mac. The vast majority of Mac models can't even take a dedicated GPU upgrade, so you're stuck with whatever Apple soldered to your motherboard and at their mercy for graphics driver upgrades. The only time I've seen anyone try to seriously game on the Mac was a friend of mine that built a Hackintosh with a (brand new at the time) nVidia GeForce 1080ti. He couldn't even maintain 60+ FPS on Rocket League. So there's no wonder why games that require that level of GPU performance don't sell well on the Mac.
- godzillabrennus 7y ago
  What is your game?
pastastickers 7y ago
> Of course Mac support request ratios will vary by game due to architecture and player base, but there’s little question that they’re higher in general, ... Why? What is the nature of these support requests? Are they specific to your game? Could it be because your game was not properly made for macOS to begin with?
- ohithereyou 7y ago
  In the minds of Apple, anything not programmed solely for the Mac is 'not properly made for macOS'. It's shades of "you're holding it wrong" again.
floatingatoll 7y ago
This article fails to address two key points that could significantly weaken its core arguments if answered. Those points and the questions that arise from each are: 1) Apple charges a flat rate of $100/year for notarization access. Steam and Mac App Store take 15-30%. What additional percentage of Mac sales (either subscription and/or one-time) is being spent on this annually by this developer? $100/year & 100 units/year = $1.00/unit $100/year & 1000 units/year = $0.10/unit $100/year & 10000 units/year = $0.01/unit EDIT: Steam indicates that this game has sold 0-20,000 units (max 168 concurrent players), between May 2015 and September 2019, so using a straight flatline average of the best-case scenario for sales, the cost to date per unit is: $500/5y & 23000 units/5y = $0.22/unit 2) Notarization can be added to command-line build scripts and Makefiles and third-party processes, so that it is simple to ensure that builds are notarized as part of releases to Steam. What, if any, engineering obstacles in the developer’s build process blocked this integration? https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow https://developer.apple.com/documentation/xcode/notarizing_y...
- CrendKing 7y ago
  The argument from the article is that in non-Apple ecosystem, the ongoing fee is 0, which is smaller than all 3 of your listed examples. Also, as opposed to "simple command-line build scripts", in non-Apple ecosystem, there is no script required to release versions. I don't see the argument weakened, but rather strengthened.
  - floatingatoll 7y ago
    Your argument is based on an unstated framing assumption: “A cheaper and simpler process is better for developers and users, and therefore the absence of both cost and complexity is universally the best solution, without regard for any other factors.” That is not a widely agreed-upon assumption. Since the post relies on this same assumption-by-framing approach, its arguments are weakened by their dependence on an unstated assumption. Answering my questions would force that assumption to be considered openly - and potentially challenged. Is it better for users that Apple is doing this, regardless of the extra cost and time it assigns to developers? That’s the question that should be being asked here. Unfortunately, it is not.
least 7y ago
I certainly don't blame the developer for not supporting macOS, but the reasoning he outlines in his post aren't particularly compelling to me. It seems to me porting his game over to MacOS in itself would be a larger undertaking and more valid complaint than the ones he's listed. The notarization process potentially reducing the number of builds he can push to users in a day from 6 to something less seems like a feature, not a negative.
rs23296008n1 7y ago
As someone who recently worked in game dev I'm not sure why 32 bit was even a factor as 64 bit is likely your default target anyway - has been for awhile. So, killing 32 bit is not a real issue. Notorizing can be seen as just another cost of targeting a platform. So do it. You will need at least one machine anyway to do basic testing on. So use that. Get the cheapest imac or whatever you require. So, mac hardware isn't a real issue. I found the statistics a bit strange as well. Sales were 2% linux, 4% mac, 94% windows. Yet support was divided 30% linux, 50% mac and 20% windows. This suggests linux is more problematic per sale than mac. Yet he has no issue with linux. If this was me, I'd be wanting to know exactly why linux/mac was generating so many tickets. The answer will likely help the overall product. Personally, you need to jump through so many hoops to release software that none of these thus far mentioned should be big enough to stop you. The real reasons should be: is there a demand in this target market; will that demand generate sufficient profit? As I'm starting my own journey on this I see all the platforms and app stores have various issues. Everything has tradeoffs. The article's author needs to come up with better arguments. I just don't see his reasons as relevant in comparison to the other much larger costs associated with development. I'd actually recommend targeting multiple platforms just to force bugs to come out. Different platforms / compilers see and expose different issues in your codebase. So far I'm quite happy to have cross platform support even when i don't necessarily release on those platforms yet. I find art, sound and game assets are more expensive than an apple dev account or even a mac computer. Others have written in more detail on this. Even generic business costs exceed the subscription/computer costs he's stating as being barriers.
- aylmao 7y ago
  I'm not a game dev but just as a developer I do think a lot of these assumptions are a little unfair. You can't call things "not a real issue" just because they're not a big issue to you. > ...64 bit is likely your default target anyway - has been for awhile. So, killing 32 bit is not a real issue. If you depend on 32-bit software, no, it is a real issue. Updating an app and dependencies to all be 64-bit can be a pretty big issue. Not everyone is on a modern stack. > ...linux is more problematic per sale than mac. Yet he has no issue with linux. If I were on a PC I would have less issue with linux too, simply because I don't need to buy special hardware or switch computers to deal with those tickets. > If this was me, I'd be wanting to know exactly why linux/mac was generating so many tickets. The answer will likely help the overall product. Will it? If they're platform issues, they're not improving the product, just getting it to run. > Personally, you need to jump through so many hoops to release software that none of these thus far mentioned should be big enough to stop you. You don't know this guy's resources though. That's like telling someone, if you're already come 25 miles, 5 miles aren't that much more. If they're in a car, sure. If they are running, yes it is— every mile is a lot. > The real reasons should be: is there a demand in this target market; will that demand generate sufficient profit? I think the fact only 4% of sales come from macOS means there isn't much demand or profit, right? > As I'm starting my own journey on this I see all the platforms and app stores have various issues. Everything has tradeoffs. The article's author needs to come up with better arguments. The arguments are good. You yourself just said it. Everything has tradeoffs, and the tradeoffs of developing for macOS are just not worth this person's time. > I just don't see his reasons as relevant in comparison to the other much larger costs associated with development. Except do you really know his costs, and the resources he has to cover said costs? > I'd actually recommend targeting multiple platforms just to force bugs to come out. Different platforms / compilers see and expose different issues in your codebase. Wait, what? What's the point of killing bugs for a platform you don't support though? Maybe when I develop for web I should text in IE 5. It'll surface so many "bugs" in my site.
zelienople 7y ago
As an active Apple dev with five commercial apps, I agree with the sentiment in the article. I'm ready to leave Apple the moment something better comes along. Since Steve died, every decision at Apple has been anti-dev and anti-user. The price/performance of the hardware is awful. Apple is the current tech leader in planned obsolescence. Old hardware is iCloud locked by default with no option to contact the registered owner to tell them that they forgot to unlock it. Now they want to extend that practice to laptops. The developer documentation is universally awful. The version changes in Swift are so drastic and frequent that you can't find solutions for the current version because the Internet is polluted with information about previous versions. They are glacially slow to fix bugs. They have removed basic networking functionality covered in the RFCs. They instantly kill backgrounded apps in a mad race for style over function. I. Could. Go. On. TL;dr I hate Apple with a burning passion and only inertia keeps me in the Apple dev world.
EricE 7y ago
As a Mac user why should I care about this developer who's never released Mac software and probably wouldn't have anyway? When someone like the Omni Group or Panic writes a similar screed than it will be newsworthy. This? Hardly...
djohnston 7y ago
It seems better to just say it isn't worth the effort because you're a small indy dev who doesnt have time to handle a bunch of heterogenous platforms. None of those things seem that bad if you had > 1 people contributing
macrbl 7y ago
Aging thread by now, but had to chime in with some clarifications as an indie dev dealing with similar issues, to respond to those saying stuff like 'you're a bad dev if your app isn't 64-bit by now'. I am a company of 1 humbly maintaining a cross platform app that's been around long enough to predate the 64-bit era. It's about 70%/30% Windows/Mac sales. When the majority of machines out there became 64-bit years ago, I happily optimized the components of my app that stood to benefit from 64-bit, such as intensive media processing tasks and other bottlenecks. But since a lot of computing tasks just don't need what 64-bit offers, parts of my app that were working well enough using 32-bit components stayed that way, and users never knew the difference or cared because over the years I strategically targeted the areas to rewrite as 64-bit without having to reinvent the wheel and devote resources to rewriting everything. Since the 64-bit x86 instruction set was implemented to sit on top of the legacy 32-bit one, it is literally impossible for x86 hardware to cease supporting 32-bit into the future. So we have Apple here making the choice to cease software support of this backward compatibility feature already baked into the cpu, to save a few bucks or whatever. There is no performance benefit to abandoning 32-bit. Your Mac won't be faster on Catalina because 32-bit support is gone, despite what Apple is trying to imply in their marketing, because the cpus they use are still built from the ground up to support 32-bit. A negligible-by-today's-standards amount of RAM and disk space used by the system will be conserved, but that's really it. So Apple, the wealthiest software company ever, has decided to stop funding software support of a feature already present in the hardware they are selling you at ungodly markups, thus screwing over both customers out of legacy app support, and indie devs with costly extra refactoring work that in many cases offers no perceivable benefits to end users. This is why it is infuriating to be an indie dev supporting Mac right now. As for my specific case, my software, under the hood a combination of several 32-bit and 64-bit processes, still runs happily on Windows, and most of my customers are on Windows, particularly large organizations that purchase site licenses and sponsor new features or customization projects. But in order for it to be 100% 64-bit, so much of it would have to change due to old dependencies as to require rewriting a huge chunk of it from scratch. This is my technical debt to bear. When it became apparent a few years ago that Mac would phase out 32-bit support, I began work on a full 64-bit rewrite, but I've been sidetracked as customization projects and consulting gigs from Windows-only customers continued to pour in and with limited resources as a small company I had to choose to prioritize those projects which added tangible features to my software right now at the expense of making progress on the 64-bit rewrite. I continue to work on the rewrite project so that I can continue to support the Mac platform, but it sure feels like a whole lot of work to port features to 64-bit that won't have any noticeable improvement to end users! In the mean time I feel terrible that Mac users who upgrade won't be able to use my software until I get around to completing the 64-bit version. But it just never made sense for a company of my scale to devote resources to racing to complete a 64-bit rewrite for the sake of those 30% of sales. These are the kinds of choices that a small business must make and thus is the position I find myself in as an indie Mac developer. I hope this provides an understandable real world answer to the question of "how can any app under active development in 2019 still be relying on 32-bit?".

142 points by samcat116 7y ago

tmaly 7y ago

why is dropping 32-bit support even a consideration?

atroche 7y ago
Maybe Cogmind depends on libraries which don’t support 64 bit? I agree though, it’s a bit weird. Maybe it’s harder for game-related libraries to switch, compared to the ones I’m used to using in my apps.
- dmix 7y ago
  Does this mean they are using unmaintained gaming libraries? Or is it just turtles all the way down of people not wanting to take responsibility to switch to 64bit because some random thing they depend on didn’t upgrade so they aren’t to blame? And this chain of side stepping of an obvious issue went on for well over a decade? I know it’s in human behaviour to delay things until they absolutely have to do something. Like we all learned in school doing less important homework. But in software there are always dialing pressures to modernize while supporting backwards compatibility. 10yr timeframes are sufficient here and from there if you want to use old stuff then it’s on both the user or the publisher to use some virtualization solution to provide long term support beyond this.
kunai 7y ago
People will mention new libraries requiring 64-bit or to reduce the installed size of macOS but I think both of those explanations are (mostly) BS. Microsoft has an unhealthy obsession with backwards-compatibility due to their enterprise market base. Apple has the opposite problem, where they consistently remove legacy features (in many cases, features that are not even "legacy" in nature but required for normal usage scenarios) without giving users a chance to catch-up. Sometimes this is warranted, as it is with removing optical drives, other times, it is not -- such as dropping 32-bit support when neither Windows nor Linux have any intention of doing so in the near future. This philosophy been accelerating in absurd fashion lately, whether it's dropping the headphone jack from the iPad Pro, the "butterfly keyboard," or leaving the MacBook Pro with no USB-A ports or SD card slot -- two extremely well-adopted technologies that are still ubiquitous nearly half a decade from the release of the all USB-C MacBook Pro.
stordoff 7y ago
Old game, potentially (you can't continue to sell them without updating them).
- crooked-v 7y ago
  Cogmind dates to 2015, it's hardly 'old'.
EricE 7y ago
And people like to make lite of the "Y2K fiasco" - here's how Y2K happened...

wjdp 7y ago

Does Apple have to sign games distributed through Steam? I thought that only applied to their own app store.

rufius 7y ago
Mojave and Catalina added more restrictions around non-App Store programs where you need to sign and notarize. I know I’ll probably catch downvotes for it but I think this is a good thing for the average user as someone in security. I know it makes it more of a walled garden but I also know that the harder it is to run untrusted code, the better for the average user. The “terrible burden” is a couple of extra button clicks if working in Xcode or you could automate it with a script. I did the latter for the project I work on and it’s been fine. That probably drives a lot of folks to Linux and that’s okay. I’m for diversity in platforms but I’m also for strong protections for the users.
- kunai 7y ago
  Letting megacorporations decide what you do and do not get to do with your personal property isn't really what I would count as a "good thing" in any circumstance. Apple has gotten away with eliminating user freedoms time and time again under the guise of security. In many scenarios Apple's attitude towards its end-users increases perceived security while causing significant hurdles for actual security, such as how iOS no longer allows you to turn off Bluetooth or WiFi from the Control Center. Somehow I've never really seen an explanation for why this is better for security for the vast majority of people.
  - ldrndll 7y ago
    You are still able to run unsigned (and now unnotarized) software. It requires holding down a single key when first launching it. I’m pretty sure the trade off here - to prevent the average, relatively uninformed user - from downloading and running random software is very much a worthwhile trade off for malware protection etc.
  - judge2020 7y ago

kgarten 7y ago

So the major points are dropping 32bit support and Apple forcing you to sign your executable? The author claims that you need to pay Apple for the signing. as far as I know this is not true. You just need to pay for being on the application stores ...

dexter0 7y ago
You have to pay the $99/yr to be in the developer program, to access to the notarization service.
- jchw 7y ago
  Also I heard that you need fairly new Mac hardware to actually use the notarization service. Now try to integrate it with your CI, because the feedback that the notarization is complete is sent via email. (FWIW: I don’t have first-hand experience, though I still have an Apple developer license. Probably won’t renew.)
  - lstamour 7y ago
    You’re not kidding about the email. It’s email or manual polling, no webhooks. Strange. Well, I can suddenly imagine a lot of CI servers will be running SMTP. ;-) > After uploading your app, the notarization process typically takes less than an hour. When the process completes, you receive an email indicating the outcome. Additionally, you can use altool with the notarization-history flag to inspect the status of all of your notarization requests https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow https://developer.apple.com/documentation/xcode/notarizing_y...
    - judge2020 7y ago
      Electron-notarize polls: https://github.com/electron/electron-notarize/blob/b3156157f8e5e9fbddac9c5b250f97f9e0d7e5f0/src/index.ts#L83 https://github.com/electron/electron-notarize/blob/b3156157f...
  - 7y ago

dickeytk 7y ago

I’m glad Apple is locking down binaries. It’s terrifying what malicious binaries are capable of. For games in particular there should be better sand boxing options.

falcolas 7y ago
Signed binaries don't stop malicious binaries. It can help prevent the spread of malicious binaries once they've been identified as malicious, but it does nothing to stop the initial mayhem.
- qtplatypus 7y ago
  I don't think that the signed binaries are intended to prevent malicious binaries but rather instead to create an evidence trail once an malicious binary has been submitted. Since you have to sign with a key that you have payed apple to authorize. Apple has the payment details that connect you and the signed binary together. In addition the membership has licence conditions that in turn allow Apple to sue you. The intent is a deterrent effect.
- dickeytk 7y ago
  That’s not true. Apple prevents unsigned binaries from being executed at all.
  - her_tummy_hurts 7y ago
    That’s not true. You can bypass that.
    - dickeytk 7y ago
      Well of course it can be bypassed, but it certainly doesn’t “step in” at some point either as was suggested. It blocks all unsigned binaries regardless of any damage they’ve caused. Though this morning I realized I misunderstood the point of the grandparent here. He was saying you can have a signed binary that is still malicious. I thought they were talking about what apple does in the case of unsigned.

deleted 7y ago

[deleted]

Despegar 7y ago

64-bit support first arrived in Leopard in 2007. Everyone has had plenty of time.

spsful 7y ago
That's what I don't understand about this. He's using 32-bit deprecation as one of his main reasons for dropping macOS support, yet his decision to exclusively use the older architecture arguably makes the user experience worse. Of course they would like new features, but a modern 64-bit foundation should not be out of the question. It's almost like Microsoft has incentivized this by supporting the older architecture. I know that probably isn't the case, but it seems like this developer should modernize his program. Edit: take my words with a grain of salt-- I'm not an experienced developer.
plorkyeran 7y ago
Also, there was only ever one set of macs released in 2006 which had a 32-bit Intel processor, as the transition to 64-bit happened only a year after the Intel transition. We're not merely long past the point where you have no excuse for not supporting 64-bit; we're long past where it made any sense to support 32-bit. Even in 2010 if you started a port to macOS and decided to target 32-bit you would be making a bad decision.

judge2020 7y ago

Notarization and needing a paid developer account doesn't change the requirement for running software on OSX relative to the previous version. Before, you needed to sign with a "developer ID distribution" certificate if you wanted to avoid having to tell users to "ctrl-click DMG then click open" to bypass gatekeeper. This certificate required a paid developer account. Now you can still distribute un-signed, un-notarized software and tell users to ctrl-click open to bypass gatekeeper. All this does is require notarization (Apple running malware analysis) to have it run without a ctrl-click.

btown 7y ago
I imagine Steam doesn't allow Gatekeeper bypasses. Still, notarization is designed to be easy to script: https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow https://developer.apple.com/documentation/xcode/notarizing_y... - so it really shouldn't be an issue.
- judge2020 7y ago
  The only issue is it can take an hour or more - https://news.ycombinator.com/item?id=21110622 https://news.ycombinator.com/item?id=21110622 polling for the status to finalize would waste build minutes on your CI.
  - Wevah 7y ago
    In my (limited) experience, for non-GB-sized apps, the turnaround time is closer to five minutes.
  - raverbashing 7y ago
    Well but you don't need to notarize all builds, just those that went through internal QA Split the build process so that you can click "version 1.2.3" and have it notarized (this is doable in Jenkins for example)
  - wolph 7y ago
    My limited experience notarizing a hello world react electron app took 10 to 15 minutes. Not that much but a large increase from the 1 minute build time before

gok 7y ago

Yikes. If you can't figure out how to make your code 64-bit safe, or how to make code signing work, you are effective requiring your users to give you root access. Completely unacceptable for a game.

delfinom 7y ago
> you are effective requiring your users to give you root access Wait, it's either code sign and you don't get root or don't code sign and get root? How retarded is macOS? Why is there no "no code sign and no root, just run as the user"?
- povertyworld 7y ago
  I'm pretty sure on Linux if you wanted to run Quake3 you had to run as root due to needing direct access to the GPU. Is Linux "retarded" too?
  - op00to 7y ago
    Please don’t use that term in the way you’re using it. It’s offensive and unnecessary.
    - povertyworld 7y ago
      I'm quoting the guy above me. Go tell him.
      - lonelappde 7y ago
        Two wrongs don't make a right.
    - iliketocomplain 7y ago
      What?
  - crooked-v 7y ago
    Plenty of coding practices from 1999 are completely unacceptable today.

olliej 7y ago

Seriously, OS X went 64bit 12 years ago. X86 has been 64bit for longer. Maybe, just maybe, the problem is developers refusing to actually move forward. It’s especially galling given game devs are the group that most prominently complains about OS X being behind the times. As for “needlessly” dropping 32bit: if your poorly written 32bit app starts up you necessarily force OS X (and the user’s machine) to pull in 32bit variants of almost the entire platform. Thanks for that. It also means Apple has to maintain 32bit versions of every framework. I can speak from experience here: maintaining a 32bit version of javascriptcore was a massive amount of work. Every new JS feature needs duplicated JIT work, and needlessly complicates the entire JSC codebase. That aside, Apple manages to do this - and I can’t imagine your game approaches the complexity of an entire OS -so if you can’t make your software work on a 64bit system then the problem is your code, not Apple.

soneil 7y ago
The number of 32bit intel macs is surprisingly small, too. Core Solo/Duo models ran from January to November 2006 (bar one mac mini model that survived into 2007). I'd be very surprised if there's a 32bit mac that'll run their game acceptably well. I'd be surprised if it's ever actually supported 32bit macs. So why was it 32bit in the first place?
- cwyers 7y ago
  It's a Windows game. People are asking him about the possibility of a Mac port.
  - olliej 7y ago
    Ok, but if the game is only a few years old why didn’t it compile for 64bit? I recognize MS insisted on screwing the market by selling 32 vs 64 bit as separate versions of Windows for many years, but even then surely most windows machines have been running 64 by default for a decade? But seriously: if you make a new piece of software in the last 15 years that only works in 32bit, then you made a choice to target an obsolete platform with worse performance (again, game developers complaining about perf while only building 32bit so throwing away 10-20% perf for no reason strikes me as hollow)

DizzyDoo 7y ago

the first commercial downloadable game I released back in 2015, that let me become a full-time indie developer, has done roughly 25% of its revenue over the last four years on Mac. This is adding together the % of copies sold on Steam for Mac users, and the Apple Mac Store, where my game was featured on the main page for three months. Notarization, and 64-bit support, and all that aside, the audience on Mac that you can sell to is massive, especially since a lot of developers just ignore the platform - I'm fully expecting to support as many macOS devices as I can for my next game.

crooked-v 7y ago
I feel like there's also something of a snowball effect here because in certain genres the available set of games are good enough to rarely need to reboot into Windows. All the Paradox strategy games, X-COM, a variety of indie games built on Unity, etc. It feels like the only thing I'm ever consistently missing out on is FPS games, and even then there's been workable ports of stuff like Deus Ex.
- ohithereyou 7y ago
  Anything requiring more than Intel integrated graphics tends to not work well on the Mac. The vast majority of Mac models can't even take a dedicated GPU upgrade, so you're stuck with whatever Apple soldered to your motherboard and at their mercy for graphics driver upgrades. The only time I've seen anyone try to seriously game on the Mac was a friend of mine that built a Hackintosh with a (brand new at the time) nVidia GeForce 1080ti. He couldn't even maintain 60+ FPS on Rocket League. So there's no wonder why games that require that level of GPU performance don't sell well on the Mac.
godzillabrennus 7y ago
What is your game?

pastastickers 7y ago

> Of course Mac support request ratios will vary by game due to architecture and player base, but there’s little question that they’re higher in general, ... Why? What is the nature of these support requests? Are they specific to your game? Could it be because your game was not properly made for macOS to begin with?

ohithereyou 7y ago
In the minds of Apple, anything not programmed solely for the Mac is 'not properly made for macOS'. It's shades of "you're holding it wrong" again.

floatingatoll 7y ago

This article fails to address two key points that could significantly weaken its core arguments if answered. Those points and the questions that arise from each are: 1) Apple charges a flat rate of $100/year for notarization access. Steam and Mac App Store take 15-30%. What additional percentage of Mac sales (either subscription and/or one-time) is being spent on this annually by this developer? $100/year & 100 units/year = $1.00/unit $100/year & 1000 units/year = $0.10/unit $100/year & 10000 units/year = $0.01/unit EDIT: Steam indicates that this game has sold 0-20,000 units (max 168 concurrent players), between May 2015 and September 2019, so using a straight flatline average of the best-case scenario for sales, the cost to date per unit is: $500/5y & 23000 units/5y = $0.22/unit 2) Notarization can be added to command-line build scripts and Makefiles and third-party processes, so that it is simple to ensure that builds are notarized as part of releases to Steam. What, if any, engineering obstacles in the developer’s build process blocked this integration? https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow https://developer.apple.com/documentation/xcode/notarizing_y...

CrendKing 7y ago
The argument from the article is that in non-Apple ecosystem, the ongoing fee is 0, which is smaller than all 3 of your listed examples. Also, as opposed to "simple command-line build scripts", in non-Apple ecosystem, there is no script required to release versions. I don't see the argument weakened, but rather strengthened.
- floatingatoll 7y ago
  Your argument is based on an unstated framing assumption: “A cheaper and simpler process is better for developers and users, and therefore the absence of both cost and complexity is universally the best solution, without regard for any other factors.” That is not a widely agreed-upon assumption. Since the post relies on this same assumption-by-framing approach, its arguments are weakened by their dependence on an unstated assumption. Answering my questions would force that assumption to be considered openly - and potentially challenged. Is it better for users that Apple is doing this, regardless of the extra cost and time it assigns to developers? That’s the question that should be being asked here. Unfortunately, it is not.

least 7y ago

I certainly don't blame the developer for not supporting macOS, but the reasoning he outlines in his post aren't particularly compelling to me. It seems to me porting his game over to MacOS in itself would be a larger undertaking and more valid complaint than the ones he's listed. The notarization process potentially reducing the number of builds he can push to users in a day from 6 to something less seems like a feature, not a negative.

rs23296008n1 7y ago

As someone who recently worked in game dev I'm not sure why 32 bit was even a factor as 64 bit is likely your default target anyway - has been for awhile. So, killing 32 bit is not a real issue. Notorizing can be seen as just another cost of targeting a platform. So do it. You will need at least one machine anyway to do basic testing on. So use that. Get the cheapest imac or whatever you require. So, mac hardware isn't a real issue. I found the statistics a bit strange as well. Sales were 2% linux, 4% mac, 94% windows. Yet support was divided 30% linux, 50% mac and 20% windows. This suggests linux is more problematic per sale than mac. Yet he has no issue with linux. If this was me, I'd be wanting to know exactly why linux/mac was generating so many tickets. The answer will likely help the overall product. Personally, you need to jump through so many hoops to release software that none of these thus far mentioned should be big enough to stop you. The real reasons should be: is there a demand in this target market; will that demand generate sufficient profit? As I'm starting my own journey on this I see all the platforms and app stores have various issues. Everything has tradeoffs. The article's author needs to come up with better arguments. I just don't see his reasons as relevant in comparison to the other much larger costs associated with development. I'd actually recommend targeting multiple platforms just to force bugs to come out. Different platforms / compilers see and expose different issues in your codebase. So far I'm quite happy to have cross platform support even when i don't necessarily release on those platforms yet. I find art, sound and game assets are more expensive than an apple dev account or even a mac computer. Others have written in more detail on this. Even generic business costs exceed the subscription/computer costs he's stating as being barriers.

aylmao 7y ago
I'm not a game dev but just as a developer I do think a lot of these assumptions are a little unfair. You can't call things "not a real issue" just because they're not a big issue to you. > ...64 bit is likely your default target anyway - has been for awhile. So, killing 32 bit is not a real issue. If you depend on 32-bit software, no, it is a real issue. Updating an app and dependencies to all be 64-bit can be a pretty big issue. Not everyone is on a modern stack. > ...linux is more problematic per sale than mac. Yet he has no issue with linux. If I were on a PC I would have less issue with linux too, simply because I don't need to buy special hardware or switch computers to deal with those tickets. > If this was me, I'd be wanting to know exactly why linux/mac was generating so many tickets. The answer will likely help the overall product. Will it? If they're platform issues, they're not improving the product, just getting it to run. > Personally, you need to jump through so many hoops to release software that none of these thus far mentioned should be big enough to stop you. You don't know this guy's resources though. That's like telling someone, if you're already come 25 miles, 5 miles aren't that much more. If they're in a car, sure. If they are running, yes it is— every mile is a lot. > The real reasons should be: is there a demand in this target market; will that demand generate sufficient profit? I think the fact only 4% of sales come from macOS means there isn't much demand or profit, right? > As I'm starting my own journey on this I see all the platforms and app stores have various issues. Everything has tradeoffs. The article's author needs to come up with better arguments. The arguments are good. You yourself just said it. Everything has tradeoffs, and the tradeoffs of developing for macOS are just not worth this person's time. > I just don't see his reasons as relevant in comparison to the other much larger costs associated with development. Except do you really know his costs, and the resources he has to cover said costs? > I'd actually recommend targeting multiple platforms just to force bugs to come out. Different platforms / compilers see and expose different issues in your codebase. Wait, what? What's the point of killing bugs for a platform you don't support though? Maybe when I develop for web I should text in IE 5. It'll surface so many "bugs" in my site.

zelienople 7y ago

As an active Apple dev with five commercial apps, I agree with the sentiment in the article. I'm ready to leave Apple the moment something better comes along. Since Steve died, every decision at Apple has been anti-dev and anti-user. The price/performance of the hardware is awful. Apple is the current tech leader in planned obsolescence. Old hardware is iCloud locked by default with no option to contact the registered owner to tell them that they forgot to unlock it. Now they want to extend that practice to laptops. The developer documentation is universally awful. The version changes in Swift are so drastic and frequent that you can't find solutions for the current version because the Internet is polluted with information about previous versions. They are glacially slow to fix bugs. They have removed basic networking functionality covered in the RFCs. They instantly kill backgrounded apps in a mad race for style over function. I. Could. Go. On. TL;dr I hate Apple with a burning passion and only inertia keeps me in the Apple dev world.

EricE 7y ago

As a Mac user why should I care about this developer who's never released Mac software and probably wouldn't have anyway? When someone like the Omni Group or Panic writes a similar screed than it will be newsworthy. This? Hardly...

djohnston 7y ago

It seems better to just say it isn't worth the effort because you're a small indy dev who doesnt have time to handle a bunch of heterogenous platforms. None of those things seem that bad if you had > 1 people contributing

macrbl 7y ago

Aging thread by now, but had to chime in with some clarifications as an indie dev dealing with similar issues, to respond to those saying stuff like 'you're a bad dev if your app isn't 64-bit by now'. I am a company of 1 humbly maintaining a cross platform app that's been around long enough to predate the 64-bit era. It's about 70%/30% Windows/Mac sales. When the majority of machines out there became 64-bit years ago, I happily optimized the components of my app that stood to benefit from 64-bit, such as intensive media processing tasks and other bottlenecks. But since a lot of computing tasks just don't need what 64-bit offers, parts of my app that were working well enough using 32-bit components stayed that way, and users never knew the difference or cared because over the years I strategically targeted the areas to rewrite as 64-bit without having to reinvent the wheel and devote resources to rewriting everything. Since the 64-bit x86 instruction set was implemented to sit on top of the legacy 32-bit one, it is literally impossible for x86 hardware to cease supporting 32-bit into the future. So we have Apple here making the choice to cease software support of this backward compatibility feature already baked into the cpu, to save a few bucks or whatever. There is no performance benefit to abandoning 32-bit. Your Mac won't be faster on Catalina because 32-bit support is gone, despite what Apple is trying to imply in their marketing, because the cpus they use are still built from the ground up to support 32-bit. A negligible-by-today's-standards amount of RAM and disk space used by the system will be conserved, but that's really it. So Apple, the wealthiest software company ever, has decided to stop funding software support of a feature already present in the hardware they are selling you at ungodly markups, thus screwing over both customers out of legacy app support, and indie devs with costly extra refactoring work that in many cases offers no perceivable benefits to end users. This is why it is infuriating to be an indie dev supporting Mac right now. As for my specific case, my software, under the hood a combination of several 32-bit and 64-bit processes, still runs happily on Windows, and most of my customers are on Windows, particularly large organizations that purchase site licenses and sponsor new features or customization projects. But in order for it to be 100% 64-bit, so much of it would have to change due to old dependencies as to require rewriting a huge chunk of it from scratch. This is my technical debt to bear. When it became apparent a few years ago that Mac would phase out 32-bit support, I began work on a full 64-bit rewrite, but I've been sidetracked as customization projects and consulting gigs from Windows-only customers continued to pour in and with limited resources as a small company I had to choose to prioritize those projects which added tangible features to my software right now at the expense of making progress on the 64-bit rewrite. I continue to work on the rewrite project so that I can continue to support the Mac platform, but it sure feels like a whole lot of work to port features to 64-bit that won't have any noticeable improvement to end users! In the mean time I feel terrible that Mac users who upgrade won't be able to use my software until I get around to completing the 64-bit version. But it just never made sense for a company of my scale to devote resources to racing to complete a 64-bit rewrite for the sake of those 30% of sales. These are the kinds of choices that a small business must make and thus is the position I find myself in as an indie Mac developer. I hope this provides an understandable real world answer to the question of "how can any app under active development in 2019 still be relying on 32-bit?".