Remix.run Logo
mattfrommars 8 hours ago

People who code for mobile development, like OP, is IOS development their full time job? Because as someone who does web development, to learn the in and out of Swift programming language and using XCode feel major vendor lockin and prefer say React Native due to its interoperability.

ascorbic 7 hours ago | parent | next [-]

Usually, yes. The overwhelming majority of mobile dev jobs are platform-specific, or are specifically for a framework like React Native.

With native mobile dev, lock-in is less of a problem career-wise, because it's a duopoly, so your chosen technology is unlikely to become unfashionable like it would if you were specialised in a particular web framework.

serial_dev 7 hours ago | parent | prev | next [-]

If you want to develop mobile apps and you want to have users, there is no way around vendor lock in and walled gardens. By supporting Android, too, the only thing you’ll achieve is that you’ll be the abused in two abusive relationships instead of one.

Adding more abstractions on top will not significantly improve the fact that you are at the whims and mercy of companies that don’t care about you, so I don’t see RN as an improvement.

If you want to avoid vendor lockin, don’t do mobile apps, go to web. Then, you can also just switch RN to React simply or any other framework.

cosmic_cheese 7 hours ago | parent | prev | next [-]

Even if using a framework like RN, solo devs would be putting themselves in a precarious position if they don't understand the underlying systems and frameworks. Without that knowledge they won't be able to effectively debug and figure out if issues are stemming from the cross-platform framework or the native platform/framework and subsequently will be entirely dependent on outside parties for fixes.

So if they're learning the native frameworks anyway, they may as well use them. These days with Swift and Kotlin most logic code transfers pretty cleanly and most apps can be LEGO'd together from UIKit/SwiftUI/Compose components, so the workload isn't as high as one might expect.

Aside from that, early on it's usually better to start with one platform, nail the UI and interaction, and then once the app is proven worry about the other platform.

RobRivera 8 hours ago | parent | prev | next [-]

If you browse job listings, you will find titles for 'iOS developer' and 'Android Mobile Developer'

mattfrommars 8 hours ago | parent [-]

Yup, I know that but my reason to ask was that if most people who develop for IOS also know web development, as in full stack development. or are they usually IOS developer fulltime.

tcoff91 8 hours ago | parent [-]

Most are full time iOS developers.

k4rli 7 hours ago | parent | prev | next [-]

Even with RN I've had to learn Swift and also often need xcode for configuring targets and such. RN helps in some ways but native apps are so much better in the long run.

RN libraries are so often buggy and disappointing in my experience.

hombre_fatal 7 hours ago | parent | prev [-]

It doesn't really make sense to call it vendor lock-in when you're learning a platform's native API and idiosyncrasies.

That would apply more to React Native since you are stuck with its vendored abstractions and you can't just swap out React Native once you've built with it.

I think you're commenting on how iOS development is a less portable skill than a toolkit than runs on all platforms. Or that your iOS app is stuck on one platform. That is certainly true. But don't overlook the value of expertise in a native platform instead of just one set of abstractions that run on top of it. There are things you can do on the native platform, like optimizing performance, that you can't do using something like React Native.

It's all just trade-offs.

cosmic_cheese 6 hours ago | parent [-]

> That is certainly true. But don't overlook the value of expertise in a native platform instead of just one set of abstractions that run on top of it.

This applies to the web, too. A dev who has a good grasp of of the fundamentals (HTML, CSS, JS), the DOM, what does and doesn't trigger a repaint, etc is going to be able to take a React project a lot further than a dev who only knows how to use React.