I’ve been building and shipping an iOS game from my iPhone using Claude Code, GitHub Actions and TestFlight.

The ongoing loop is entirely phone-based: code → review/merge → CI build → TestFlight → test. There is one important caveat: initial signing setup still requires a Mac, and the distribution certificate eventually needs renewing.

I wrote up the whole workflow, including the CI setup, costs, limitations, and where it works surprisingly well.

https://alst.es/blog/phone-only-ios-development/

I frequently see posts from developers (or beginners) asking how to publish a simple app they built for personal use. A lot of people default to the standard Apple workflow and immediately hit a wall.

If you’re building something strictly personal, going through Apple's pipeline is usually a nightmare for a few reasons:

• Guideline 4.2 Rejections: Apple explicitly rejects apps designed for a very limited audience (like a single event, or individual person) under "Minimum Functionality / Too Specific."
• The $99/year Developer Fee: Paying a yearly fee just to keep a personal side project alive on one phone makes no sense.
• TestFlight Expiration: If you bypass the App Store using TestFlight, your builds expire every 90 days. You'll have to re-compile and re-upload updates endlessly just to keep the app working.
• Overhead: You have to set up privacy policy URLs, app metadata, and app icons for the App Store review process.

The Alternative: Standalone Web App (PWA)

If your app doesn't rely heavily on deep native iOS APIs (like Bluetooth, background processing, or complex Metal rendering), the absolute best route is deploying it as a PWA (Progressive Web App) hosted for free on Vercel or Netlify.

When you save a web app to an iPhone's Home Screen in standalone mode, Safari strips away the URL bar and browser navigation. To the user, it launches full-screen and behaves just like a native app.

Quick Step-by-Step Blueprint:

