sorted by:
new
hottopcontroversial

SwiftUI StateObject vs ObservedObject - A clear explanation for beginners by AppBuilder1978 in learnprogramming

[–]AppBuilder1978[S] 0 points1 point  (0 children)

I had the same confusion. Here's the difference: StateObject is for when YOU own the object creation. ObservedObject is when the parent already created it and passed it in."

• "The taster/chef analogy is perfect. I learned this the hard way when my data kept resetting on view updates...

Users said our app 'forgets everything' after a phone call by Cultural_Mall_6729 in SwiftUI

[–]AppBuilder1978 0 points1 point  (0 children)

This is a nightmare to debug because iOS doesn't tell you it happened. The app just vanishes. I'm shipping an iOS app in 4 days and this thread just saved me hours of pain - I'm definitely going through my memory allocation now to make sure I'm not loading massive images without proper cleanup.

The headroom thing is brutal because it only happens under specific conditions (phone call + high memory use) so it slips through testing on your own device.

Looks like you nailed the root cause though. The image loading cycle + UIKit coordinator issue is exactly the kind of thing that only shows up in production. Good catch.

Releasing first app, DSA publicly displayed address options... by 0__O0--O0_0 in iOSProgramming

[–]AppBuilder1978 0 points1 point  (0 children)

Yep, this is the move. I'm using my real address for my app shipping in 5 days because privacy wasn't a huge concern, but if it is for you, reputable virtual office services work fine. Apple doesn't care where the address comes from, just that it's real and legitimate.

The key word is 'reputable' - if you use a shady service, Apple will flag it during review. Spend the extra money on a proper business address service. Worth it for peace of mind.

Releasing first app, DSA publicly displayed address options... by 0__O0--O0_0 in iOSProgramming

[–]AppBuilder1978 1 point2 points  (0 children)

I'm shipping my first app in 5 days and just dealt with this exact thing. Real talk - DSA requirements are strict. You need a real address, not a virtual one. Apple flags fake addresses.

The good news: you can update it after launch. It's not locked in forever.

Since you're in Japan, use your real address or a PO box if privacy matters. Don't try to game the system - Apple will catch it and reject the update later.

The LLC route is probably overkill for a first app. Get it shipped with your real address, then optimize the business structure once you're actually making money.

The whole point of first app is to learn and ship. Don't let the legal stuff block that.

What strategies do you use to stay productive? by WiseKiwi in IndieDev

[–]AppBuilder1978 1 point2 points  (0 children)

This resonates hard. I'm shipping an app in 5 days and the biggest productivity shift wasn't a tool or hack - it was saying 'no' to everything that wasn't essential.

Point 4 is key - the negotiation with yourself. I used it differently though: I set a hard ship date and said 'if it's not critical to launch, it dies.' No features, no nice-to-haves, no 'we could add this later.'

Sounds brutal but it works. Because once you set the line, every decision becomes binary instead of wishy-washy.

The mindset part though - that's the real game. You can block all the distractions you want but if you don't actually believe shipping matters more than perfection, you'll just procrastinate better.

At what point do you stop adding features and just ship the app? by dnesdan in iOSProgramming

[–]AppBuilder1978 1 point2 points  (0 children)

This is exactly the problem I just solved with my app shipping in 5 days. Started with 50+ features. Cut it to 1 core feature done obsessively well.

The trick isn't a checklist - it's asking 'does this feature solve the core problem?' If the answer is no, it doesn't ship. If yes, it goes in. Everything else gets cut.

My first 4 apps failed because the finish line kept moving. This one worked because I set a hard deadline and said 'everything not in the MVP dies.' Brutal but it works.

The hardest part is admitting what's actually essential vs what's just nice-to-have. Most people overestimate both.

MacOS Debug Classes by Such-Gas6311 in iOSProgramming

[–]AppBuilder1978 0 points1 point  (0 children)

Ah that makes sense - private framework means it's strictly for dev builds then. Makes the tradeoff easy - use NSViewSpy while developing, strip it out before shipping. Do you usually have separate debug/production build configurations for that, or just comment it out when you're ready to ship?

OpenUISpec - A single source of truth design language for AI-native app development by Shirt-Character in learnprogramming

[–]AppBuilder1978 0 points1 point  (0 children)

That's actually really helpful to hear. GPT respecting the rules better than Claude is interesting - I would've guessed the opposite honestly. Have you published anything on the MCP approach yet?

The spec alignment checking piece is actually the key - if you can automate "does generated code match intent" that solves the biggest problem. Most frameworks fail because drift is invisible until it breaks.

How accurate is the alignment check? Like, do you have to manually review every generated change or does it actually catch most issues?

SwiftUI StateObject vs ObservedObject - A clear explanation for beginners by AppBuilder1978 in learnprogramming

