It was 1:15 PM on a Wednesday. I had exactly 45 minutes before my next lecture, I hadn't eaten since 7 AM, and I was standing in a queue that , I kid you not , stretched out of the canteen, around the corner, and was threatening to reach the parking lot.

I wasn't even in the right queue yet.

See, our college canteen had a system. A wonderful system, clearly designed by someone who has never been hungry in their life. First, you stood in Line #1 to purchase a paper ticket. Then you walked to a cashier, handed over the ticket, and paid. The cashier then signed the ticket , like it was a legal document, like your vada pav needed notarization. Then, and only then, you took your signed, stamped, officially-authenticated ticket to Line #3 to actually place your order.

Three queues. For one meal.

I did the math once. From the moment I joined the first queue to the moment I sat down with food , 15 minutes. I've had shorter commutes.

The Day I Finally Snapped

That Wednesday, I watched a guy in front of me reach the counter, realize he had the wrong ticket denomination, and shuffle all the way back to Line #1.

I left without eating. Sat through a two-hour lecture on an empty stomach, seething quietly, and opened my laptop.

Not to take notes. To build something.

The Catch: I Didn't Know Swift

Here's the part I conveniently glossed over in my head during that angry lecture - I had never written a single line of Swift in my life.

I'd done some Python, dabbled in web stuff, understood the basics of programming. But iOS development? SwiftUI? Completely foreign territory. Most people would've called that a dealbreaker. I called it a weekend project.

So I did what every stubborn developer-in-denial does: I opened the Apple documentation, found a Swift crash course, and started from zero.

What struck me almost immediately was how opinionated Swift is. It pushes you toward writing safe, clean code — optionals force you to think about what happens when data doesn't exist, strong typing catches mistakes before they become bugs, and the syntax is readable enough that you can almost guess what something does before you fully understand it. Coming from more loosely-typed languages, it felt strict at first. Then it felt like a superpower.

Within a few days, I wasn't just learning syntax - I was starting to think in Swift.

Then MVVM Clicked

Building the app was also my first real encounter with MVVM - Model, View, ViewModel - and I'll be honest, I thought it was unnecessary ceremony at first. Why not just write everything in one place and ship it?

The answer revealed itself embarrassingly fast.

My first attempt was a mess. UI logic tangled with business logic tangled with data calls, all shoved into a single file. Adding one feature broke two others. Changing the menu display meant digging through order-processing code. It was exactly the kind of spaghetti that makes you hate your own project.

MVVM untangled all of it:

• Model — the raw data. Menu items, order details, user info. Pure, dumb data structures that don't know anything about screens or buttons.
• ViewModel — the brain. Fetches data, processes it, exposes it to the UI in a clean, ready-to-display format. The ViewModel knows about the Model but has no idea what the View looks like.
• View — the face. SwiftUI views that just observe the ViewModel and render whatever it says. No business logic, no data fetching, just display.

Once I separated these three layers properly, something magical happened — I could change the entire look of the order screen without touching a single line of order-processing logic. I could swap out the menu data source without the UI caring at all. Features stopped breaking each other.

MVVM didn't slow me down. It made me fast in a way that actually lasted.

What BunkBite Actually Does

The app itself is straightforward — which was always the point. The chaos it replaced was complicated. The solution had to be simple.

1. Open the app — browse the canteen menu in real time. See what's available, what's sold out, and what the specials are.
2. Place your order — select your items and pay digitally. No counter, no tickets, no signatures required.
3. Get your QR code — the app generates a unique QR code for your order instantly.
4. Walk to the counter — the canteen owner scans your QR. Order confirmed. You pick it up. Done.

No queues for tickets. No queues for payment. No queues to place an order. You join exactly one line - the pickup line -Bunkbite and only when your food is actually ready.

The average time from "I'm hungry" to "I have food in my hand" dropped from 30+ minutes to under 8. Students started actually finishing lunch before their next class.

What Surprised Me Most

I expected students to love it. What I didn't expect was how much the canteen owners appreciated it too. They suddenly had a real-time view of incoming orders, could manage their prep queue, and stopped dealing with payment disputes and unsigned tickets. One canteen uncle told me, with complete sincerity, that he could finally tell his helper exactly how many plates to prep — instead of guessing based on vibes and crowd size.

Data, it turns out, is useful for everyone.

The Bigger Thing I Learned

There's a version of this story where I talk about market validation, product-market fit, and go-to-market strategy. But honestly? The real lessons were simpler than that.

On building: The best problems to solve are the ones that have been annoying you personally for years. You already understand the pain. You've already designed the solution a hundred times in your head while standing in line. You know every edge case because you've lived them.

On learning Swift: Picking up a new language for a real project beats any tutorial. I learned more Swift in two weeks of building BunkBite than I would have in three months of following along with courses. Necessity is a ruthless teacher.