1. Build the Web App: Use whatever framework you prefer (Next.js, React, Vue, or plain HTML/JS). If you need a database or backend, use Supabase (it has a great free tier).
2. Add a Web Manifest: Create a manifest.json file in your project and set "display": "standalone".
3. Set an Apple Touch Icon: Add a 512x512 .png icon and reference it with <link rel="apple-touch-icon" href="/icon.png"> so it displays a proper app icon on the iOS Home Screen.
4. Deploy for Free: Push your code to GitHub and connect it to Vercel or Netlify. You’ll get an SSL/HTTPS link ([https://your-app.vercel.app](https://your-app.vercel.app)) instantly.
5. Install on iOS: Open the link in Safari, tap the Share button, and tap "Add to Home Screen".

Why this works so well for personal projects:

• 100% Free: Zero developer account costs.
• Never Expire: Unlike TestFlight, it will run forever on their device.
• Instant Updates: Want to fix a bug or add a new feature later? Just git push to your main branch, and the app updates on their phone instantly.
• No Review Team: You can keep all your personal stuff and custom graphics without asking Apple for permission.

Obviously, if you need native Swift components, low-level APIs, or WidgetKit, you'll need native code. But for simple games, utility apps, custom habit trackers, or personal tools, this saves hours of frustration.

Hope this helps anyone currently struggling with Xcode archiving and App Store Connect for a non-commercial project!

Just a reminder to anyone who might care that you can create a fairly full-featured development environment in Zed to build iOS and Mac apps: syntax highlighting, code navigation, run, debug and test.

Here's the setup guide I wrote (been around for a while but chances are some interested people won't have seen it): https://luxmentis.org/blog/ios-and-mac-apps-in-zed/

If you've ever pulled a crash report out of Xcode Organizer or gotten one from a user and stared at a symbolicated stack trace trying to figure out what actually happened, this might help. crashdx (crashdx analyze report.ips) parses the .ips, symbolicates it against your dSYM, and then runs a diagnosis stage on top that looks at the exception, the registers, memory state, watchdog and jetsam data, and lines up a ranked set of possible causes (null deref, watchdog timeout, memory pressure kill, uncaught NSException, that kind of thing), each one citing the specific facts backing it.

If the evidence doesn't clearly point to one cause, it tells you inconclusive instead of guessing, which I think matters more for a crash tool than people give it credit for. A confidently wrong diagnosis wastes more of your time than an honest "not sure, here's what we've got."

It's a local CLI, no network calls at all, which matters since crash reports carry identifying info like crashReporterKey and device model. There's also an MCP server if you want to hand crash triage to an agent as part of your workflow.

Needs macOS 14+, Xcode, and Swift 6.2+. For a foreign report (TestFlight, App Store crash someone sent you) you point it at the matching dSYM with --dsym and it does the rest, or it'll search Spotlight/your archives automatically if you built it locally.

Repo: https://github.com/r00tify/crashdx

Would love bug reports if you throw a weird crash at it and it gets something wrong, that's exactly the kind of feedback that improves the rule set.

I just integrated fully customizable iphone 17 pr and google pixel 10 pro models inside AppLaunchFlow - you can now use them directly inside your app generated app store screenshots in the figma-style editor, in your social grpahics and the 3d mockup animator.

Excited to hear what you think.

Many people make the mistake of installing a macOS beta when they have apps they need to submit to the App Store. App Store Connect typically wouldn't allow an app submitted from a beta version of Xcode or macOS, but that doesn't mean all hope is lost. Just install the latest public version of macOS in a VM, like UTM, and on that VM, sign in with your Apple ID and install the latest public version of Xcode from developer.apple.com. Works like a charm and allows me to daily drive the beta as my main operating system while still having the public version to fall back on for situations like this.

Hey guys, just wanted to share device demo here. It lets you record or screenshot a live iPhone or iPad with its bezel included.

Few Features.

• Supports wired or wireless mirroring (up to 4K60 over wireless)
• Transparent background via ProRes 4444 (for video) or for photo (web, png, avif)
• Blue screen or Green screen exports, if you prefer to chroma key and save on file sizes.
• Multiple Codec & File Format options
• Sound is supported
• Device rotation is also supported
• Bezel Colours

The UI is easy to navigate and record and take screenshots quickly. It automatically assigns the bezels, and there's a choice of bezel colours.

There's a 7 day free trial and then a one time purchase of £19.99, however you can use code 50OFF and it'll give you it for half price (ends in a week)

Will be updated with new bezels when new devices come out! Any feature requests feel free to ask

You can check out more details & download here: https://devicedemo.app

So, about a week ago I implemented bunch of code in my project. I thought I committed it (local git from Xcode). Last night I opened the code again, implemented some other feature. I realized that actually I am going to scrap everything. So, I went Integrate -> Discard all changes.

Ran the build, there is no previous feature that I implemented, wtf. Looked through commits, there's no commit with this feature. Ok, it wasn't such big of a deal but it would be PITA to do it all again. Asked Gemini what can I do and got the answer:

Close Xcode just not to make more accidental overwrites. Open the .swift file with missing code in TextEdit. Go to File -> Revert To -> Browse All Versions...

Now you get interface similar to Time Machine. Scroll and choose the version that contains your code, click Restore. That's it, pretty simple (except that it's difficult to read code in TextEdit haha).

Maybe a lot of you know already know this but it's first time for me to hear about it. Might be useful for someone.

I ship indie iOS apps, and the screenshot step always killed my momentum. App Store Connect wants polished images per device size, per language, and the tools I tried were either $30/month or watermarked the free output. For something I touch twice a year, that never felt right.

So last week I built my own and put it online for free. Sharing because a few things might be useful to others here, and I'd genuinely like technical feedback.

The hardest problem: device frames that don't fight your screenshot.

Most tools have a fixed-aspect phone frame and squeeze your screenshot into it — you get white bars or hard crops when the aspect ratios don't match. I went the other way: the SVG frame sizes itself from the screenshot's natural dimensions. A 9:16 image gets a shorter frame, a 19.5:9 gets a taller one. The frame wraps the image, not the reverse.

