[srameshc]

Start learning. It has never been this easy to learn and build an App. I would certainly recommend Flutter/Dart rather than any JS framework. Since you mentioned Java, I personally think you will find working with Dart comfortable. Flutter is cross platform and now you can also build Web apps, though it is in beta. Flutter makes it easy for developers to play with the design aspect of application development so it will be a great way to get insight and learn a few things. It will be always challenging to outsource if you are not sure about the capabilities or reliability of developer or team you want to work with.

[pcr910303]

As always: quoting my comment[0] about flutter:

> We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch. Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. For example, in macOS Cocoa, textboxes have universal readline-esque keybindings (and is configurable globally) which, as an Emacs user, very, very useful. Most Mac apps use Cocoa as the GUI toolkit, so basically all kinds of apps can benefit these keybindings. Another example of this directly benefiting users is the addition of tabs in macOS Sierra. macOS Sierra added tabs to Cocoa apps, and applications could get the feature without additional modification. I can use tabs in any application, with the same look-and-feel, in all apps. Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!) Adding Flutter or any other UI library that draws everything from scratch is a bad idea.

[0] https://news.ycombinator.com/item?id=20612195

[BoorishBears]

If you want to make a product, use what ever tool is most productive for you.

Unless you're writing an IDE, you're not going to lose users (you care about) over not supporting Emacs bindings.

People will put up with a lot of garbage if your product fills a need. And non-native UI is not even inherently garbage, just sub-optimal (and even that depends on the product)

[saagarjha]

> If you want to make a product, use what ever tool is most productive for you.

If you’re making a product that other people use, I would caution you against putting their needs on the back burner. It’s very often the case that what’s easier for the developer ends up making a worse product for the people that have to use it.

> Unless you're writing an IDE, you're not going to lose users (you care about) over not supporting Emacs bindings.

No, the whole point of this feature is that it works outside of an IDE. I don’t even use Emacs and these shortcuts are so ingrained in me that I ended up setting up custom shortcuts to emulate this in the places that wouldn’t support it (where possible, of course…).

[BoorishBears]

I don't see how a comment calling out the fact the most important thing your product should do is "fill a need" is claiming you should put their needs on the back burner.

Unless you mean some of their needs.

In which case yes, that's my point. If you want a successful product, prioritizing features is very important, and in most contexts, filling your "core need" is going to add a lot more value than a native UI does.

>I don’t even use Emacs and these shortcuts are so ingrained in me that I ended up setting up custom shortcuts to emulate this in the places that wouldn’t support it (where possible, of course…).

Unless your tool is for a space where a lot of users are going to say stuff like this is a major detractor for your new product (...like an IDE or other developer tool) you're much better off just making your product and validating it.

-

When you're making a new product, and bootstrapping it like OP describes, your currency is time.

Time isn't just money, it's a changing market, it's your own motivation coming and going, your overall situation can change and make working on it untenable.

The less time you spend fighting a lack of knowledge the better.

A working MVP in Xamarin.Forms in a few weeks > months spent killing the moment for your idea and learning enough iOS and Android to have the base knowledge for a middle of the road native app, is true much more often than people like to admit.

[pcr910303]

Well, just Emacs bindings are not the point; it’s that non-native widgets don’t respect the user’s intent of customizing the whole OS. Let’s take another example: macOS supports Dark Mode from Mojave... and Electron apps usually don’t implement them, or if they do: with a separate toggle.

Yeah, these aren’t great deals, but people who care enough try to switch to alternatives. And by using native UIs, you can mitigate your concerns about whether you implemented everything the user expects or not.

[listenallyall]

The most popular apps in the world -- Facebook, Instagram, Twitter, Uber, Line, Airbnb, Snapchat, many many more -- all use completely custom UIs focused on consistentcy across platforms, which they accomplish by purposely not following any individual platform's specs or using platform widgets.

[pcr910303]

Yeah, and they are successful (mostly due to networking effects — all of the apps you’re mentioning have strong network effects) in spite of their app quality.

The Facebook app is criticized everywhere, I can’t think of anyone who likes their app.

AFAIK AirBnB once used RN but moved to native development, and Twitter use native widgets.

Also, don’t forget that they have the resources to develop all of the expected features of native widgets, for example Accessibility. The OP probably doesn’t.

And, this is all talking about RN which is actually half native since they use native widgets; Flutter is much worse than this because they draw their own widgets.

[listenallyall]

>> don’t forget that they have the resources to develop all of the expected features

You're talking out of both sides. The OP is obviously limited on resources. That's the exact reason flutter is a good option, he gets an app that works on iOS and Android in one codebase using a modern language. Going native requires 2 distinct code bases, which itself requires learning all the specific quirks and features of each platform. Android adapters and fragments, XML layout, distinct libraries for simple Http calls, object serializers, etc, etc. The only downside you can point to is "its not native" and guess what, see above, users don't really care.

[rohansingh]

