Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building all of our new mobile apps using React Native

engineering.shopify.com

Post reply on HN
Print view View original

221–230 of 588 posts

Re: Building all of our new mobile apps using React Native

#221

Post by beefield »

Normal_gaussian wrote: post #170
jammygit wrote: post #89

Earlier quoted context omitted.

I can’t stand push notifications, I disable them all except for a couple (like signal). They are usually only part of the app to manipulate you into using it constantly

several applications require them to be useful. Security events from my home cameras, messages from clients, timers, email Anytime I'm using a peice of small business software I'd probably like it to be able to give me notifications

Honestly curious and hopefully not rude, but how can you concentrate on anything? Or does your work/life not require you to concentrate ever/most of the time on anything?

(I have turned all but phone call and sms notifications off on my phone. I will check my email/whatsapp when I want and see notifications there as needed. If someone has something urgent, they know how to call.)

Re: Building all of our new mobile apps using React Native

#222

Post by k__ »

hopia wrote: post #195
k__ wrote: post #164

Earlier quoted context omitted.

https://mobile.twitter.com/LinguaBrowse/status/1220695261246...

The last time I was using React Native even text input was broken on Android. It made any app using it basically unusable. Android profiler didn't work either, opening it crashed the runtime. Flutter has its bugs but they're certainly not that fundamental issues.

Sounds like the opposite to me.

A bug in React Native and fundamental issues in Flutter.

Re: Building all of our new mobile apps using React Native

#223

Post by Androider »

wvenable wrote: post #212
Androider wrote: post #194

Earlier quoted context omitted.

But the question was why large companies use platform abstractions. Because they are large in headcount, by definition. Because the apps are already large. Because they have massive platform specific teams, and they would like not to. Because the teams are geographically spread out, for a myriad of reasons. The large companies are what they are, and you cannot apply the same type of thinking to their problems as if y…

Yes, many large companies seek technological solutions to political problems. I've worked for dysfunctional organizations; they want technology to provide the decisions bottom-up because, for whatever reason, nobody wants to make any hard calls. These projects fail because you simply can't have success that way. If this is a political and organizational problem, then this choice of technology is entirely not about th…

I wouldn't class this as political problems. Is Facebook having a gazillion developers on their app a political problem, or necessary given what they want it to do? How is replicating that for each platform a good solution, in any sense (political or technical)?

Tech companies core competencies are the service or product that they provide. Making it N times for N platforms is a hurdle that doesn't improve on the core, it's a cost of the fragmented market. I'm arguing that it makes perfect sense both technically and politically to focus your vast majority of developers on your core, and only having specialized platform teams were necessary as a cost of doing business. How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch?

Re: Building all of our new mobile apps using React Native

#224

Post by gargs »

ziftface wrote: post #44
gargs wrote: post #34

Translation: we don’t see mobile experiences driving our growth.

Why is that an equivalent statement?

Companies invest in growth areas. Mobile experiences are driven largely by interactive native elements using the latest platform specific API.

Re: Building all of our new mobile apps using React Native

#225

Post by buboard »

newfeatureok wrote: post #7

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…

I m a web fanatic and use only the browser. My other apps are dropbox and skype , a decibel meter and strava, so things that cant exist on the web anyway. I use multiple gmail accounts so webmail is better

Since most content apps use browser links at some point it doesn’t even make sense to e.g. have a twitter app

Now, i wish we could have a better api than web push notifications though

Re: Building all of our new mobile apps using React Native

#226

Post by buboard »

dmix wrote: post #98
jammygit wrote: post #89

Earlier quoted context omitted.

I can’t stand push notifications, I disable them all except for a couple (like signal). They are usually only part of the app to manipulate you into using it constantly

What's your point? Do you think you represent most people? Can you not just turn it off? Notifications have fine tuned controls on both iOS and Android with schedule Do Not Disturb features and varying levels of priority (iOS has 3 tiers). Plus per-app controls to disable them from annoying apps, which in newer versions of iOS prompt you before they turn on, making them opt-in. It's essential for communication apps (…

Its true that tons of news sites ask for permission just to spam you, or outright sell notifications to advertisers. I think the web notif channel has already been abused beyond repair. It may be time to redo the concept from scratch

Killer feature for email: add an email header that turns an email to notification. Then email apps would push the notification to the user, bypassing apple’s block. Websites already have the user’s email, so no need for more subscriptions. If gmail implemented this, it might push for adoption

Re: Building all of our new mobile apps using React Native

#227

Post by Androider »

wvenable wrote: post #220
Androider wrote: post #194

Earlier quoted context omitted.

But the question was why large companies use platform abstractions. Because they are large in headcount, by definition. Because the apps are already large. Because they have massive platform specific teams, and they would like not to. Because the teams are geographically spread out, for a myriad of reasons. The large companies are what they are, and you cannot apply the same type of thinking to their problems as if y…

> Because they have massive platform specific teams, and they would like not to. I'm somewhat shocked at the size of some of the mobile app development teams at some of these companies. There's no way they need that many developers. What are 100's of developers doing on a single app for a single platform? How is there enough work for that many people? The overhead must be unbelievable. I can't imagine that adding a p…

The Facebook app is like Microsoft Word. Everyone only uses 20%, but it's a different 20% for each. The app is a hojillion megabytes, and serves literally billions of users. There's features in there that addresses some specific niche in Africa for "only" 50 million users, that some sub-team of a sub-team is tasked with maintaining.

Re: Building all of our new mobile apps using React Native

#228

Post by trevyn »

awinter-py wrote: post #192

low quality of tooling in mobile has been a reality forever and the vendors are not only unwilling to change, they've doubled down on poo-flavored buildsystems that are impossible for the community to fix 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…

>code updating is illegal on the app store

This is not true, the restriction is to “download, install, or execute code which introduces or changes features or functionality of the app.”

(And, of course, internal users & builds can do whatever they want.)

Re: Building all of our new mobile apps using React Native

#229

Post by jollins »

divbzero wrote: post #184
newfeatureok wrote: post #7

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…

As you said yourself though, this was 10 years ago.

Re: Building all of our new mobile apps using React Native

#230

Post by nilkn »

Touche wrote: post #209
Despegar wrote: post #198

Earlier quoted context omitted.

That really just says it all doesn't it? It's basically an admission that the use of cross-platform frameworks is worse for customers/users, but they're going to ignore that to optimize for their own software engineering org.

Right, but it doesn't really optimize for their engineering team either since the only reason to use something like React Native is the ability to do both platforms at once.

Is that not a tremendous optimization for the team? It probably cuts the team size in half (or, seen another way, doubles its size for free), and it unifies of a lot of the mobile and web stacks behind similar languages and tools, which in turn would allow some unification in the hiring and recruiting pipelines.
Post reply on HN