Live data from Hacker News

Building and shipping Mac and iOS apps without opening Xcode

scottwillsey.com

221–230 of 248 posts

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

#224
post #41

I've been building and testing my iOS app just for fun via Linux only. Surprisingly, it's very easy. This works like a charm: https://github.com/xtool-org/xtool You do not need to upload to TestFlight or the App Store; you can just install the app locally to your iPhone via usb -- even from Linux! When in doubt, just ask your coding agent of choice to help you create and upload a Hello World iOS app. It's really easy…

I'm not an ios developer so forgive me... So you can develop ios apps, run it on a real iphone that is activated without going through app store as a native app? But, you have to reinstall it every week?

Yes, but you have to reinstall every week unless you have a paid developer account.

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

#225

I spent seven years as a dev on the Xcode team and this is pretty much my exact workflow these days.

Thank you for your service. Xcode gets a bad rap from developers but for beginners, it doesn’t overwhelm them, giving them a great entry experience into app development.

Thank you for your comment. Prior to Apple, I worked on the Visual Studio team for 10 years. Now that is a complex app now matter how experienced you are. ;-)

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

#227
post #34
post #16

By using "Claude Code"* * and giving Anthropic all your secrets, env vars, certificates and your source code to them.

What bad things to you anticipate Anthropic doing with your secrets, env vars, and certificates?

Is this a joke?

Anthropic isn't great at keeping stuff private as we saw with the Claude Code leak. The more information they get access to the bigger the risk.

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

#228
post #27

This is cool but also makes me worried about the tendency with llms for all of us to make bespoke solutions rather than building a better community tool or extending an existing tool to solve the problem. fastlane exists to solve exactly this problem in the mobile space.

Bespoke solutions are better in many cases. They do exact things required for the project without taking extra dependency. Reducing dependencies is beneficial, because dependencies require management. So with llms economy of taking dependency shifted.

everything has tradeoffs, on the one hand you are right you have one less dependency, on the other hand the maintenance of said dependency is now on you. many times app store connect has changed some api and fixing our release process was a matter of updating fastlane because the community had already dealt with it, that's on you if you have a bespoke delivery solution.
Post reply on HN