Hacker News Reader

Comment by unlinked_dll | Hacker News Reader

As a developer mainly on MacOS I feel the author's pain. There's also some legitimate gripes about Apple locking down their platform in a way that is ultimately hostile to users down the road.

As a user I say suck it up. Notarization and 1st party QA will make users lives so much easier. I have yet to see people run into serious issues with either that weren't doing things that entitlements/signing were designed to prevent.

The $100/year dev license kinda sucks if you just want to hack around and distribute code, but it also goes a long way to stopping people from creating spam accounts and evading bans. But it's a pretty trivial burden, if you're distributing software professionally and can't cough up $100 in revenue in a year... maybe try your hand at something else or just go the amateur route?

I also don't get complaining about obsoleting 32 bit. Use obsolete software on an obsolete OS in a VM like the rest of us, we all hate supporting things until the end of time.

View on HN

> just go the amateur route?

But how do you even go the amateur route? You still won't be able to distribute what you make.

A big part of my childhood was making games, and sharing them on shareware sites in the mid 90s. It sucks that kids today aren't going to be able to do that. There was no way I could afford $100 as a 10 year old.

Well you could write your game in JS and deliver it over the web. Flash games were all the rage when I was a kid.

But for now, non-notarized executables don't fail, they just need to be enabled by an admin account through permissions.

You surely can’t be oblivious to how this has been a process of boiling the frog slowly — almost certainly they will eventually be permanent-blocked like on iOS.

You surely can't be oblivous that, user wise (security, ease of use) this is a process of improvement slowly...

MacOS might have bugs due to neglect, bad priorties, too fast deprecations, etc.

But all the extra restrictions (notarization, sandboxing, dropping 32-bits, etc) are in the right direction for a consumer platform (i.e. not for devs), for making the computers easier and more secure, like appliances that just do what you bought them for. And they will be part of any/all platforms going forward (including Windows, and new platforms like Fucscia).

As for Linux, it exists for 2.5 decades, it has been free since forever, it's still not adopted by the masses. It's not in the direction that most want.

I'm not sure who you're arguing with, but the poster I was replying to noted the status quo is that you can run unnotarized executables. To your point, that should not be taken to mean that we won't eventually see it evaporate. On the contrary, we should assume it will.

>I'm not sure who you're arguing with

I'm arguing against your comment: "You surely can’t be oblivious to how this has been a process of boiling the frog slowly — almost certainly they will eventually be permanent-blocked like on iOS".

And I'm saying that this is a good thing in some ways (whereas "boiling the frog slowly" doesn't just point to the graduality of the process, but also implies it's bad).

I don't disagree on the graduality or that we will "eventually see it evaporate" (it being various current more open abilities).

To kill the analogy — developers are unambiguously the frog. You’re arguing about who we should care more about, the frog or those who will be having frog for dinner — this has no bearing on if the frog being boiled is a bad thing but it certainly is from the vantage point of the frog ;)

WebGL isn't fully supported on iOS, so there goes your nice little web game.

If you're an amateur and can't afford $100 dev license, why are you targeting a premium mobile platform that you'd need to test on?

Just don't support ~~MacOS~~ [e: iOS, my b], this is what I mean by going the "amateur" route. If you don't care about distributing software professionally, then just don't deal with the headaches and costs.

Last I checked MacOS wasn't a premium mobile platform... it's a general computing platform for desktops and laptops.

I was replying to the comment that WebGL isn't fully supported on iOS.

Last year I was building web games* with Phaser. To better support iOS, I just changed the renderer to `canvas` when an iOS user agent was detected. In the end, the games worked pretty well on iOS devices.

*Games I worked on: https://livegame.show/play/ride_v3 | https://livegame.show/play/pewpew_v6 | https://livegame.show/play/bubbleshooter3

I will say though, Apple does seem to almost purposefully hold back the web on iOS. I suppose this makes native iOS apps, which must pay Apple 30% of their revenue, more appealing to users. On iOS, the Firefox and Chrome apps aren't allowed to include their own browser engines. They have to just wrap Safari webviews.

On Android, the Firefox app is allowed to include it's own browser engine. An engine that supports adblocking extensions like uBlock Origin.

I think this is an issue with phaser. I’ve also made a bunch of web games with various frameworks, and webGL works fine on iOS in many other contexts. The js port of cocos2d is webGL compatible on iOS.

Consider though that flash was a security dumpster fire that coincidentally ran as fast as something unburdened by security concern, and that the most certainly pirated full Adobe suite used by a young beginner developer was installed by some sketchy exe that would no way be notarized by any sort of authority

