Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> and a non-native experience is something like 7 out of 10 good but it's not as bad as 1 out of 10 good

The problem is that when a native app falls short, it stays with the conventions of the platform. When a non-native app falls short, it'll stay with the convention of the framework and likely be confusing or broke for the user.

As an example Adobe Flash was really popular for 10+ years. On all platforms it broke copy/paste, swallowed keystrokes, and ate battery, cpu, and memory. Those things could technically be addressed, but rarely were. Most of the time the website was for a restaurant where I was only interested in the menu, location, or hours.

I don't use any of the apps you cited regularly, but I do often hear complaints about them using excessive battery and memory usage for apps that just do chat and music playback.

I also don't see why it matters if your MVP is built on a cross-platform abstraction? In my experience, I often find details where I have to fight the abstraction to access something exposed in the native API.



> I also don't see why it matters if your MVP is built on a cross-platform abstraction

To reach a larger audience with less dev time/fewer devs?


Reaching a larger audience isn't a minimum viable product. Especially, like I said, if you're fighting with the abstraction to achieve your minimum viable feature set.

Sure, use a library if it papers over deficiencies or adds features your app needs to be viable. That's always a technical debt : developer time call. But, especially with the amount of iteration on the native mobile platforms, I haven't heard of that very often.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: