Hacker News Reader

Comment by hardlianotion | Hacker News Reader

>If you want to develop on Mac, you have to use Xcode, you cant use any other tools. So Apple is at a disadvantage.

I don't think that's true even if you consider IDEs that target the OS X frameworks only. Intellij has a product, Flutter targets iOS, I am not an OS X developer but those two jump out straight away.

As for developing on Mac - it's a Unix & so a very capable development tool to target a range of platforms.

View on HN

Even though you can develop in Flutter, you still need xcode tools to build the apps, even if you can mostly skip the IDE.

We should differentiate between Xcode the ide and Xcode tools, which are just git, clang, etc. The tools aren’t apple’s product.

In Linux they would have been separate packages, but I don’t think the App Store has dependencies so how else are they going to get the required packages installed for their ide.

In this case the argument is focused on Apple forcing you into their ecosystem. Even though some packages might be generic, Xcode tools & codesign wont run and build on another OS then MacOS.

This is just like saying clang compiled for Linux won’t run on Windows [1].

[1]: Yes, I know about WSL. No, that doesn’t count.

It's not: for any other OS, you can develop and compile on whichever other OS you want. Sure, MSVC won't run on Linux, but you can just compile it with clang or GCC on Linux and target Windows. There is no way to do that for iOS.

And this is not because no one wants to write a backend to target iOS, it's because Apple won't allow it. If you want to run native code on iOS, it must be built and signed with XCode on a Mac.

Try to create a UWP application or Windows service, or do any kind of debugging or ETW monitoring, like that.

Fair enough with UWP. Might be one of the many reasons no one uses it...

I will still note that debugging and monitoring are usually not going to work cross-platform - try to log to journalfs from a Windows system (wihtout using MinGW or similar).

Plenty of people use it, they don't need help from Linux devs trying to cross compile applications without any tooling for UI/UX.

You only need clang and codesign to build an app.

If it were actually this simple in practice I wouldn't be jumping between AppCode and Xcode all the time

Could you provide a few examples from your workflow that requires you to open Xcode?

If you want to do real-world things, like change your project settings across different compilation targets (AppCode has a buggy/incomplete settings interface that can't be trusted), use the interface builder (inc. previewing your UI, inc. creating/editing the UI if you're not using SwiftUI), debugging the UI hierarchy, performance profiling, etc., you'll be switching over to Xcode. Once again, in theory you could just have everything running off whatever `make` toolchain you prefer, but if you're making apps for a company, and sharing code with other team members, chances are your exotic setup isn't going to cut it.

i think people might be conflating needing to install xcode vs launching xcode

if you want to build ios apps installing xcode is a requirement (to get the proprietary cli tools) but launching xcode is not required

to build native mac apps, neither installing nor running xcode is necessary, as you can build with the smaller cli-only tools which include only mac os headers/libs

As was mentioned here, xcode is not a requirement. I manage my development tools on Big Sur with NetBSD's pkgsrc via pkgin.

Not strictly required, but practically implied.

Developing good software for Apple's platforms without Xcode remains an unsolved problem.

Anyone that has written portable UNIX software knows why stuff like autoconf even exists, targeting POSIX is just like trying to make HTML/CSS/JS, it works as long as everyone uses Chrome, sorry GNU/Linux.

As for those IDEs, they are a subpar experience of what the whole AppFrameworks are capable of, just like Borland of yore always playing catch up with Windows SDKs.

> Targeting POSIX is just like trying to make HTML/CSS/JS, it works as long as everyone uses Chrome, sorry GNU/Linux.

That's a bad analogy IMO. GNU/Linux is mostly POSIX compliant. There are some edge cases one runs into with C programming, but if talking about shell scripting, sticking to POSIX is definitely more portable. Bash would be a chrome equivalent, otherwise it's like targeting a subset of what every browser can do. Testing against Busybox/musl (Alpine) is a good way to assess portability.

As a FreeBSD user, I don't think I ever had a C program that didn't advertise being tested on FreeBSD work first time. There's no test suite to verify that you've used only the POSIX subset of what Linux provides, and it's not something you're going to get right solely by trying, no matter how careful a programmer you are.

Try to fork in a POSIX compliant way an application using signals and threads, across several UNIX implementations.

Or asynchronous network programming with certificates, while using only POSIX APIs.

Dealing with filesystem capabilities, file locations, daemon configurations, port management utilities,...

Ah, and anything GUI related is not even part of POSIX.

Reply on news.ycombinator.com