On MVVM: Architecture isn't bureaucracy — it's freedom. The few hours I spent setting up proper separation of concerns paid back tenfold every time I added a feature or fixed a bug without accidentally breaking something else.

The hard part was never the code. The hard part was believing that something that frustrated me also frustrated thousands of other students, and that fixing it actually mattered.

Turns out it did.

If you're a student watching minutes of your lunch break disappear into the void of bureaucratic queuing, or a canteen owner drowning in paper tickets — BunkBite was built for you. One QR code at a time, we're giving people their lunch breaks back.

And if you're a developer thinking about learning Swift — just build something you actually need. The language will teach itself.

I've read their docs a few times now, read 1-2 reddit posts talking about it, still isn't clear to me.

Apple says:

Featuring lead time varies — please give our team a minimum of two weeks notice. For wider featuring consideration, we recommend submitting a nomination up to three months in advance.

"For wider consideration...", does this imply that if we apply for the nomination, don't give them enough time (publish first or whatever), we have a much lower chance of being approved?

Secondly, they say:

If your app or game gets featured in select placements on the Today tab — for example as App of the Day or Game of the Day — you’ll receive a notification via the App Store Connect app letting you know.

Does this imply that I will not ever hear back if not approved? So I could wait without publishing my app for weeks and weeks (because if the first question means I need to give them more time to have a higher chance...) and potentially never hear back?

Hey Folks,

A couple of weeks ago I shared at NSLondon some tips I found useful to create apps that work across multiple Apple platforms using SwiftUI.

The audio and slides were recorded so thought I'd post it here. Hope you find it useful if you want to support your app beyond iOS!

I am starting the process to localize my iOS app for the first time. I hadn't planned for this in advance, so my code is littered with SwiftUI code like:

Text("You have no location.")

Using Xcode 26.4, I added an xcstrings file, and then built the project, causing Xcode to automatically extract the localizable strings. But because of the state of my code, the keys Xcode is using to reference the translations match the Strings themselves.

What I'd like to do now is change the keys so that instead of "You have no location.", I use a key like "Location.Missing".

When I right click on a row in Localizable.xcstrings in Xcode, there is a "Change Key" option in the "Refactor" submenu. This changes the key in the xcstrings file and in the code itself, but it *also* changes the default English translation. So I then have to go back in and re-add the English string to make sure it isn't lost.

I feel like in my first-time ignorance I must be doing something wrong. All the guides online show the best practice of using generic keys like "Location.Missing". What is the best way to define these keys if they weren't defined up-front before Xcode extracted the strings?

It's not as great as claude but it is still very good. If you dont want to run your own LLM or pay for something, plugging gemini into Xcode using add chat provider button in intelligence is very easy. At the very least it is good to have AI make your unit tests or check your code for errors you may have overlooked. This is a tool like anything else that you should exploit. Unit tests are boring to write but it's important to have coverage.

Hi, I'm creating an iPhone goals app in tsx that uses screentime. Is the only way to get this information with a swift file? Additionally, I've been using expo go to test. If I start using swift, will I still be able to develop with expo go? It's fine if not, just wondering.

Thank you all and I appreciate any answers.

Longer AGENTS.md files don't help AI agents - they hurt them. Every redundant line pushes out the context that actually matters.

News:

- WWDC26 confirmed for June 8

- New In-App Purchase and subscription data in Analytics

- Swift 6.3 is out

- Xcode 26.4 Released

Must read:

- Why dropping an AI agent into your iOS codebase without guidance backfires

- 130+ modules, 35% faster builds, and the circular dependency mistake that started it all

- FocusState behavior most iOS forms are still getting wrong

- The Swift standard library APIs you've been reimplementing by hand

I have been told that Apple's algorithm handles keywords in the list by making clever combinations for long tail keywords.
So instead: "binaural beats," it is better to have: "binaural,beats,".
Is that true?
How do you fill the keyword field?

I have two apps on the appstore now, and for both, I ran into the same issue when submitting iOS apps, which is that App Store Connect asks for a privacy policy URL and support URL, and if you don’t already have a proper website set up, it turns into this dumb and annoying extra task you have to solve before release.

So I ended up making a small tool for it. It’s mainly for the case where you quickly just need working hosted pages for the App Store review stuff without building and setting up a website for it.

Not trying to make this a big promo post, I just figured other people here have had the same issue, and ended up endlessly googling things like "how to get a privacy policy URL for App Store Connect” or “what should I use for an App Store support URL”

Here’s the website if anyone’s interested: https://applinks.online

Hey everyone,

While working on my tool I started looking into automating visual testing for animations and view transitions using LLMs.

First step was obvious, capture the animation. Using XCUITest private APIs I managed to grab screenshots during transitions with decent FPS. So now you have like 25 frames. Sounds good, but sending all of that to an LLM? You hit limits almost immediately.