You would think... but they already made it so even riot can't delete binaries from /use/bin, and you can't disable that setting (have to boot into a special mode)

You can still do that, you just have to find users dumb enough to authorize the running of an application downloaded randomly from the internet.

Oh, and they need to authorize it from an admin account. So, yeah. Not sure there are a lot of people out there that dumb. Unless you're some well known downloaded product like Blender or something, I would think you would have a hard time getting people to run your software.

At the same time, to be completely fair, you probably should have a hard time getting people to run your software. That's pretty much exactly how a lot of malware is distributed.

Thing is, for the common scenario of "safe enough for random users to install" we want some barrier of entry. The market where random creations of a ten year old are acceptable isn't the Apple Store, it's something like Roblox environment for user-created content or some other sandbox that is (a) isolated from the rest of the system and (b) makes it clear that it's likely not to meet even the (already low) standards of the generic Store.

For all the major means of distribution the problem isn't not enough apps, the problem is too much garbage - so the direction of improving end-user experience is more filtering of apps and developers, not easier access to distribution.

That is exactly what some developers just can't seem to get:

Many users agree with Apple.

But those developers are going: "No those users are wrong and should join my mob to make Apple let me do whatever I want to users' systems."

The amateurs will have to start distributing source. I remember back in the day when I was a kid making GameMaker games on Mac in the late 90s, sometimes I would collaborate with other developers and we would just send the source files around which were completely useable, but of course we wanted to distribute executables as if we were legitimate companies, even though our users were typically other kid developers. We had fake company names and stuff, but if we were emulating open source projects instead of cloistered corporations, we could've gotten more done together.

I predict this change will cause kids to embrace open source more and distribute their projects in a way that can be shared and reused.

I hypothesize "fantasy consoles"* are potentially fertile ground for young developers. They impose a lot of restrictions, but to someone starting out that means fairly low limits to understanding the basics of the environment (as opposed to something like UE4). They're also cheap or free. And some of them (like PICO-8) host user-created games.

*https://github.com/paladin-t/fantasy

Or just drop Apple and macOS. Even for an application like Krita, for creative people, macOS is a laughably small platform, with a very small user-base, bringing in next to nothing money-wise, nothing contribution-wise, and it tries to force everyone to use proprietary libraries like Metal, instead of properly supporting OpenGL and Vulkan.

From an effort-to-income perspective, macOS isn't worth it.

>From an effort-to-income perspective, macOS isn't worth it.

Apple has introduced Catalyst in Xcode -- this translates iOS apps to macOS, compile once and run on two platforms.

Mac App store has been notirous for not getting as much love as the iOS one but this change might reverse the direction as there will be a lot more apps coming for the Mac App Store now that they can leverage their iOS dev ecosystem.

I don't know If the Mac App Store will bring better apps and grater for enthousiasm than it is now for Apple Store business model, but you can be sure of one thing : notarisation program will not last. The goal is to lock the platform like iOS and force force every user to get their apps through the App Store and nowhere else.

I'm pretty sur once MacOS has switched to ARM, system partition will be in read only mode, you will not be able to install app outside of the AppStore except if you jailbreak thank to a "security flaw".

> for creative people, macOS is a laughably small platform, with a very small user-base, bringing in next to nothing money-wise, nothing contribution-wise

... As a user, statements like that – about any platform – honestly just make me want to avoid anything from the developers who make them.

The platform matters. Mac is intentionally expensive and exclusionary. They won't even sell their expensive OS to run on perfectly functional low cost computers. If you are going to blame the victims for that, I don't want you as a user either.

Apple got to where they are because users generally agree with them.

If a developer is going to attack users, the users are better off on Apple's side.

For Krita maybe.

Creative Suite stuff, which actual pro creatives use, on the other hand, has been 50-50 Mac/PC sales, even though the Mac has 10% or less of the desktop market.

That's how many creatives are on the platform.

If Krita can't tap into them, it's not the platform that's at fault...

Affinity, for example, does fine, as does Pixelmator...

This pretty much nails it. I don't know anyone on macOS who uses Krita, but that's not because macOS has such a tiny tiny userbase there's no reason for anyone to support it -- it's because Krita has neither measurable marketshare or mindshare on the Mac.

