
Sorry macOS users, but Apple has gone too far for some of us devs - samcat116
https://www.gridsagegames.com/blog/2019/09/sorry-mac-users-apple-doesnt-care-about-us-devs/
======
rs23296008n1
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.

~~~
dantondwa
What surprises me is the fact that the author doesn't talk about the craziest
of Apple's recent choices: the deprecation of OpenGL. This is much worse than
the deprecation of 32 bit and, IMHO, it's just Apple giving up on being a
relevant gaming platform. This, plus the lack of nvidia drivers and of support
for Vulkan.

All the small issues here show, together, that indeed Apple doesn't give a
shit about gaming and about interoperability with other platforms. They want
developers to be faithful to their locked garden and their technologies.

~~~
ohithereyou
> All the small issues here show, together, that indeed Apple doesn't give a
> shit about gaming and about interoperability with other platforms. They want
> developers to be faithful to their locked garden and their technologies.

Especially if it's only 4% of your sales. If 4% of your sales doesn't cover
the cost of a Mac, code signing, and the cost of support on the Mac then it's
a _net negative_ - you'll make more money not being on the Mac.

------
judge2020
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
I imagine Steam doesn't allow Gatekeeper bypasses. Still, notarization is
designed to be easy to script:
[https://developer.apple.com/documentation/xcode/notarizing_y...](https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow)
\- so it really shouldn't be an issue.

~~~
judge2020
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.

~~~
raverbashing
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)

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

~~~
gridspy
1\. You also need to pay apple a subscription, update your hardware, change
your build process. I think there is also a review step during the build.

2\. All the existing tooling (not the game, but the build process) will need
to be 64 bit to run on this new hardware. So the build needs to be re-worked

3\. People on Mac require more support, which is harder because dev is not a
Mac user.

~~~
povertyworld
Do these guys complain this much about releasing games on consoles too?

~~~
Aeolun
That’s a fundamentally different platform I think.

~~~
yjftsjthsd-h
In some ways, it isn't that different; consoles are just computers with some
platform-weirdness. But I do actually agree insofar as that I can reasonably
target NT, Darwin, and Linux from one machine (so long as it's a mac or I'm
willing to break the Apple EULA), but to target consoles, so far as I know,
requires purchasing additional hardware.

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

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

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

~~~
trothamel
You have to pay for the signing. You also have to wait several minutes for the
notarization process to finish, and submit every program to Apple.

~~~
new_realist
All malware checkers must read the app binary to be effective. Apple forces
the app to be scanned once, not one million times on one million desktops.

~~~
trothamel
Apple also forces every single app for macOS to be submitted to them. Seeing
as how Apple has historically been willing to compete with the applications on
their platform, that seems to at least have the potential to be a problem.

~~~
johncolanduoni
If they want to use your compiled binary to compete with you somehow, buying
one copy per app they want to put out of business seems like a better option
instead of setting up a whole notirization scheme to trick you into uploading
it to them.

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

~~~
spsful
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.

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

~~~
dickeytk
That’s not true. Apple prevents unsigned binaries from being executed at all.

~~~
her_tummy_hurts
That’s not true. You can bypass that.

~~~
dickeytk
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.

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

------
olliej
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
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
It's a Windows game. People are asking him about the possibility of a Mac
port.

~~~
olliej
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)

~~~
unicornfinder
I mean, I agree with you completely but what I've found is that a lot of
games, whilst are 64-bit themselves, often have a lot of dependencies that,
for whatever reason, still have 32-bit binaries in there somewhere.

------
floatingatoll
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_y...](https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow)

~~~
CrendKing
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.

~~~
judge2020
If Windows also required code signing as a deterrent to malware being
distributed, we'd see similar prices (depending on the code signing reseller,
currently cheapest is $59/year for 3 years). Instead, we have a huge third-
party antivirus market that only deals with malware after the fact.
Notarization is Apple's approach to pre-screening applications and will
certainly be constantly improving its detection.

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

~~~
rufius
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
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
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.

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

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

------
tmaly
why is dropping 32-bit support even a consideration?

~~~
atroche
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
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.

------
djohnston
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
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?".

