191–200 of 588 posts
Earlier quoted context omitted.
Don't know last time I tried React Native and wanted to use some cool feature of iOS. I either had to write my own RN plugin in Swift/ObjC or wait for someone else to do it.
You say that like writing plugins is hard or undesirable.
OP is pretty much saying that.
this stuff is life or death, and also impossible without giving up on native:
> React Native on both iOS and Android and shares 95% of the same code
> less crashes on iOS than our native iOS app
> an Android version launched
> team composed of mobile + non-mobile developers.
(impossible on native because of the multi-day process required to build an ios app for the first time)
> The team also came up with this cool way to instantly test work-in-progress pull requests. You simply scan a QR code from an automated Github comment on your phone and the JavaScript bundle is updated in your app
code updating is illegal on the app store, but it's hard to kick out shopify. this is a shot across the bow
Honestly I think the future of mobile will just be... mobile websites. What's missing until regular websites have parity with mobile apps in functionality? - Accelerometer and all sensor support (some of these are already supported on various browsers on various OSes) - Background support - Bluetooth - WiFi - Better notifications - etc. Sure there will always be a need for native, but 99% of apps don't need any of th…
Ten years ago Facebook fought this battle and lost. [1] [2] [3] [1]: https://www.facebook.com/notes/facebook-engineering/using-ht... "Using HTML5 Today" [2]: https://appleinsider.com/articles/12/09/11/facebook_admits_h... "Facebook admits HTML5 not competitive with Cocoa Touch" [3]: https://techcrunch.com/2012/12/13/facebook-android-faster/ "Facebook Speeds Up Android App By Ditching HTML5 And Rebuilding It Natively…
Earlier quoted context omitted.
Headcount is the biggest expense in almost all companies. Larger companies also have larger and more complex apps, so while a small company may have a small iOS development team, large companies have massive iOS development teams. Massive team * number of platforms = serious money. You also get into all kinds of platform and feature parity issues. "Why can't we do X on Android but only on iOS?", "Well because they're…
But developer headcount doesn't scale to the size of the installed base. Whether you have hundred-thousand users or a million users, you don't need a larger development team. Once you have a reasonable-sized team that can make the app, you don't need any more developers, no matter how successful your app is. Having different teams for different platforms might result in a slightly larger headcount my point is that ri…
The large companies are what they are, and you cannot apply the same type of thinking to their problems as if you were designing the organization from scratch. There's problems they have, and the team structure they would like to have, and based on that the technology choice to favor abstraction makes sense.
Earlier quoted context omitted.
In my experience Flutter is not any less productive than RN is, I'd prefer the former in every case now.
https://mobile.twitter.com/LinguaBrowse/status/1220695261246...
Flutter has its bugs but they're certainly not that fundamental issues.
Source: https://dev.to/agiratech/flutter-vs-react-native-what-to-cho...
"At the beginning of 2019, we did a 6-week experiment on our flagship Point of Sale (POS) app to see if it would be a good candidate for a rewrite in React Native. We learned a lot, including that our retail merchants expect almost 2x the responsiveness in our POS due to the muscle memory of using our app while also talking to customers.
In order to best serve our retail merchants and learn about React Native in a physical retail setting, we decided to build out the new POS natively for iOS and use React Native for Android."
So it's okay to build Android and less important apps using RN, but their flagship iOS POSS is off limits?
I'm surprised no one is mentioning this: "At the beginning of 2019, we did a 6-week experiment on our flagship Point of Sale (POS) app to see if it would be a good candidate for a rewrite in React Native. We learned a lot, including that our retail merchants expect almost 2x the responsiveness in our POS due to the muscle memory of using our app while also talking to customers. In order to best serve our retail merch…
I don't understand why so many large companies use platform abstractions. At a certain size you're big enough to have an iOS team that develops natively in Swift/ObjC and an Android team developing natively in Kotlin or Java. Developing directly for the platform, with expertise in that platform, is a proven long term bet. Screwing around with platform abstractions seems much riskier. The situation is a lot different…
Even large companies can be cheap. Hiring developers is a complicated and costly process. But I'd wager that using a solution that the company or a middle manager X,Y,Z didn't vet before can also be a complicated a costly process. Plenty of language X shops refuse to use language Y for political reasons.
Earlier quoted context omitted.
> Installing software is cringey as hell now? When you know that the features you're interested in can be made easily available by a simple web app.
Perhaps I'm misunderstanding the logic but doesn't that mean using a fancy pen is "cringey as hell" since you can just use a simple ballpoint pen? Sorry, it just seems unnecessarily negative to me.
Besides, I do find fancy pens cringey, but that's another story :)