It is definitely a bit of a pain to use and I have had issues with the bikes not being maintained. That being said its relatively easy to just switch to another one.
Much bigger problem in my opinion is that while the Metro lines are rapidly expanding they have very poor bicycle support. There is almost no space for bicycles and even on the cars that do have space it very quickly gets taken up by other people.
This app is super buggy. The UX has so many glitches (engineering failures).
Probably the biggest UX snafu that I found is that one can unlock a bike across town by mistake and then get billed $2000 for it getting lost/stolen. Take what Lyft did and copy that.
This is an app that is used by a lot of tourists - many of whom have minimal English skills. The UX failures are embarrassing. Whoever did this should be held responsible for breaking their SLA.
It feels like the whole thing was built by an intern over the course of one summer. Realistically, the city is probably paying an uncompetitive wage in a very competitive market and thus hiring less-than-competent engineers to service millions and millions of people.
What makes app developers so special? The only extra requirement is that you don't break the rules of Apple/Google's sandbox play area, else you can release whatever garbage you want.
Typically native development environments offer platform specific capabilities. Using a cross platform tool means you are not taking full advantage of what a platform offers to make an experience shine.
But the real problem is that organizations that trade quality for cost/development time at the architectural level also typically sacrifice quality at every other level. This means that cross platform apps come away with a reputation for being low quality products.
You are overstating the value of ‘native’ development and understating the cost of developing natively on multiple platforms. What capabilities are exclusive to native apps in the minimal well defined sandbox provided on portable devices?
You are generalising about attitudes of businesses who are concerned with return on investment, an obvious priority that I shouldn’t have to point out.
The reputation you mention is just an opinion based on inherent bias not shared by all. If you were to choose at random 10 reasonably well performing apps on the store you could in no way tell if they were developed ‘natively’ or not.
React native is compiled into native code, by definition it is ‘native’. It is not running in a virtual box or a web browser.
This is disingenuous. There is JavaScript interpreted at runtime produced by the metro bundler, and the UI latency is palpable. Animations still suck and threading is painful.
I’ve been involved in several react-native projects at FAANG because senior leadership bought into the misguided belief that cross-platform is cheaper and faster than fully native. Every project was eventually scrapped and re-built natively because the app became too slow, unwieldy, bloated, and impossible to maintain usually because of the dumpster fire burning inside node_modules. On iOS, You will have to know how to use clang and llvm when things eventually go sideways, and few (if any) js devs have that expertise.
And have you ever experienced a react-native upgrade? It’s a thing of nightmares, typically taking between two and four weeks with all hands on deck.
The same product can be built twice on each platform with half as many devs, will be better maintained, and always perform better. React-native is great for quick prototypes or a temporary MVP, but for everything else it’s a house of cards.
I’ve been an iOS developper for 8 years (working on apps with millions of downloads, for a French company).
I’ve been fighting management constantly about this, explaining that it would be cheaper to have iOS and Android experts ratherg than « multiplatform » developers. For instance, on iOS side, frameworks and UI change a lot every years, so you want to be able to update your apps quickly and adopt the new best practices (which is easier if you stick to the standard UI without any other framework).
We had other projects that started with a multiplatform approach, to go back after sometimes on « real » native apps (by real, I mean using only standard SDK, UIKit on iOS for instance). Despite these failures, management keep pushing for technology like React Native, Xamarin etc…
I’ve lost this battle: I think that the idea to have half devs is to appealing to business, and you don’t have chance to explain why this is not as simple as it’s seems to be. Or my points were simply not convincing.
UI latency is palpable, so palpable that the millions of people who use apps developed in react native wouldn't notice the difference or care. node_modules is such a dumpster fire that it's the most popular package manager in existence.
React native is for prototypes although it’s used in both the public and private sector to deliver apps. You can make 2 versions of an app in half the time apparently just by saying so.
Somewhere reality disappeared in your argument. Your employment history is of no concern to me.
>dumpster fire burning inside node_modules.
This made me laugh a bit.
I agree with everything you said, I have React Native projects that will never run again. The node ecosystem is still an unstable mess, everything is largely hacked together.
I do use Flutter for my side projects, and it appears to be gaining popularity. It feels like a much better React Native since you don't have 20 years of legacy JavaScript code running in the background.
as crappy as the app is, using a tap card on subscription usually works like a charm (although bike return doesn’t always register perfectly, creating overbilling issues that customer service does resolve for you).
It would be nice if these were built with public APIs so that alternative chromes could be built around those. But the same factors that make the apps shitty make the APIs shitty, I suppose.
> In an ideal world, where things work like standard tech that already exists, I would attach a credit card, walk up to a bike, and get automatically charged for unlocking it/riding it. I'm trying to give you my money, Los Angeles!
For the same reason any other business offers a discount for buying in advance / in bulk: "Revenue today" is more valuable to a seller than "a little revenue today, and maybe a little more at a later date".
It's buggy and doesn't work well because people who have no idea how software works are in charge of managing software projects. There's a good book titled "Power to the public" that goes into this phenomenon in-depth and explains why most government software projects end up being dumpster fires.
I haven’t verified this but I have a colleague that works in a different province than mine who said the government planned to create an app for snow something or other and it was in production for years and finally released a buggy mess and some college kid came along and recreated it in a weekend with glowing success.
The app is buggy (sometimes I have to reopen it over and over to get bikes to show up), but procedurally I actually like it more than other bikeshares I've used. No need to futz around with QR codes or do a wacky challenge-response routine with the docking station. I just tell the app which bike I want to unlock (based on its parking spot), and it happens.
19 comments
[ 2.6 ms ] story [ 49.4 ms ] threadMuch bigger problem in my opinion is that while the Metro lines are rapidly expanding they have very poor bicycle support. There is almost no space for bicycles and even on the cars that do have space it very quickly gets taken up by other people.
Probably the biggest UX snafu that I found is that one can unlock a bike across town by mistake and then get billed $2000 for it getting lost/stolen. Take what Lyft did and copy that.
This is an app that is used by a lot of tourists - many of whom have minimal English skills. The UX failures are embarrassing. Whoever did this should be held responsible for breaking their SLA.
React Native says web developers are automatically highly qualified app developers.
But the real problem is that organizations that trade quality for cost/development time at the architectural level also typically sacrifice quality at every other level. This means that cross platform apps come away with a reputation for being low quality products.
You are generalising about attitudes of businesses who are concerned with return on investment, an obvious priority that I shouldn’t have to point out.
The reputation you mention is just an opinion based on inherent bias not shared by all. If you were to choose at random 10 reasonably well performing apps on the store you could in no way tell if they were developed ‘natively’ or not.
React native is compiled into native code, by definition it is ‘native’. It is not running in a virtual box or a web browser.
I’ve been involved in several react-native projects at FAANG because senior leadership bought into the misguided belief that cross-platform is cheaper and faster than fully native. Every project was eventually scrapped and re-built natively because the app became too slow, unwieldy, bloated, and impossible to maintain usually because of the dumpster fire burning inside node_modules. On iOS, You will have to know how to use clang and llvm when things eventually go sideways, and few (if any) js devs have that expertise.
And have you ever experienced a react-native upgrade? It’s a thing of nightmares, typically taking between two and four weeks with all hands on deck.
The same product can be built twice on each platform with half as many devs, will be better maintained, and always perform better. React-native is great for quick prototypes or a temporary MVP, but for everything else it’s a house of cards.
I’ve been an iOS developper for 8 years (working on apps with millions of downloads, for a French company).
I’ve been fighting management constantly about this, explaining that it would be cheaper to have iOS and Android experts ratherg than « multiplatform » developers. For instance, on iOS side, frameworks and UI change a lot every years, so you want to be able to update your apps quickly and adopt the new best practices (which is easier if you stick to the standard UI without any other framework).
We had other projects that started with a multiplatform approach, to go back after sometimes on « real » native apps (by real, I mean using only standard SDK, UIKit on iOS for instance). Despite these failures, management keep pushing for technology like React Native, Xamarin etc…
I’ve lost this battle: I think that the idea to have half devs is to appealing to business, and you don’t have chance to explain why this is not as simple as it’s seems to be. Or my points were simply not convincing.
React native is for prototypes although it’s used in both the public and private sector to deliver apps. You can make 2 versions of an app in half the time apparently just by saying so.
Somewhere reality disappeared in your argument. Your employment history is of no concern to me.
I agree with everything you said, I have React Native projects that will never run again. The node ecosystem is still an unstable mess, everything is largely hacked together.
I do use Flutter for my side projects, and it appears to be gaining popularity. It feels like a much better React Native since you don't have 20 years of legacy JavaScript code running in the background.
https://flutter.dev/showcase
> In an ideal world, where things work like standard tech that already exists, I would attach a credit card, walk up to a bike, and get automatically charged for unlocking it/riding it. I'm trying to give you my money, Los Angeles!
For the same reason any other business offers a discount for buying in advance / in bulk: "Revenue today" is more valuable to a seller than "a little revenue today, and maybe a little more at a later date".