> Yeah, and they are successful (mostly due to networking effects — all of the apps you’re mentioning have strong network effects) in spite of their app quality.

That seems to live up with what was said further up the thread:

> People will put up with a lot of garbage if your product fills a need. And non-native UI is not even inherently garbage, just sub-optimal (and even that depends on the product)

[jurip]

They also have dozens of developers working on their apps.

[listenallyall]

And the OP doesn't, which is why a cross-platform toolset like flutter is a great option in his case.

[on_and_off]

A mobile example : I know a company that decided to scrape their crossplatform codebase (I can't remember if it was flutter, RN, or whatever else).

They had the opportunity to be promoted as app of the day by Apple, which would have been awesome for them.

Unfortunately the condition was to ship an apple watch integration. The sdk they were using did not support it.

[on_and_off]

You just have to know that all cross platform toolkits come with lots of drawbacks.

Maybe you can live with them, maybe not, it depends a lot on the usecase.

[rohansingh]

As someone in a similar position as the OP, I definitely recommend Flutter. I'm working on a new hardware startup, and my team has strong backed and infra experience.

That jives well with our product, but we do also need a mobile app to interface with the product. Flutter has been great in this regard. Dart and the declarative UX framework are very grokkable for backend folks.

The UI/UX is definitely good enough. Our app feels native, is snappy enough to get the job done, and looks way better than the native Android app we were trying to build before. Even if we were to have to go fully native down the road, Flutter is just the right tool for the job of getting us off the ground.

For a small team, there's just no way we could build both an iOS and Android app separately, on top of hardware, firmware, and a backend. It would kill us before we ever even launched.

[saagarjha]

> The UI/UX is definitely good enough. Our app feels native, is snappy enough to get the job done

n.b. to you.

[latchkey]

Sure, but they are correct and you're focused on the premature optimization.

I've also built a small flutter app where everything runs snappy and it more than solved the needs with a minimal development time and number of lines of code.

[saagarjha]

If you’re happy and your users are happy with Flutter, go right ahead with it. But please don’t be the all-too-common startup that writes blog posts about their “coding velocity” with Flutter (of course, they can’t afford to hire talent for anything else) while they keep their fingers in their ears as users scream about usability or missing platform functionality.

[latchkey]

My users have no idea it is flutter, that is the best part.

[saagarjha]

Then you’re probably fine :) Do make sure to keep your eye on this, though, just like you might be a bit more regular when checking the performance of a Python application.

[fauigerzigerk]

I agree with starting to learn. But whether or not Flutter is the right choice may depend the app.

Flutter allegedly consumes about twice as much memory as a native app. So I guess it matters who the target audience is and what kind of device specification can be expected.

Disclaimer: I have never written a Flutter app and I'm not sure if the information I have found is still up-to-date.

[la_fayette]

Can you give any sources for twice as much memory argument of flutter compared to native? What do you mean with memory exactly, is resulting binary twice as big or does the flutter app neads twice as much main memory?

[fauigerzigerk]

I was looking for some benchmarks two weeks ago because I find Flutter interesting, and I found two benchmarks showing twice as much RAM usage at runtime (not the app binary) for some simple demo app. I no longer have the link, but I can try to find it.

Edit: What I have also found is that there are plans (or ongoing work) to port Flutter to Apple's Metal framework, which should cut memory usage by a lot on iOS.

Edit 2: Here's one of the benchmarks: https://thoughtbot.com/blog/examining-performance-difference...

[la_fayette]

Hey cool thank you! This is an interessting question how different cross platform approaches compare in terms of performance.

[listenallyall]

>> Flutter allegedly consumes about twice as much memory as a native app.

Would be interesting to benchmark Flutter's memory use vs. the app that was never built because of the lack of time, steep learning curve, boredom, etc, to deliver both iOS and Android natively.

[apl002]

I have never explored Flutter.

Coming from a web background, React Native made the most sense for me. Since I started using it a year ago, I absolutely love it. Great community with constant updates from Facebook, tons of articles/blogs/courses on how to learn it and there hasn't been a single feature Ive wanted to build but couldn't due to some lib restriction

[latchkey]

I'm a backend/web dev and recently built an app with flutter over RN. The reason I picked flutter was more about the component/widgets... flutter has them built in. This allows me to just focus on building features over trying to figure out which things to use with RN.

[apl002]

What kind of components/widgets are you referring to? RN has a lot built in and then there are a good number maintained by the community. As far as custom UI components I know some people use libs like NativeBase but I handroll my own

[bg117]

Flutter is declarative. UI is rendered each time completely. Will it not consume more power? In an increasingly warming world, is it a wise choice to use Flutter?

[swiley]

Dart feels like one of those google things kind of like chromium where the first step in setting up for building it requires (more or less) becoming a google employee.

[latchkey]

I personally downvoted you because this comment just is not helpful.

You don't need to ever 'build' Dart unless you're going to be working on the language itself... and if you are, you might as well be a google employee and get paid for it.

Setup for Flutter development is just a few easy steps.