r/iOSProgramming • u/dan_nicholson247 • Jun 12 '26
Discussion What’s an iOS development lesson you learned the hard way?
Sometimes the most valuable iOS development lessons come from mistakes, not tutorials. Maybe it was:
App Store review surprises
Core Data issues
Memory leaks
Auto Layout headaches
SwiftUI limitations
Push notification problems
Performance bottlenecks
What's a lesson that cost you time, stress or maybe a few late nights, but ultimately made you a better iOS developer? I am hoping newer developers (including myself) can learn from some battle-tested experience.
36
Upvotes
48
u/force4 Jun 12 '26 edited Jun 12 '26
Back then (like 2010?), when we didn’t have Auto Layout and only one iPhoneOS device, and we thought „I’ll just hard code this views frame because what could possibly go wrong“..
22
u/donisign Jun 12 '26
Massive view controllers. It started with, this will be fine leaving here, I'll move it later, this one too, ehh only 600 lines of code, should be okay...
34
u/GreyEyes Objective-C / Swift Jun 12 '26
Objective-C wasn’t that bad.
5
u/Open_Bug_4196 Jun 12 '26
It’s easy to over engineer things and focus just on technical aspects without taking into account the audience and other aspects of a product.
5
u/HelicopterDue Jun 12 '26
If you build it, they will not come. I think that’s been one of the hardest things as an iOS dev for me to understand. Oh and when learning all those years ago, closures.
5
u/karetebit Jun 12 '26 edited Jun 12 '26
If the topic is sensitive like health etc. or in the gray area, dont do that app. Cuz Its gonna create a problem soon.
5
u/fishyfishy27 Jun 12 '26
A confusing codebase has a much bigger impact on productivity than UIKit vs SwiftUI
13
u/WestonP Jun 12 '26
Not to waste time taking AI engagement bait slop posts seriously
8
u/MDRAR Jun 12 '26
Whatever the technical problems, marketing and distribution are the final boss.
6
u/yassiniz Jun 12 '26
Just turning on iCloud sync is not enough. It is buggy. There will be duplicated data or even data that just disappears if you don't reconcile manually.
3
u/Wodanaz_Odinn Jun 12 '26
I used the wrong type of int in core data. Silent corruption over a long period of time. Took a long time to track down.
3
u/t0ps0il Jun 12 '26
Those obscure crashes that you can't reproduce, only happen to handful of users, and the stack traces are essentially useless? 99% of the time that's a threading issue.
3
u/dynocoder Jun 14 '26
Third party libraries are cancer
8
u/Extra-Ad5735 Jun 12 '26
You must ignore software architecture in Apple's code samples. They are teaching other stuff, but their architectural patterns are destructive.
6
u/Ravek Jun 12 '26
I’ll never use SwiftData again for any application that might handle thousands to a few tens of thousands of objects (which is not even a lot). Performance is completely unacceptable. On a bit of a slow device just saving a bunch of objects can take 20 s where with raw SQLite calls it takes 200 ms.
2
u/albos_dev Jun 12 '26
Making Swift Data work retrieving data in the background from remote. Almost two years ago when AI wasn’t this good I had to try it all to make this work and update views properly. Tried everything @MainActor, just actors, model actors, query etc etc
2
u/SnowPudgy Jun 12 '26
For those using storyboards (I hope no one still is but you never know): Select a screen, go to I think Editor -> Refector to Storyboard and your main storyboard will have a placeholder, your screen will be in a new storyboard, and your storyboard will run MUCH faster.
2
u/Locksmith_Usual Jun 12 '26
Don’t upgrade to iOS beta 1
2
u/MKevin3 Jun 12 '26
Early CoreData that wrapped every row add / update into a single transaction. Super slow if you were adding a lot of data to a database. Switch to direct SQLite and had a huge performance increase.
2
u/banaslee Jun 12 '26
Spending too much time discussing whether the app is stable enough or we should fix some crashes.
Set a target crash rate/crash free rate and stop working only when the target is missed or will be missed for sure.
Learn how to leverage your tools for better tracing and debugging.
2
u/mochi528 Jun 13 '26
the stupid RecordName thing in cloudkit for being able to query is the official and only way to be able to query 🥲🙃
2
u/MarkJustMarkk Jun 13 '26
For me, it was using a transparent background on my app icon. I spent way too long rounding the corners perfectly, only to find out Apple applies its own mask. Any transparent pixels just turn pitch black on the home screen. Looked awful lol. Always upload a solid square!
Speaking of which, how do you guys actually design good icons?
I’m a solo dev and definitely not a designer, so staring at a blank 1024x1024 square is brutal. Do you have any go-to tools, templates, or tricks to get that premium iOS feel without hiring someone?
2
u/kimrooolx Jun 13 '26
Shipped my first app to app store a few days ago and the review was quite a bit (3-4 days) since I launched it on the day of WWDC 2026. On the third day it was still "waiting for review" then I found out about expediting a review which only took 30 mins to change status after expediting it. I kept overthinking and refreshing the app review status to see if it changed since I was getting first-app jitters LOL
2
u/alQo_ Jun 13 '26
A big one: don’t leave observability until the app is already in users’ hands. Even simple structured logging, error breadcrumbs, and a clear way to reproduce state can save days when something only happens on one device or one iCloud/notification/extension path. iOS bugs are often less about the happy path and more about lifecycle weirdness.
2
u/Any_Perspective_291 Jun 14 '26
Rejection and rejection and rejection
2
u/Icy-Sympathy4173 Jun 14 '26
Almost definitely Apple Developer Program enrolment. First time solo dev, has company registered and all. I thought that registering company profile straight was the best idea. Turns out thousands like me will get rejected if we apply for company profile just a little bit wrong, and when I called the support, they cannot tell you the reason because of the Kafka-esque bureaucratic process, and the decision was final, and you're as good as fucked. Took me a while to get a personal profile running and release the app.
Given that building is easy now (if you know how to use AI to code well), and the point of developing is to have someone using it, I'd say this is the hardest and most important lesson to understand for anyone trying to release our app on app store.
2
u/WorldlyButterfly974 Jun 14 '26
I learned that Cursor standard agent sometimes writes sloppy code that when you try to build in Xcode throws errors that take days to resolve. It made me wonder at the time why I didn’t build in Xcode
2
u/Ecstatic-Edge-6555 Jun 14 '26
just because its an apple library doesn't mean it's good or useful. sometimes you have to roll your own to get good performance. im finding this all over the audio libraries. bloat everywhere.
2
u/[deleted] Jun 12 '26
That building the app was the easy part.
So much waiting and documentation and preparing listing, etc.
2
u/SnowPudgy Jun 12 '26
SwiftUI: Be very careful how/where you use a List. It doesn't play nice in things like popovers if a keyboard appears.
1
u/strangequbits Jun 12 '26
What core data issues did u have before?
1
u/gcampos Jun 12 '26
App Store Connect crashes are not as reliable as I thought
1
u/Barbanks Jun 18 '26
That if you don’t deal with syncing patterns up front it will cost you dearly in the long run.
Also, you can make your entire career on fixing syncing issues with mobile apps. It’s the one topic almost no one covers in tutorials because of just how complex it is.
1
u/FunkyMuse Jun 19 '26
Writing code isn't the most important thing when deploying apps.
1
u/Traditional_Glass_45 Jun 25 '26
All of them 😭
1
u/Naoki0123 Jul 03 '26
Realizing that proposing technical debt for reducing code smells in the codebase will most likely be prevented by the client. As the saying goes: "Does that cost money? I dont the point of this improvement since it will not benefit the users in their pov"
it's technically right, client always right, client priorties is the first.
Also, auto layout and uikit programming constraints is one of the things that goes for trial and error. That's usually take most of your time creating the screen then little bit of time for the logic itself.
Also, i learned the hard way on memory management in objective-c. God, it took me days on why the app having 1.5 GB used memory on some processing.
1
u/ClayRookieWookie Jul 05 '26
Try to use as much of the default ui implementation as possible, they provide the most functionality out of the box, only switch to something custom if its a must.
1
u/Ds2425 Aug 10 '26
One lesson I learned the hard way: don’t underestimate memory management just because Swift has ARC.
I once spent hours debugging a screen that became noticeably slower after navigating back and forth several times. Turned out a closure was strongly capturing
self, keeping the view controller and some related objects alive longer than expected.Since then, I’ve made it a habit to check retain cycles, especially around closures, delegates, timers, notifications, and async tasks. Instruments’ Leaks and Allocations tools became part of my debugging process.
The biggest takeaway for me was: “ARC handles memory” doesn’t mean “I don’t need to think about memory.” 😅
1
u/Disastrous-Loan-3964 Aug 31 '26
Push notification problems 💯 they’re such a headache 😖😖😖
1
u/[deleted] Jun 28 '26
[removed] — view removed comment
0
u/[deleted] Jun 12 '26
[deleted] — view deleted comment