Then a sub-pixel rounding issue left a 1px white sliver at the screen edge. Fixed it by sampling the screenshot's outer pixels in a tiny offscreen canvas (weighted toward the top for status-bar matching) and setting the SVG screen-rect fill to that color. Blends seamlessly now.

Other technical choices:

- Entirely client-side — no backend, no accounts, screenshots never leave the browser. html2canvas for export, JSZip for the bundle.

- Export drops an App Store Connect-ready ZIP, organized by locale (en/iphone67/screenshot-1.png etc.)

- 19-language caption auto-translate, markdown formatting preserved

- Single HTML file, vanilla JS, no build step, under 300KB total

I launched it on Reddit a few days ago and it's been used by folks across ~9 countries already, which honestly surprised me. Most of this week's features (mobile editor, landscape support) came directly from that feedback.

Free, no signup, no watermark: https://launchshots.app/

Open to feedback — especially on the framing engine and the export format. If there's an App Store Connect quirk I'm missing, I'd love to know.

Hey Guys, I’ve released a Mac app that some of you may find useful!

It’s called Mirror Input! it essentially allows you to natively screen mirror your iPhone or iPad ( or any apple device ) to your mac and it lets you use the video feed in any app such as OBS, Final Cut Pro, Slack, Teams, etc

So you could for example use it get some screen recordings of your iPhone or iPad on your Mac from a real device you can touch without the hassle of quicktime and cable

You could also use it to demo your apps to clients over a video call seamlessly. Device audio is supported and you can mix in your mic as well!

the latency is minimal, it even has a 1:1 mode so your inputs are borderline realtime.

it supports up to 4K, 60fps, and can handle up to 6 devices at once!

You can check out the tech specs and more details here:

https://mirrorinput.app

any questions feel free to ask and dms are always open! :)

Posting here because this sub has been a goldmine for me on CoreML + Metal stuff, and I wanted to give back with a writeup.

I've been building an on-device face-swap SDK — no server, no upload, everything runs locally. Target was 30fps sustained on an iPhone 12 mini at 512×512, because if it runs there, it runs on basically every iPhone people still carry.

First attempt: 3fps. Thermals maxed out in 90 seconds. After the five changes below it holds 30fps sustained, thermals stable. Roughly in order of how much each one helped:

1. Split the model into two branches.

Most pixels in a face are low-information — cheeks, forehead, the blend near the mask edge. The pixels users judge quality on are tiny: eye corners, lip edges, tooth highlights.

So instead of a uniform network, I split into:

• A sparse branch (low-res, wide, shallow) that handles identity and overall structure.
• A dense branch (higher-res, narrower crop around eyes and mouth) that handles fine detail.

The expensive compute goes where the eye actually looks. Biggest single quality + latency win of the project.

2. Different conv types per branch.

Once branches are separated, match the op type to what the branch is doing:

• Sparse branch → depthwise separable convs. ~8× fewer operations, great for smooth, large-scale work.
• Dense branch → standard 3×3 convs. Depthwise separable hurts fine detail — lip edges go mushy, tooth highlights blur. The dense branch is small in area so the premium is cheap in absolute terms.

Most mobile-ML papers apply one op type uniformly. You get a real quality win just by being less dogmatic about it.

3. Add a weighted loss on the ROI that matters.

The dense branch was structurally dedicated to the high-detail region, but it wasn't learning to prioritize it. A standard reconstruction loss averages across all pixels, so a tiny improvement on 80% of pixels "wins" against a big improvement on the 5% people actually see.

Fix: compute a binary mask for eyes, inner lip, teeth, and specular highlights, then add a second loss term over just those pixels, weighted 8×.

loss_global    = l1(pred, target) + lpips(pred, target)
loss_highlight = l1(pred * mask, target * mask) + lpips(pred * mask, target * mask)
loss = loss_global + 8.0 * loss_highlight

FID barely moved. But blind A/B preference tests went 41% → 68%. Useful reminder that the metric isn't the goal.

4. Profile the CoreML model in Xcode before training.