It may be a wonderful program now, I don't know, but I do remember KDE's initial efforts on the Mac -- and they were... I originally wrote "just awful," but I'll amend that to a weaker "not very good." I haven't actually seen any desktop GUI program whose primary platform is Linux really take off on the Mac, with the possible exception of LibreOffice. We have so many good cheap-to-free alternatives.

I used KDE as my primary desktop for a few years circa 2000-2004.

In fact I used "webkit" before it was webkit and before it was cool: I used Konqueror as my main browser (I didn't care for it being not compatible with many sites at the time, as I cared mostly for simpler, text-based sites which worked fine).

I remember all the "KDE Office" apps, various drawing programs, etc. They were and many are on a perennial semi-finished state, in a way that Windows and OS X equivalent are not. Krita has done well on that front, and a couple of others, but it took many years of not great releases. And in Windows/OS X they are non-starters as ports...

Yes, absolutely, poor people should not be able to try to develop their skills and attempt to make apps.

They can make apps and develop these skills, however, the apps listed for random end-users in the Apple store shouldn't contain all these experiments. This is about access to a particular distribution and advertising channel, which should happen after you've already developed the skills and are ready to offer something serious in context of which a $100/year investment is trivial.

Notarization is a requirement for distributing your content outside the app store. Within it the requirements are even higher.

Notarization isn't the same as the App Store.

This is about whether a 3rd-party application downloaded from a 3rd-pary website can be run. It used to be that you only needed to pay to get onto the distribution and advertising channel, now you need to pay not to make your user jump through special hoops on an admin account.

It's not implausible to suggest that in the future, that loophole will be removed as well. Apple does not want you to download apps that they can't personally vet.

The complaint isn't that you need to pay to get into their store. Of course you do, that isn't surprising to anyone. It's about whether distribution channels exist outside of their store.

As to why that's a problem? To quote the author:

> It really upsets me because the iOS App Store policies basically prohibited art or anything interesting (nudity, glitch, error art...temperamental depending on who reviewed you for approval).

> It was hell for me to get things approved, and even when I got them approved I had to change so much about my work it really wasn't my work anymore. A platform holder shouldn't dictate so much about someone else's work.

Apple has been consistently behind the curve when it comes to recognizing the artistic potential of games[0]. On a cultural level, we don't want want them to be a gatekeeper for a medium. As a company they aren't responsible enough or smart enough for that job.

[0]: https://www.theverge.com/2013/1/16/3879194/apple-app-store-g...

I fail to see the (new) change.

Gatekeeper was added in 2012, and required the user to either take steps (right click open, or disable gatekeeper via the Gui or command-line) to run apps not signed by a developer ID, which costs $99/yr.

Eventually Apple removed the option to disable Gatekeeper via the GUI due to developer abuse (e.g. games, including Minecraft, walking children through globally disabling security settings rather than signing their apps).

Notarization doesn't add the requirement of signing, nor does it change that you need a developer ID for $99/yr

If Apple considers walking users through the process of disabling Gatekeeper to be developer abuse, then I don't see how anyone can claim that notarization or the developer fees are optional.

The change is that in each release of Mac OS this process is getting harder to avoid and is starting to include additional requirements. "You need to sign apps" becomes "we need to run an automated review on our servers for every release you make." This matters because a lot of the original criticism around the original Gatekeeper was dismissed via the argument that it was just an optional security feature that was turned on by default. It wasn't like Apple was going to block 3rd-party marketplaces, this just made Mac OS safer for computer illiterate users.

With El Capitan, people are starting to suspect Apple does not want unvetted apps on the Mac in any context, and it seems more likely that future Mac OS versions will continue the trend of having stricter, more burdensome vetting requirements.

It is increasingly harder to take advocates at face value when they say that 5 years from now I'll be able to run a 3rd-party app on my Mac that didn't go through a manual review. Which might sound great to some people, some users love the app store.

As to why I think that could be a problem for creative mediums, see my parent post. It may not matter if Gatekeeper begins to live up to its name, because creative mediums may just migrate off of Mac. But if Mac becomes a platform too big to ignore, or if other platforms like Windows follow suite, then I think creative mediums will suffer.

Good lord, didn't anybody read the article? Or at least skim it?

Mac App Store apps are pure crap, for most of them. Cheap apps developed by chinese or indian developers or other coming from developping countries. A few apps are good but sell at inflated price. Games prices are outragious and sell for half the price on Steam.

My users and I both already paid an eyewatering price to get our Macs. Why should I have to pay to distribute my non malware app, which might even be free and open source, because my users want to defend against other people's malware?

Why is Apple blackmailing the industry over malware protection instead of making it a core part of the OS experience? I'd rather have malware protection than losing my Esc key or redoing the app window background textures yet again.

Why should I let you run non-sandboxed code on my machine?

What do you offer to earn my permission to allow your app?

If you are poor you probably aren't going to start with a Mac.

> I also don't get complaining about obsoleting 32 bit. Use obsolete software on an obsolete OS in a VM like the rest of us

You mean like games released last year which require heavy GPU usage? That's neither obsolete, nor a great experience.

Please cite one game—a single one—from last year which is 32-bit only and "requires heavy GPU usage".

One will do. I'm sure this won't take you long. Even if you can cite one, all that will prove is that the developer was so incredibly stupid that they ignored a full decade of warnings about how 32-bit software would be deprecated soon.

I'd be happy to tell you what it was, but I'm on holidays away from my laptop/steam account.

I'm not even sure it's possible to acquire hardware on which to compile and test a demanding game and not have a 64 bit Dev toolchain, without going to extra effort just to avoid 64bit for what purpose? A trivial performance improvement for an app that is resource intensive while also not needing 4gb Memory?

Notarization will not last. In 2 ou 3 years max, they play the card of security again and will stop the notarization program. Why do you believe they want to bring MacOS and iOS together through same processor family and same developement api ? They want to bring iOS business model to MacOS.

How is it not that obvious ?

"As a user... The $100/year dev license kinda sucks if you just want to hack around and distribute code"

As a user, what does $100 a year even accomplish? It is nothing more than a racket.

You don't need to pay to run your own code or distribute un-notorized code.

Apple is a trillion dollar company. It can easily support running 32-bit indefinitely, perhaps with a download for 32-bit libraries libraries and/or with some sort of containerization. As a platform holder it has the responsibility to do so. Failing to do that is a clear abdication.

It is clear from the post that Apple's platforms are hostile towards any sort of digital executable art.

It's not about "could" but about "should." Apple hasn't sold a computer with a 32 bit CPU in what, 8-9 years?

They deprecated 32 bit support almost a decade ago. Software has a lifespan and always has, to run obsolete code you need to jump through hoops to get an obsolete target running. This isn't new.

I've always wondered, what exactly is the overhead on running 32-bit code on a 64-bit machine? Why is support eventually dropped? I'm sure there are good reasons but I've no idea what they are.

I believe there is a little bit of overhead when it comes to mapping virtual addresses and dealing with different pointer sizes for the OS, but imo the main reason Apple wants to ditch 64 bit support is so their OS isn't tightly coupled to an ISA that has 32/64 bit modes.

In other words it's not about the overhead, it's about the reliance on x86.

If ISA decoupling is the goal then they should be mandating everyone write to a VM like the CLR or JVM (or variants like Dalvik).

It seems kind of silly to block x86 modes on x64 chips when the backwards compatibility needs of Windows pretty much insures "eternal" x86 modes. It's going to be a while before x86 modes disappear on Intel or AMD chips, and there's evidence to support that like the Itanium (IA-64) failure, and the fact that Windows on ARM made it a commitment to emulate x86 (but not x64) on ARM. x86 is likely going to be a lasting "lingua franca" ISA. Right now I'd almost put more money on x64 being retired before x86, and if anything from that perspective Apple is more tightly coupled to an ISA than before this choice.

> ...if anything from that perspective Apple is more tightly coupled to an ISA than before this choice.

That really depends on what their long-term goal is. If the speculation & rumors about an eventual ARM transition have any merit at all, then sunsetting 32-bit support now can help them smooth that transition, since they'll have a lot less work to do to implement whatever Rosetta-esque dynamic binary translator they would need.

Microsoft and Qualcomm together supposedly just invested tons of money in making sure that x86 emulates well on ARM64, but apparently had little success emulating x64 on ARM64. If the speculation and rumors about an ARM transition have merit, it seems backwards to sunset x86 and not x64.

Which it seems unlikely that Apple could do in secrecy what Microsoft + Qualcomm could not do (very publicly), but I guess all things are possible.

Yes, it is about should, and saying "it's a bit old" doesn't justify it.

Why is 8 years self-evidently "long enough"? Banks have code from the 1960s still running, and plenty of people have industrial hardware much older than that. Many of my household appliances are older.

It's only "obsolete" code because Apple has decided it is, it didn't rot.

"Long enough" is for certain a relative term. I don't think we should be making the comparison to banking software/appliances though. Banks are notoriously slow and I would think are more concerned with correctness than new features. Given how often we see complaints about archaic banking software I'm not sure if 1960's code is a good thing but it has longevity by design. Apple does not need to play by these rules and as an end user I'm ok with that. I think Apple should optimize for the 97-99% of average users even if it is at the expense of a few and I see this change in that lens. Besides, the users who use 8+ year old software probably have the know-how and the will to jury-rig a solution to get around this.

> Banks have code from the 1960s still running

The only reason "old code" still works in banks is because untold man hours are spent wrapping around it, working around it, and testing it.

A long time ago, some exec saw that some old thing needed updating because the world has changed. There are new regulations, new customers types, new products, new strategies...

A bunch of people get hired. A bright future of next thing is promised. It gets everyone excited and devs start cutting little chunks away off the old thing, making a new thing. Now there are 2 things to maintain, but that's ok, some day new thing will become next thing.

But the exec leaves (probably to another bank) before the next thing became a thing. Another exec comes in, declares the new thing is crap because it doesn't quite get the job done. A next next thing is planned. The previous new thing is now the old new thing. It will be removed, someday. Just not today, because it's _a_ thing now. old new thing will be sunset when next next thing arrives.

Many many years and several execs later, there are many things maintained by a small army of devs and testers. These things work in really strange, archaic, or even stupid ways. Nobody knows how (or worse, why) the entire system works. The most knowledgeable people only know how it _behaves_.

But it's there, still working. And your money is in that thing of things. Many peoples' money are in it.

That's not necessarily a good thing.

It's been longer than that. Core 2 Duos are 64 bit chips, and there were core 2 duo Macs releas e in late 2006, so it's been almost 13 yesrs.

The 32 bit support is actually a bit of a red herring here; the bigger issue for some is Apple dropping support for Carbon, a 32 bit only API made to ease porting of classic MacOS apps from the 80s and 90s to OS X, and itself deprecated in 2012.

I guess Apple could have created a 64 bit version, but it also seems reasonable to expect software developers to have rewritten effected software in that timespan. Carbon was originally a compromise for companies not wanting to learn an entire new OS (NeXTSTEP) and API/libraries when updating their apps for OS X -- the fact some apps still need it today is kind of mind boggling.

Then, I suppose the Win32 API has been stable-ish for far longer.

What's wrong with Carbon? CLI tools still work 40 year later. Tk/Qt/Swing programs still work 20+ years later. Why not updated and recompile carbon for 64bit?

A work of digital art is not "obsolete", and trying to pretend that it is is capitalist garbage.

There is lots of great modern art. but none of it makes older art "obsolete".

While I agree, I think there's an important caveat that is missing. To me, digital art needs to be self-contained. Digital art, unlike physical art, doesn't really rely on anything else for it to present itself. It's why digital media has standards. A .jpg should, in theory, be self-contained and only require a device to view. A game presenting itself as digital art, however, needs to be tied to a specific platform and software that may not potentially run in the future for any number of reasons. It needs to be feature-locked and self-contained so that it can be archived. To try and compare modern/older art to modern/older digital art isn't fair or equivalent, in my opinion.

Digital art, just like physical art, needs to be maintained.

If a painting sits in a moldy basement for a decade, don't be surprised when someone finally go to check on it at what happened.

Not true! The Intel Architecture CPUs that's in the Macs of today lets you seamlessly mix 32- and 64- bit processes. Windows 10 Operating System has no trouble managing both types of processes.

The argument that I have heard people make is that some ABIs are changing in 64 bit land, such as syscalls or how appkit talks to the window server, so they have to keep some 32 bit frameworks frozen in time in some places, and update them in others. Maintaining 32 bit versions of that is nonzero cost.

That said, I don't agree with such an argument. It seems like seeking out technical excuses for crappy user outcomes. In another thread on this topic I said: in any job there are parts that are fun and others that are not so fun but necessary. They should try to keep customer apps working.

If you want long term support, buy windows or get linux. Mac is for cutting edge beautiful experiences of the future, not legacy of the past. It's a trade-off. Supporting old tookits makes your Mac less pretty.

If that were true, maybe they should get rid of ancient relics like the Mach kernel. But honestly you sound like you believe Apple craps rainbows, or something. They aren't better than everybody else by virtue of self identity. They make lots of mistakes just like any other group of mortals.

> Apple hasn't sold a computer with a 32 bit CPU in what, 8-9 years?

The Mini was the last Mac to make the switch to 64-bit, in "Mid 2007". So a little over 12 years.

For comparison, the Macintosh was on M68K from 1984 to 1994 (10 years), and on PowerPC from 1994 to 2006 (12 years). IOW, the Mac has been on 64-bit x86 for as long as they've been on any CPU architecture ever.

Another fun fact: there was less than 10 years between the last Apple IIe they sold and the first Power Mac G5.

> ...if you're distributing software professionally and can't cough up $100 in revenue in a year...

This is kinda where I'm at with this. Surely anyone even remotely garnering an audience could raise this amount annually. It's a decent cost to an individual but to even a humble audience, it's peanuts.

If you can't raise even that, then IMO your game being lost is of little consequence. Not everything farted out by every indie developer is a lost masterpiece, sometimes stuff is lost because it lacks the traction to merit archival.

devil's advocate: $100 is a lot of money to spend on a hobby/side gig for a lot of people. Like some of us can blow more than that just on IDE's/Git clients in a year, but for some people it's a legitimate hurdle to cross.

When I was in high school working on the weekends, that would have been two weeks wages, which I had other stuff to spend on. And that's from a privileged background, I know plenty of folks who's weekend/summer jobs paid towards rent/bills for their families.

That said, Apple probably doesn't care about the teenagers or indie devs out there who want to make a little game for their platform. However I'd also say to those folks - if you're strapped for money, don't develop for Apple devices. Go make a doohickey on a windows or Linux box.

> devil's advocate: $100 is a lot of money to spend on a hobby/side gig for a lot of people.

Agree. But this isn't some lost nobody. This person has a Wikipedia Page [https://en.wikipedia.org/wiki/Nathalie_Lawhead], is an established game developer and artist, and lives in California. She's won multiple awards and she owns at least one Mac.

Like come on. The refusal to drop a hundred bucks on something that is apparently so important to her reeks of good old fashioned stubbornness, or at worst, entitlement, but even then, she has a significant audience. Crowdfund it, cough up and stop whining.

Like I don't entirely agree with the $100/year model being the only option from Apple, but we're all paying that particular piper. Why is she so special that hers shouldn't be subject to the same?

I'm very curious why you're getting downvoted by a large enough number of people to be de-emphasized but no one has responded to you.

If it's always OK to pay an extra $100/yr on top of all the other Apple purchases, then the market price is actually $infinity.

Also, some people may look up to Lawhead as a role model as a programmer/artist but not have awards and lots of $.

> If it's always OK to pay an extra $100/yr on top of all the other Apple purchases, then the market price is actually $infinity.

By this logic the cost of anything that you can't own and use ad-infinitum is $infinity.

> Also, some people may look up to Lawhead as a role model as a programmer/artist but not have awards and lots of $.

What does that have to do with her ability or willingness to pay?

The problem is that the best indie games communities in my experience were those that revolved around free games. Newgrounds, wc3/sc custom maps, etc. Every now and then someone would run off and get a job based on their games, or turn a decent profit from adverts or selling the game, but it was largely a non-monetary enterprise. The monetary incentive was mostly along the line of a vague hope of working at a AAA shop down the line.

And those communities succeeded, and produce interesting games/genres, primarily due to the lack of barrier to entry (in the sense that you eg bought doom & sc for the game, and then realized there was an editor attached that came free)

Annoyingly, they never learned to share their source code and assets, but otherwise.

Today indie gamedev has become more and more a minaturized version of the AAA industry, and that's a terrible shame.

> The problem is that the best indie games communities in my experience were those that revolved around free games.

Apple is not opposed to free games.

> Today indie gamedev has become more and more a minaturized version of the AAA industry, and that's a terrible shame.

I'm sorry but this comparison is ludicrously hyperbolic. Firstly because the Mac is hardly the platform for free and open gaming, relative to the topic at hand because the Mac itself has a high barrier to entry, being so damn expensive just for the hardware, and secondly because the total expenditure, if you wanted to publish, not develop because ANYONE can develop on a Mac for precisely no money, to publish a game for free is $100 for the dev license.

And, additionally, I see no reason the games couldn't be distributed as source code for free for people to build and run themselves. Is it as elegant as App Store? No, obviously, but that's what the $100 is paying for.

I'm sorry I just don't see why this is a problem. Mac has always been a bit of an exclusive platform, which makes it both of higher quality, but also does indeed introduce barriers to entry. If those barriers are too much for you, then don't do it, you're still spoiled for choice for distribution channels that aren't the Mac App Store.

Reply on news.ycombinator.com