I’m a frontend developer who has worked with Angular and React for the past few years. Both frameworks have taught me a lot, but React in particular has dominated my recent experience. It’s popular, flexible, and powerful — no doubt about that. But despite its upsides, working with React in real-world production apps slowly pushed me to a breaking point.
React often felt… messy.
Even though React gives you freedom, that same freedom can become a burden, especially as your project grows. Every team ends up inventing their own structure, folder naming conventions, and state management preferences, and you’re left stitching everything together with dozens of third-party libraries. It’s like building a city with Lego bricks… from a thousand different boxes.
The biggest pain points for me were:
JavaScript itself — coming from a JS-heavy background, I constantly struggled with its lack of structure and unpredictable behavior. Even TypeScript sometimes felt like a band-aid on top of chaos.
Code maintainability — as the app scaled, so did the number of hacks, abstractions, and side effects. Reading your code a month later felt like reverse-engineering someone else’s logic.
Third-party overload — almost every feature depended on an external library: routing, form validation, state, icons, UI kits — each with its own bugs, updates, and documentation inconsistencies.
After I quit my job, I finally had time to breathe and explore.
I’ve always been a fan of Apple and their ecosystem, and this was my chance to try something I had wanted to test for a long time: native iOS development.
Why Native? Why Swift?
One of the main reasons I was drawn to native was the feel of the apps. Native iOS apps just have a certain smoothness and polish that I’ve never felt replicated on the web, even with all the latest advancements in web performance. The animations, the responsiveness… It’s just different.
So I jumped into Swift and SwiftUI.
At first? Honestly, it felt weird. The syntax was unfamiliar, the tools were new, and coming from a JavaScript background, I had to unlearn some habits. But very quickly, I started appreciating what Swift was offering:
A modern, strongly typed language with clear syntax
Minimal reliance on external packages for basic functionality
A UI framework (SwiftUI) that feels designed for building interfaces, not fighting with them
I always struggled with JavaScript’s lack of structure. Even with best practices, I often felt like I was hacking things together rather than building something proper. Angular did a better job at enforcing structure, but Swift and SwiftUI feel like a natural evolution — strict enough to help you write maintainable code, yet still elegant and expressive.
What’s Not So Great?
That said, I’ve already run into some rough edges:
SwiftUI can feel more rigid than CSS — While I love SwiftUI’s declarative syntax, coming from the web, I missed the flexibility of CSS. Controlling layouts and spacing isn’t always intuitive in SwiftUI, especially when you’re used to things like Flexbox and Grid.
Xcode Simulator is sluggish on my M1 Mac — It’s usable, but not exactly snappy. Previews sometimes don’t refresh properly or crash. And while Xcode has many great features, it doesn’t match the speed and simplicity of tools like VSCode, especially when you’re in the early stages of learning.
The learning curve is real — Swift itself is a big jump from JavaScript, and SwiftUI, while modern, has its own set of concepts like @State, @Binding, and ViewBuilders that take time to click. If you’re just getting into coding, iOS might feel like a steep first mountain to climb compared to the instant feedback loop of web development.
To be clear: I’m still early in this journey. I’ve just started exploring this ecosystem, and I’m sure I haven’t seen all the downsides yet. Maybe once I try building a full production-level app, more pain points will show up.
But that’s the thing — you can’t fully judge a language or framework until you try building something real with it.
Top comments (0)