Live data from Hacker News

Building and shipping Mac and iOS apps without opening Xcode

scottwillsey.com

201–210 of 248 posts

Re: Building and shipping Mac and iOS apps without opening Xcode

#201

Earlier quoted context omitted.

Why should you need a Mac to build for iOS at all? What makes Apple so special here? Cross-compilation toolchains aren't forbidden alien technology. Forcing people onto Macs is such a pathetic way of extracting rent from developers and makes workflows worse. No you can't just build and debug your app from your Windows or Linux workstation because we want you to buy hardware you don't need. Sorry we only support Xcode…

I don't disagree with you, but we're talking about affordability which is a different topic. > It's especially nice when you work on projects that aren't iOS/Apple native and you don't get Mac workstations. If you develop natively for macOS, then you probably need the OS for it. It's the same for Linux and Windows. But building is not the biggest hurdle because you can build in your usage-based-billed/free CI as well…

I'm not really sure how any machine is more affordable than the $0 it should cost because you shouldn't need a Mac. It's absolutely true that you can get by with a base spec Mac Mini, but often you can't with bigger projects and the cost skyrockets because Apple prices memory like kidneys (current market conditions aside, they've always done it).

I have nothing against the hardware. I despise how artificial the problem is. It's not even like Apple just refuse to provide tools and leave it up to the community. They force you to use a Mac in the terms of service.

For context I work on the mobile team for a large AAA game engine. This is going to colour my opinion because we're very Windows centric, but my experience wouldn't exist if it weren't for Apple. I need to sync code on two different machines and build half the project on Windows and the other half on the Mac. If we could just build and debug the iPhone on Windows none of this mess would be needed.

We don't develop for MacOS, we develop for iOS. Just debugging the app requires several hoops across multiple machines because of Apple's policy here. Just because a base spec Mac Mini is cheap doesn't make this whole problem any less stupid. I don't need a vendor's special-sauce computer to build for consoles. Cross compilation and remote debugging has existed for decades, this problem should not exist.

Calling it more affordable because Mac Minis aren't junk anymore is really just accepting Apple's ridiculous requirement because "I guess it could be worse right?".

Re: Building and shipping Mac and iOS apps without opening Xcode

#203

Earlier quoted context omitted.

Why should you need a Mac to build for iOS at all? What makes Apple so special here? Cross-compilation toolchains aren't forbidden alien technology. Forcing people onto Macs is such a pathetic way of extracting rent from developers and makes workflows worse. No you can't just build and debug your app from your Windows or Linux workstation because we want you to buy hardware you don't need. Sorry we only support Xcode…

Because it would cost Apple a substantial amount of money to make it possible to build your code for iOS on other platforms in any sort of supported fashion. So all the stuff they invest very substantial amounts of money into creating and maintaining are only going to be licensed for use on the hardware they sell under the latest operating system it runs. Asking for more is asking them to spend more money without any…

The Apple developer terms of service require all app submissions to come from a Mac.

Apple could've chosen to offer no tools and leave it to the community to build their own. I think that's reasonable. I don't expect Microsoft to bring MSVC to Linux.

But Apple take the explicit position that you must purchase a Mac in order to ship apps for iOS.

Re: Building and shipping Mac and iOS apps without opening Xcode

#204

Earlier quoted context omitted.

Because it would cost Apple a substantial amount of money to make it possible to build your code for iOS on other platforms in any sort of supported fashion. So all the stuff they invest very substantial amounts of money into creating and maintaining are only going to be licensed for use on the hardware they sell under the latest operating system it runs. Asking for more is asking them to spend more money without any…

The Apple developer terms of service require all app submissions to come from a Mac. Apple could've chosen to offer no tools and leave it to the community to build their own. I think that's reasonable. I don't expect Microsoft to bring MSVC to Linux. But Apple take the explicit position that you must purchase a Mac in order to ship apps for iOS.

Oh no. The horror. How terrible.

Re: Building and shipping Mac and iOS apps without opening Xcode

#207
I have a nice setup on my Linux for iOS apps. I compiled the OSXCross toolchain, and also copied iPhoneOS.sdk and iPhoneSimulator.sdk from the macOS VM. With some wrappers, I can compile iOS apps (Obj-C) on my Linux machine, sign them with zsign, and use go-ios to install them on the device.

At first, I just used simulator builds to test (and debug) on the macOS VM, in the simulator, but that was slow and painful. Finally, I bought a used iPhone, all bruised, just so I could test it on a real device. The main issue for me was signing, one cannot register a macOS VM (maybe with some kext hacks?), I managed to enable developer mode on the phone (crazy process, but it worked with Xcode in a VM), I registered the phone on the website, and paid those damn 99$.

I used that for my cross-platform UI library with native controls, based on IUP. Now, future users of the UI toolkit do not need to care about Mac, iOS, or tooling; it just works. You can check the toolkit (WIP) here https://github.com/gen2brain/iup-go .

Re: Building and shipping Mac and iOS apps without opening Xcode

#208

Earlier quoted context omitted.

There’s Xcode-mcp-proxy that proxies Xcode’s mcp and adds clicking dialog and reconnects. How do you deal with macOS app testing? Do you use Peekaboo or plain screenshotting automation?

Can you link it? Quick google search didn’t reveal it

Gave the wrong name, this is it- https://github.com/lynnswap/XcodeMCPKit

Re: Building and shipping Mac and iOS apps without opening Xcode

#209

Everyone will still need to use Xcode for at least some debugging, no way around that. As for the builds, your agent probably already knows how to do a lot of this from the command line, although explicit suggestions can help it build faster for different situations. As for XcodeGen, you may find it unnecessary overhead if you're already using Xcode file system synced groups. For iOS my biggest suggestion would be to…

There’s complete lldb debugging for Swift as plugin for VSCode.

Re: Building and shipping Mac and iOS apps without opening Xcode

#210

Technically, you are using Xcode. Xcode is a [buggy as hell] GUI wrapper for a lot of system-level UNIX utilities and apps [which are generally, not so buggy]. Using CLI to release apps is a pretty old practice; at least as long as I've been doing it (I released my first Xcode app in 2012).

Xcode’s a lot more than a wrapper for UNIX utilities. For example, it has an entire build system. It doesn’t just invoke xcodebuild under the hood—and even if it did, xcodebuild uses the exact same code to build your projects as the IDE. Most of the problems that I saw people have with Xcode over the two decades that I worked on it were the result of one fundamental problem: They wanted to work a different way than X…

Thanks for your service on Xcode.

In my experience, it’s quite “crashy.” It often locks up so bad, that I need to force-quit (or force-restart the Mac). I end up doing that once a day, or so. I suspect that many of the performance and stability issues, have to do with resource usage. It’s a damn big app.

It can also end up in strange states, where portions of the UI fall “out of sync,” and the app needs to be restarted. Some operations (like opening a storyboard, or stopping at a breakpoint) introduce massive delays.

It’s not a denigration, calling something a UI shell. I’m working on one, right now. The engine and backend were done in April (started in February), and all the work since, was on the UI shell. I probably could have shipped something that “ticked all the boxes,” in May. It’s almost done, but there’s still a couple of months of testing, ahead.

Post reply on HN