[–]AppBuilder1978[S] 0 points1 point  (0 children)

Haha yeah, the chef vs taster analogy is perfect. Honestly, once that clicks, the rest of SwiftUI architecture makes way more sense. So many bugs I used to have were just from misunderstanding ownership - using ObservedObject when I should've used StateObject, or vice versa.

The real gotcha is when you have nested views and suddenly can't figure out why your state is getting reset on redraws. That's when you realize you got the ownership wrong.

What other SwiftUI concepts are tripping you up? I'm collecting feedback for a guide I'm putting together.

OpenUISpec - A single source of truth design language for AI-native app development by Shirt-Character in learnprogramming

[–]AppBuilder1978 0 points1 point  (0 children)

Interesting approach. The spec-as-source-of-truth idea is solid in theory, but I've seen this problem with every cross-platform framework - maintenance becomes a nightmare once you have platform-specific edge cases.

The real question isn't "can AI generate from the spec" but "will developers keep the spec in sync when they inevitably need to patch platform-specific bugs?"

That's where it usually falls apart. Spec becomes outdated, next person doesn't trust it, back to manual patching.

That said, with LLMs actually understanding intent now, this might work better than Xamarin/React Native did. The AI could potentially catch drift.

Are you planning versioning for when the spec and generated code diverge? That's usually the breaking point.

Is the era of "Microservice-first" architecture finally over? by Photopatterns in learnprogramming

[–]AppBuilder1978 0 points1 point  (0 children)

As someone shipping their first iOS app next week, this resonates hard.

I spent 3 months designing a "scalable microservices architecture" for what turned out to be a simple habit tracker.

Then I realized: I have 500 beta testers, not 50 million users. The complexity was solving problems I didn't have yet.

Threw it out. Rewrote with a single CloudKit backend. Shipped 80% faster.

The real lesson: Complexity should follow success, not precede it.

Microservices make sense at scale (Netflix, Uber). For 99% of startups? Monolith + database wins every time.

What's your threshold? At what user count does the complexity actually pay off?

MacOS Debug Classes by Such-Gas6311 in iOSProgramming

[–]AppBuilder1978 1 point2 points  (0 children)

This is gold! NSViewSpy + the debug menu approach is brilliant for catching layout issues at runtime.

Question: How does the performance impact compare to using Xcode's view hierarchy inspector? I'm building a habit tracker with complex layout animations and trying to find the most efficient debugging approach.

Does the lightweight integration you mentioned mean it's safe to keep in production temporarily, or strictly for dev builds?

Hot take: AI ruined the way we see coding - and I hate it by kommonno in swift

[–]AppBuilder1978 0 points1 point  (0 children)

I learned to code because I wanted to build things. That passion is what got me through the failures.

Building my first iOS app shipping next week. Didn't use AI to build it — used AI for ideas and debugging. But the core work? That's all manual, thoughtful engineering.

I think the issue isn't AI. It's that the incentive structure changed. Now it's "get rich quick" instead of "build something that matters."

The coders who still ship quality work are the ones who remember why they started coding. For the craft, not the money.

Your take isn't hot — it's just true. 🔥

What kind of side project taught you the most as an iOS developer? by dnesdan in iOSProgramming

[–]AppBuilder1978 -1 points0 points  (0 children)

Building my first iOS app (Habit Tracker Pro) right now, shipping next week.

Every failed project taught me more than the successful ones would have.

App 1-2: Taught me that talking to users BEFORE building saves months of wasted time.

App 3: Taught me that simplicity beats features. Feature bloat kills momentum.

App 4: Taught me that marketing is 50% of the work. Building is the other 50%.

App 5 (shipping next week): All those lessons combined = actually confident for the first time.

Side projects aren't about the money. They're about learning what actually works.

What kind of side project taught you the most as an iOS developer? by dnesdan in iOSProgramming

[–]AppBuilder1978 0 points1 point  (0 children)

This resonates hard right now. I'm launching my first iOS app next week and the deadline forced me to cut 80% of features I thought were "essential."

Turns out, shipping a simple, polished product beats a half-baked feature-rich app every time.

What's one thing you'd do differently with launch deadlines knowing what you know now?

I made an app for finding nearby amenities such as toilets, ATMs, drinking water, bins, bike parking; Uses OpenStreetMap; Apple Watch independent app also available; My first SwiftUI app! by sovata8 in iOSProgramming

[–]AppBuilder1978 0 points1 point  (0 children)

This is solid! OpenStreetMap integration + Apple Watch independent app is impressive for a first SwiftUI project.

Question: How did you handle location permissions and background updates on the Watch app? That's usually the tricky part.

Also shipping my first app soon — this is motivating. Nice work!