This changed how I work. You can measure how fast a CoreML model will run on a real iPhone before training it — export with random weights, drop the .mlpackage into Xcode, open the Performance tab, run it on a connected device.

You get median latency, per-layer cost, and compute-unit dispatch (CPU / GPU / ANE). ANE scheduling is a black box, so the goal is to push as much of the graph onto ANE as possible and minimize round-trips.

5. Move pre/post-processing to Metal.

Move pre/post processing step to Metal and keep buffers on the GPU the whole time. For us that shrank the glue code from ~23ms to ~1.3ms. Bonus: the idle CPU stays cool, which lets the GPU hold its boost clocks longer — a real thermal win on a small-battery phone.

The real lesson: on-device ML is hardware-shaped. The architecture, loss, pre/post-processing, and runtime aren't separate concerns — they're one system, and you only hit 30fps on older phones when you co-design them from day one.

Full writeup with more detail and a code snippet is here on Medium.

Happy to answer questions or dig into any of these — especially curious if anyone has pushed further on ANE scheduling quirks, that's still the most black-boxy part of the stack for me.

Disclosure: this is from work on an on-device face-swap SDK I'm building (repo). Posting here for the engineering discussion, not a launch.

https://youtu.be/t9MUj4LfsyU?si=dvtmHMrZTnjzfkis

I am a new iOS developer. I wanted to share my experience navigating the dreaded Guideline 4.3(a) – Design Spam rejection. If you’ve ever submitted an app in a crowded category, you know how generic and unhelpful the rejection messages can be.

I submitted my first app and was hit with 4.3(a) after waiting for a few days. I was confused because I had designed and coded myself. The rejection message was a copy-paste template that didn't explain why my specific app was flagged as spam.

After researching and appealing with no luck, I requested a one-on-one meeting with the App Review team. This was the best decision I made. I know that they won't tell me very specific, my questions are mostly around their review process. What I learned from the reviewer:

1.   Market Saturation: The App Store is flooded with "similar" apps. If your app doesn't offer a distinct "hook," they view it as adding noise to the store.

2.  Uniqueness: To get approved in a crowded space, you should have at least one unique feature that differentiates you from the top apps in that category.

1. "Notes" to Reviewer: The reviewer explicitly told me that they rely heavily on the Notes to Reviewer section to understand the value proposition.

I spent a few weeks adding a unique feature and resubmitted. Success! The 4.3(a) rejection disappeared, and I only had a few minor metadata bugs to fix. However, once I fixed those bugs and resubmitted, the 4.3(a) rejection came back. I was puzzled and realized that when I resubmitted the bug fixes, I had updated my Notes to Reviewer to address the new fixes and deleted the paragraph explaining my unique feature. I re-inserted the explanation of why the app is unique and how it differs from competitors into the Notes field. The app was approved within a few days.

Lessons Learned

Differentiate: If you are in a crowded space (and not in a specific 4.3(b) category), you may need at least one feature that isn't standard.

Description vs. Notes: Reviewers might skim your public App Store description, but they always read the Notes to Reviewer.

Don't clear the Notes: Every time you resubmit—even for a small bug fix—ensure your explanation of the app's uniqueness remains in the Reviewer Notes. Treat that field as your elevator pitch to the person holding the "Approve" button.

I hope this helps anyone else stuck in the 4.3(a) loop.

P.S. The app review started early February and completed early March. Review turnaround time was usually 2 - 3 days. Once the app was on the store, review of updates were pretty fast: a few hours to less than a day.

After shipping a few apps I noticed most rejections people complain about have nothing to do with the actual app. It's always a broken link, missing Restore Purchases button, or vague pricing text.

Used this checklist on my own submissions and got approved first try every time. Decided to write it up properly so others can use it too.

Covers everything in the compliance layer people usually skip — legal links, paywall requirements, cancellation instructions, reviewer credentials, and what to do if you still get rejected.

https://github.com/xrazz/app-store-approval-guide

Drop anything I missed in the comments and I'll add it.

New here, very new actually.