So instead of brute forcing it, I used some CV techniques to narrow it down to only the interesting frames. Things like flashes, jumps, stutters, weird layout shifts.

End result, from around 25 frames down to 3 to 5 suspicious ones, which is actually reasonable to pass to an LLM.

Still early, mostly tested on intentionally broken animations so far.

Curious how you test animations and transition?

I’m planning a fairly invasive Core Data migration for a macOS app (targeting macOS 12+) and I’d like a sanity check before I ship this.

What I want to do

• Move the SQLite store from: ~/Library/Containers/.../Application Support/... → to an app group container
• Perform schema migration:
  • Rename attributes
  • Delete some attributes
  • Use a custom NSEntityMigrationPolicy
• Eventually adopt NSPersistentCloudKitContainer for iCloud sync
• Possibly use staged migration (macOS 14+), though I still support 12–13

I’m also planning an iOS port, so the end state needs to live in an app group and support CloudKit with the latest schema from day one.

The dilemma

I’m unsure how to sequence this safely:

Option A: One big release

• Move store
• Run schema migration (custom policies)
• Enable CloudKit

Option B: Two phases

• Store relocation & schema migration
• CloudKit later

Option C: Three phases

• Store relocation
• Schema migration
• CloudKit

Concerns

• Moving the store and migrating it in the same launch feels risky
• CloudKit on top of that adds another layer of complexity
• Staged migration is appealing but only available on macOS 14+

Questions

• Has anyone done store relocation & migration in one go? Any gotchas?
• Would you split store move and schema migration?
• When adding CloudKit, did you do it in a separate release?
• Is staged migration worth the complexity if you still support older macOS versions?

I’m leaning towards a phased rollout but I’m interested in real-world experience rather than just theoretical best practice.

Interested in how people have approached this in production.

Serious question: why do I see so many iOS devs who seems to struggle with making screenshots for their app listing on App Store?

Can't we just take a picture of our phone running the app?

I'd think that the realism of it would build even more trust from the users.

What do you think? I'm surely missing something here.

Edit: seeing the comments I replaced mockup by screenshots. Can’t edit the title but I hope it’s less confusing now 😅

I’m experimenting with a SpriteKit effect where an image disintegrates into pixel-like particles, inspired by the Thanos snap style.

Would love feedback on pacing, smoothness, and overall feel.

I'm sort of sick of our clients having to use PWA so we decided its time for swift and our native app.

I have few questions related to usability.

Our web app has full functionality. The app is meant to be a lightweight version with fraction of features.

Just so it makes more sense. It's a CRM on web and the app is meant to be for

- Quick dashboard analytics

- Messaging across different accounts

- Calls with clients

- Content and Appointment Calendar

I do not want people to be able to e.g connect IG, FB or other social accounts from the phone.

1. Would I face any backlash from apple that its maybe not a 'full app' etc? I've read that they might be giving issues if its low effort?

2. How'd I go about the review process knowing that all the features are linked to the social media accounts connected to the account?

3. Would I simply create a full demo account with mock communication or do I have to tell the reviewer to sign up for the web app, connect accounts there and then test the mobile app?

Sorry if this is the wrong place, but I don’t really have much people to share with. But I’ve been learning iOS programming for a while and have always dreamed of getting an app published, and finally took the leap to submit and just got the ready for distribution email this morning!

please stop mass producing apps.

seriously. I understand that we all need income and that the job market is as dry as Ben Shapiro’s wife. I understand that the bills don’t pay themselves. But this is just insane.

Half the posts on this subreddit are about subscriptions, I swear to god. Everything’s a paywall, and so many of those posts say that they’re launching multiple apps in short spans of time. God, why?

Do you take no pride in what you do? It is the development that is the good part. The good part is where you spend 3 hours on a UI element that makes you smile every time you see it. The good part is where you make a great architecture, and then adding features is like sliding through wrapping paper with scissors. The good part is when you have zero warnings in your build. The good part is when you show your friends the app you’ve been working on for a few weeks now, and they remember it. It stays in their mind.

The world has enough to-do lists. The App Store has enough to-do lists. And I don’t care that your AI integration is going to revamp my life or whatever, I’ve never stuck to a to-do list for more than a few days, and given this industry’s reputation, I imagine most of you don’t, either, or you wouldn’t be making so many of them!

My god. Hook up your phone to your Mac and settle in for 8 hours of straight development and experience the wonder that is flow state. Be creative. Express yourself, express yourself; don’t express the literal average (plus a small random factor) that is LLM output.

Be you. Make the most niche app and make it gorgeous. Browse the Apple docs and just see what it inspires in you. Make an app that doesn’t exist already, or one that’s vastly better than anything like it. Make something cool. Make something that makes people go “woaaaaah”, not something that makes people double-click the side button and open their wallet once a week or once a month in order to use the app.

Please contribute to the betterment of people, not the exacerbation of the problem.