I wrote my first Swift code in June 2014, the week after WWDC. I was an intern at TOPS Technologies in Surat, and I had been writing iOS apps in Objective-C for three months. Swift felt like the future arriving too soon — exciting and slightly unfinished, which, if you remember those early betas, was accurate.
Eleven years later I lead the mobile team at NexTurn India, building AI-powered physiotherapy tools using MediaPipe and Apple's Vision Framework. The path between those two points was not linear, and the lessons I picked up were rarely the ones I expected.
Read the platform documentation, actually read it
The single highest-leverage habit I developed was reading Apple's documentation and watching WWDC sessions systematically, not just searching Stack Overflow when something broke.
Most iOS bugs are not novel. They are documented behaviours that developers hit because they did not read the documentation. The concurrency gotchas in Grand Central Dispatch, the layout cycle in UIKit, the state restoration dance — Apple documented all of them. The developers who read the docs ship fewer bugs and debug faster, because they know what the platform is actually doing, not what they assumed it was doing.
WWDC sessions are a level above the docs. They explain why APIs are designed the way they are, which tells you where the edges are. Understanding why willSet and didSet work the way they do, or why SwiftUI uses value types for views, shapes how you use them. Watch the sessions for technologies you work with, not just the announcement sessions.
Architecture matters later, not day one
Early in my career I spent too much time choosing between MVVM, VIPER, and Clean Architecture before I had written enough code to understand what problem each one solved. I implemented patterns I did not fully understand because a blog post made them sound professional.
The truth is that architecture pays off at scale — when a codebase has multiple engineers, when features evolve in ways you did not predict, when the original author has left and someone else has to maintain it. For a junior developer shipping their first real app, the better investment is writing clean, readable code within a simpler structure.
What I wish I had done at the start: pick MVC, follow Apple's patterns, and focus on writing methods that do one thing and that have clear names. That discipline transfers to any architecture. Patterns are containers — what you put in them is what matters.
Ship something imperfect early
At every stage of my career I have been tempted to wait until the code was ready before showing it. Clients, managers, and team leads who could have told me I was solving the wrong problem waited weeks longer than they needed to because I was polishing something that needed to be redesigned from scratch.
The best feedback loop in software development is a working app in front of a real user. Not a prototype, not a mockup, not a screen recording — a TestFlight build that the person can actually tap on. Working code that does 40% of the job gets you better feedback than a perfect design document.
I now ship to TestFlight every week, sometimes twice a week, even when the build is rough. The discipline of making a build shippable every week forces you to keep the codebase in a deployable state, which is a better outcome than the alternative.
The network around you is the career accelerant
I got my role at Shivam Jewels because of a referral from someone I had worked with at DRC Infotech. I got the NexTurn engagement because of a recommendation from a client whose app I had helped debug. Every meaningful career move I have made came through a relationship, not a job board.
This is not unique to me — it is true for most engineers. The implication is that the quality of your work and your reputation as someone who is reliable and good to work with matters more than any technical skill on your CV.
Be the person who responds promptly, who says what they will do and does it, who gives honest status on where a feature stands. Those qualities are rarer than good code, and they compound. Engineers with strong networks get the interesting problems, the better compensation, and the faster paths to lead roles.
Specialisation is a strategic choice, not a trap
Around 2019 I had a choice: stay deep in iOS, or broaden into backend and fullstack. A lot of advice at the time said that generalists were more valuable and more employable. I stayed in iOS.
The generalist-vs-specialist debate is real, but it misses the point. The question is not whether to specialise — it is whether you are specialising in something that has genuine depth and genuine demand. Native iOS development has both. The platform changes every year at WWDC, there is always something new to learn, and the barrier to doing it well is high enough that companies pay a premium for engineers who have been doing it for a decade.
Broadening is valuable too. I learned React Native and Flutter, which made me a better architect because I understood trade-offs I would otherwise have argued about theoretically. But I did not dilute my iOS identity. The depth is where the value is.
Tools change, thinking does not
When I started, the industry was moving from Objective-C to Swift. Then from XIBs and Storyboards to programmatic UI. Then from UIKit to SwiftUI. Now from reactive patterns to Swift concurrency. Each transition felt urgent and existential at the time.
Looking back, the engineers who navigated these transitions smoothly were not the ones who jumped on each new tool fastest. They were the ones who understood the underlying principles — why Combine solved the problems it solved, why async/await is not just syntax sugar for callbacks. Tools are implementations of ideas. If you understand the idea, you can learn the tool quickly. If you only know the tool, you are starting from scratch with every transition.
Learn the principles. Read the proposals (Swift Evolution is public). Understand why the language and frameworks change in the direction they do. That understanding compounds.
The one thing that changed everything
If I could go back and give myself one instruction: build something real and ship it.
Not a tutorial project. Not a portfolio app that has three screens and a hard-coded JSON response. A real app, with real users, where real things break in production and you have to fix them on a Sunday night. The debugging skills, the release discipline, the ability to estimate accurately and communicate honestly about scope — these only develop under real conditions.
I published my first personal iOS app in 2016. It had eleven users. Two of them were my parents. It crashed on iOS 9 devices. Fixing those crashes taught me more about memory management than three years of tutorials. Ship early, fix fast, repeat.