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.
Sorry macOS users, but Apple has gone too far for some of us devs
81–90 of 118 posts
Re: Sorry macOS users, but Apple has gone too far for some of us devs
#82Earlier 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?
Re: Sorry macOS users, but Apple has gone too far for some of us devs
#83the 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…
Re: Sorry macOS users, but Apple has gone too far for some of us devs
#84Re: Sorry macOS users, but Apple has gone too far for some of us devs
#85Earlier 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.
Re: Sorry macOS users, but Apple has gone too far for some of us devs
#86Earlier 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.
Re: Sorry macOS users, but Apple has gone too far for some of us devs
#87Earlier 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.
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
#88Earlier 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?
Re: Sorry macOS users, but Apple has gone too far for some of us devs
#89As 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…
> ...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
#90Earlier 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?