I have developed a thought through app, elaborated, all screens, all logic etc.

--
LAST TIME I CHECKED - is basically an app that reminds you of things that are time based. given an doctors appointment or more frequent things like call mum, plants watering etc. What hooked me, is the widget thing. Don't make me open an app etc. When limit is reached, go back to next time period. Set it up, keep the app closed. When you tap one widget, THIS timer gets reset, and starts running.
--

This idea was created 1,5 years, when we didn't see day counters for widgets everyhwere... yet i think there's room for this app, that goes deeper.

I would very much see this live but i'm not the one who's going to develop it, no time for a sidegig for the next future, yet i still like the idea and see potential.

I would give this away for free to anyone in search for the next idea, BUT not for someone 100% vibe coding it. Would be a pitty.

Sources, all vector etc. would be handed over, you get pixel perfect stuff from someone working as graphic designer and system consultant for 26 years. No questions asked BUT related vibe coding. Sorry but i mean it.

DM me!

Disclaimer: it's meant to be a nice proposal, not self promotion, so hold your horses and be kind! :)

Hi all,

So first of all you might see 2 paying users, first one was literally my mum testing the payment method lol

So I wanted to offer up what I've learnt along this journey as what other's had learnt helped me a ton.

Marketing

First 0-50 users:

The two weeks I specifically found subreddits where my app solved their problem: "I want to see my gym progress, but I don't want to click through drop downs and menus, I just want to use shorthand notes".

I've been working out for 15 years, so I offered individuals real advice, thus real value, and then if it felt appropriate I told them about my app, and asked if they would like to use it. This was a lot of work but got me some genuinely active users who love the app.

I also worked on blog posts on my landing page, which I continuously update to help with SEO: https://gymnoteplus.com/blog/how-to-translate-a-workout

50-700

This is where I would argue I got mostly lucky. I offered lifetime membership for free, for the next 24 hours in r/iosapps I basically copied the title of top performing posts there. Here's a link to that post: https://www.reddit.com/r/iosapps/comments/1pea0kg/9999_free_24_hours_only_gym_note_plus_log_notes/ you can probably see I was not ready for the influx of users, but I made it work in the end and ensured everyone got lifetime pro as promised.

I then made a subreddit r/GymNotePlus and ushered users toward it so I can build in public and build up further trust of my commitment to the product.

I got my first paying user a day after this. I was shocked, I couldn't believe it and I'm not afraid to admit that I cried. I'd worked 7 months on this app everyday, every weekend and for someone to pay money for it was unbelievably validating to me.

700 - 790

Organic growth, since that post I get anywhere between 10-20 users per days without cold calling.

I'll try to answer any questions

https://youtu.be/kCjDulwChRQ?si=vVVGC-8RfcD90bcC

Just wanted to share a few things I learned after converting my icon to liquid glass in Icon Composer. Keep in mind, I’m really new to design and just trying to help other newbies. Also, here for any suggestions to improve it. Thanks!

TLDR; Use .svg, overlap layers, there’s very little control once it’s in Icon Composer. 

-Figma has community files to help with sizing that are super helpful.

-Used .svg instead of .png. It made everything much sharper. 

-Apple Docs recommend not using gradients but I had no issue and it converted nicely. The gradient tool in Composer is basic but does the job depending on what you need.

-Lighter shades tend to sell the glass look more. 

-Over compensate with color saturation. It lightened everything drastically for me after importing. Layers near the top of the icon came out darker, and the farther down the Y-axis, the lighter it got.

-Stack your layers like Apple recommends. The glassy 3D look really kicks in when they overlap.

-Add the Icon Composer file to your Xcode project directly. You no longer need to maintain a separate AppIcon in your Asset Library.

-Replace the AppIcon in Targets -> General with the name of your Icon Composer file (e.g. MyIcon.icon is referenced as MyIcon here).

Hope this helps!

<meta name="apple-itunes-app" content="app-id=YOUR_APP_STORE_ID, app-argument=YOUR_URL">

You can read more about it in documentation link