Live data from Hacker News

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

gridsagegames.com

81–90 of 118 posts

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

#81
post #31

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…

> That aside, Apple manages to do this Also pretty much everyone else - I just checked the status of all the apps present on my Mac (System Report) and the only 32-bit apps on here are QuickTime Player 7 (long-deprecated) and a bunch of garbage Adobe background update processes.

Yup, complaining about deprecating 32bit seems to primarily be a choice by game devs who care about frame rates, but will happily throwaway 10-20% perf win that you get on x86_64

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

#82
post #32

Earlier quoted context omitted.

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.

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

Probably, consoles aren't mentioned at all in the blog post or on the game's website.

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

#83

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…

What is your game?

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

#84
post #41

Earlier quoted context omitted.

Please don’t use that term in the way you’re using it. It’s offensive and unnecessary.

I'm quoting the guy above me. Go tell him.

Two wrongs don't make a right.

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

#85

Earlier quoted context omitted.

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.

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

That’s not true. You can bypass that.

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

#86
post #64

Earlier quoted context omitted.

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... - so it really shouldn't be an issue.

The only issue is it can take an hour or more - https://news.ycombinator.com/item?id=21110622 polling for the status to finalize would waste build minutes on your CI.

In my (limited) experience, for non-GB-sized apps, the turnaround time is closer to five minutes.

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

#87
post #64

Earlier quoted context omitted.

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... - so it really shouldn't be an issue.

The only issue is it can take an hour or more - https://news.ycombinator.com/item?id=21110622 polling for the status to finalize would waste build minutes on your CI.

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)

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

#88
post #32

Earlier quoted context omitted.

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.

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

Ironically, releasing on consoles got easier over the years. Patch certification cost (and possibly the entire requirement for indies) got dropped and programs like ID@Xbox allow you to release your game for free.

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

#89

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…

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.

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

#90
post #56

Earlier quoted context omitted.

> It’s not burdensome As defined by who? 1. Submit build 2. Wait an hour 3. Retrieve notary receipt 4. Staple to correct build 5. Upload build Sure sounds more burdensome to me than: 1. Upload build Edit: Lol, people arguing with reality. It may or may not be a good thing, but arguing that it doesn’t add any burden to the developer seems hard to me.

Wouldn't you have jenkins (or whatever your build system is) do that all for you?

Not necessarily.
Post reply on HN