[okamiueru]

What I want to do is not have to have a unified build system for multiple platforms and ABIs without any problem, but for some reason, to target anything apple, I have to use a physical apple machine.

It's absolutely abusing market position, because it ends up being that in my profession, you end up purchasing mac computers for the whole office, because then you can target all platforms without any fuss. Not because the hardware or software has any merits, but because they artificially restrict these use cases so that's the only option to target a significant market.

[amelius]

Yes, and I wonder why do we have Wine to run Windows stuff on Linux, but we have no equivalent to run OSX programs on Linux ...

Is nobody interested in implementing the OSX APIs on Linux?

[diffeomorphism]

> but we have no equivalent to run OSX programs on Linux ...

It is called darling: https://www.darlinghq.org/

> Is nobody interested in implementing the OSX APIs on Linux?

The reason for wine is that windows has a dominating market position and hence you often have to use some software that is windows-only. For OSX you might want to, but there is no such dire need.

[rollcat]

It's a very fast moving target. Apple keeps rewriting and deprecating stuff faster than they can write the documentation. As a newcomer to native macOS development, I'm sometimes struggling to even find working examples.

[Gareth321]

I am convinced this is by design. Apple has leaned heavily into service based revenue. This means recurring revenue. So in their App Store, they heavily incentivise subscriptions over one-time purchases. One of their tools is frequent and rapid API deprecation. This breaks older apps which aren't maintained. Developers must therefore spend much more effort on maintaining software on iOS and macOS (I can still run software on Windows from 20 years ago). This makes the value proposition of selling one-time purchase software poorer. It also means that older software has a much shorter lifespan, so users are forced to purchase software more frequently. I think this is one of the reasons revenue on iOS is so much higher than Android.

[jonplackett]

Which IMHO has made the AppStore a cesspool of awfulness.

Buying a one time app for a few quid used to be a normal and a good deal all round (I say this as a customer and iOS developer)

But now EVERYTHING is a monthly subscription. Even for apps that really shouldn’t need any updates - but like you say, they do need constant updates just to remain functions.

It’s created a broken AppStore and I just never pay for anything anymore.

[amelius]

Ripe for disruption ...

[jonplackett]

I’m in the UK and it’s looking from the rumours 3rd part AppStore’s are gonna be EU only so we’ll be missing out.

Another fabulous consequence of brexit.

[jstarfish]

> This breaks older apps which aren't maintained.

This does suck when you find an "old" app that works well, but there is an upside-- the 99% of other garbage apps from 15+ years ago don't pollute ongoing search results forever. Eventually, old apps that aren't maintained get popped from the stack.

The other upside is that new developers don't have to compete with ghost apps from the past continuing to leech new interest because they're ranked higher due to cumulative downloads over time. Nobody can compete with Time.

As an example of an app store that doesn't do this-- I don't know if ticalc.org is still around or still works this way, but their catalog grew endlessly with every generation of bored students uploading new redundant renditions of Drugwars (et al.). If you want to play Drugwars, which of the 500 versions of it are the best? Maybe the 1998 version is the best, or maybe the 2020 version is-- who can tell?

It made it very difficult to figure out what to bother with unless you were using a brand new TI-83+++ Extended APU Platinum Edition with bespoke hardware specs that forced a new backwards-incompatible platform category that instantly excluded all the old cruft.

[andromeduck]

Isn't that what metrics like DAU is meant to capture?

Making DAU & avg active time per day in addition to user reviews/ratings would be a pretty strong signal.

[hamilyon2]

I really like how impartial and matter-of-factly your comment is in contrast with dystopian picture it paints. Or maybe there are positive aspects of this process that I don't see?

[evdevreed]

Not that it's any relief, but this is also the case with Windows too. MS often introduces breaking changes in the Windows API and rarely adds/updates examples.

Unfortunately, it's the norm in most massive closed source ecosystems like these.

On the one hand, it makes being a developer on these platforms pretty painful at times, and on the other hand, it also increases the value in having expertise with them.

[vardump]

"MS often introduces breaking changes in the Windows API"

Can you give an example? I have also plenty of Windows development experience, but can't think of anything. More like, Microsoft seems to be pretty careful making sure APIs don't break.

NTAPI doesn't count, because it's undocumented in the first place and you're not supposed to use it in the userland at all. Yeah, we all do, but...

(Many APIs are pretty bad in the first place, but that's another matter.)

[account42]

> NTAPI doesn't count, because it's undocumented in the first place and you're not supposed to use it in the userland at all. Yeah, we all do, but...

In the context of developing something like Wine that is irrelevant - you need to deal with what people use.

[Tagbert]

That may be true in Swift, which is a relatively new language that was evolving rapidly in the early years. For objective-C the rate of change has been much slower.

[ayewo]

Agree. This is why WWDC videos can be immensely useful to get inside information about how things actually work and the shape of things to come.

[okamiueru]

I cannot express how frustrating and unprofessional Apple comes across, that you have to sit and watch YouTube videos, to try and find some documentation for iOS development.

> WWDC videos can be immensely useful to get inside information about how things actually work

Imagine if we could have proper text based documentation on how things actually work? I don't know why this isn't the case. I'm sure they can afford it. Maybe it's just lack of respect for developers? "They seem to figure it out anyways"?

[ChuckNorris89]

Jobs made it clear in the 1997 WWDC speech[1] that Apple's priority is never the developers, but solely the customer experience and the final product, and if programing languages, frameworks or developers will be casualties along the way, then so be it. His words, not mine.

[1] https://www.youtube.com/watch?v=oeqPrUmVz-o

[amelius]

Without developers there would be no customer experience. But developers keep prostituting themselves and become the victims that you mention.

[okamiueru]

I'm not sure those two are incongruent. Surely, the customer experience and final product includes software written for the platform? And, if developers make apple development an afterthought, or more poorly tested because CI/CD is tedious and cumbersome... how does Apple benefit? Of course, this is a comment on the what seems to be lack of insight on the comment made by Jobs, and not your comment. Thanks for sharing that. It does give some insight into the state where developers seem to be treated as second class citizens, even though they rely on their work.

In any case, Apple sure has convinced the masses, and can rarely do no wrong. So, I suppose I'll just keep yelling at the clouds.

[yreg]

Yes, but it's unclear how having a proper documentation detracts from customer experience or the final product.

[mort96]

Is there really that much software out there which runs on macOS but neither Windows nor Linux and has no good alternatives for either Windows or Linux?

There's a truly absurd amount of software out there which runs on Windows but not Linux, it doesn't surprise me in the slightest that way more effort is invested into running Windows software than running macOS software.

[andromeduck]

Iterm2 and Karabiner Elements don't have comparable equivalents.

[fuu_dev]

There is a project like this: https://github.com/darlinghq/darling

[wappieslurkz]

OS X is not developed anymore for a while now. I assume you mean MacOS.

[planede]

Technically it's possible, but possibly not legal:

https://github.com/tpoechtrager/osxcross

> Please ensure you have read and understood the Xcode license terms before continuing.

According to the EULA you may only use the SDK on Apple-branded computers. But you can use Linux to cross compile to Apple.

Do the Visual Studio build tools have more permissive license terms? AFAIK you can have clang-cl on Linux, but you do need a lot of the SDK for it to be useful. No experience there.

[malermeister]

At least in the EU, there's precedent for click-through EULAs like the XCode one being unenforcable.

[account42]

For Windows, MinGW has an independent implementation of the complete build environment so you don't need any VS tools, import libraries or headers. For macOS there is no such complete build root but the actual tools are available - e.g. clang is always a cross-compiler able of targetting all supported architectures and for the linker Apple's own ld64 is open source and we also have lld now although I am not certain the macOS target status.

> AFAIK you can have clang-cl on Linux

clang-cl is a frontent for MSVC command-line compatibility - you don't even need that for cross-compiling, just -target and then whatever -fms-* extensions you need for your non-portable code. But yes, Clang doesn't come with its own SDK so you will need headers and import libraries and possibly other tooling (although the LLVM procect covers a lot).

[okamiueru]

It's unfortunately not legal. Makes it also not commercially viable. Cross-compiling is nice, but if the build toolchain requires xcode, then it doesn't help all that much, since the last and most important step has to be done on apple hardware.

[planede]

At least you can build on docker runners instead of fragile shell runners on MacOS. But any benefits are probably not worth the cost of complexity of cross compilation.

[bryanrasmussen]

I think when they started this requirement they were not in the market leader position, so it seemed less abusive to people at the time.

[matthew-wegner]

You can run unmodified macOS underneath VMWare hosts. Apple even ships a VMXNET3 driver on every Mac (since they don't really have an external driver paradigm).

If you're reading this on macOS, have a look:

  /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleVmxnet3Ethernet.kext

[grishka]

What's wrong with running hackintosh in a VM if you really want to build for Apple platforms without buying a Mac? Sure the days of hackintosh are numbered because of the ARM transition, but this would work for as long as macOS runs on x86.

[heavyset_go]

It would open your or your employer's business to liability.

[fredgrott]

In my case with Flutter framework, I buy cheap MS Windows or Linux box and the build children are Minis even an Apple mini. I have not priced it out yet, but I expect it to be cheaper in the long-run than buying time on cloud testing lab set ups.

[okamiueru]

We also use flutter, and have extensive native code that needs to be compiled for each platform/abi. What you describe is similar to the setup we used. However, more and more developers have opted to get a MacBook in order to avoid the hassle. It might make sense to just have a dedicated mac computer running a gitlab worker that builds the iOS stuff for us.

[fubbernuckin]

I wish all developers could just up and agree not to bother with the headache and leave Apple and its walled garden to rot. Too bad we don't answer to ourselves.

[borispavlovic]

It's on the expensive side, I know, but have you considered using bitrise.io?

[okamiueru]

Thanks for the tip. We have considered it. Its likely the place to go once we iron out development/product. Its just unfortunate that the basics of such a CI setup is trivial to set up "in-house", for everything except software targeting apple hardware.

[amelius]

Not an option for many from a privacy/security standpoint.

[LegNeato]

Facebook has this for builds as well for runtime (osmeta).

[batty_alex]

> It's absolutely abusing market position,

It’s definitely a “dick move” but, I’d have trouble calling it abusive. Having to buy expensive development kits is common in our industry

[okamiueru]

They only way to reach a significant market share is to put up with it, wouldn't that count as abusing their position? They don't have to care, because they know that developers have no choice, and in the process they increase their hardware sales? Imagine if google wanted to produce end-user hardware. Then they limit their SDK/NDK to only work on that new hardware. And, this isn't any magic or special hardware. Just an added EULA that restricts legal use, and lack of developer support. This is pretty much apple has done. Of course, doing something like that on an already established market would be suicide. But, developers would have also to a much larger extent chosen not to target Apple hardware, if it wasn't for the market share. That's why it is abusive and a case of anti-trust. They get away with it because of their market share.

[npteljes]

The fact that the practice is widespread doesn't mean that it's not abusive. It just means that most players are also abusive.