We definitely don't intend to push you into Material... can you elaborate on that? What would we have to change for you to think we were not pushing you into Material?

Regarding the crash logs, it has definitely helped us improve stability. We do try hard to notify you that it's happening. It's opt-out because people don't tend to opt in to that kind of thing and so the data would be more or less useless (not representative of real usage) if we made it opt-in.

Sorry for the delay in response, I didn't see this. I think the problem is kind of endemic -- it's kind of like all the documentation and everything always starts from a Material component. Like if you look at provided scaffolds and you see CupertinoScaffold in the Widget Index[0], you might expect MaterialScaffold to be an option as well, but it's just "Scaffold". Little things like this indicate that you expect "MaterialScaffold" to be the default resting state. 99% of the time when I'm writing an app I have the design already and it may or may not be in material style or Cupertino style -- I personally would expect a framework to offer general tools first then the specializations. There are a bunch of other example of components that only really work correctly in the Material context. It's not a huge thing, and Google does have a pony in the race (which makes it easier for me to tinfoilhat about it), you have every right to push material as the default/make it easier to work with -- but I enjoy not having any such bias with Nativescript, even if it costs me slightly more work to get components that are stylistically coherent with either paradigm.

From an engineering standpoint I absolutely understand the automatic crash logging, it's good that you're able to get the user data. I think you guys are just fine as I'm more tinfoil-hatty than 99% of the usual developer will ever be -- the average developer won't care. I don't know realistically how it could be improved without sacrificing that useful data, but maybe a notice @ install time? I just never saw any mention (I read through the docs, watched lots of video), and was surprised -- maybe the negative impression was amplified because I was having issues with flutter at the time. My thought/reaction at the time was that "Oh so a weird crash and you're sending the details back without me explicitly allowing it? classic google".

To wrap this up, I do want to thank you (I'm assuming you're on the flutter team) for the hard work -- drawing every pixel and building a composable, considered system to do that is very hard, and you've expanded the mobile development landscape, Flutter is unique in it's approach AFAIK, and I mention it any time I talk about the mobile dev continuum. Building flexibly to support multiple embedders is awesome and I'm sure flutter will go far.

[0]: https://flutter.io/docs/reference/widgets

It's always interesting to hear about lesser-known cross-platform solutions. Why do you think Nativescript never got the buzz that React Native, Flutter, Xamarin, or web-focused efforts like Ionic, have?

tl;dr - Progress (the company that sponsors Nativescript) doesn't the market/advertising dollars compared to Facebook/React, and Google/Flutter or MS/Xamarin.

Well I think the biggest difference is purchasing power of the companies behind those other solutions in terms of marketing. Flutter has gotten this the most right, so far -- they make very published developer resources, and market aggressively, they have things like the Flutter Development Show[0], and little 30 second clips introducing parts of the platform[1] . It's a good thing (they're innovating in the documentation/dev experience space), but taken cynically it's just a marketing ploy.

I hate to say it, but lately people have been applying the same advertising and marketing logic they use on consumers on developers rather than necessarily making the best product they can and letting word spread organically. It's a bit of a chicken and egg problem -- you usually can only build the best product with help from others, which means getting in front of them, but usually you want to make a good thing so you can justify getting in front of the developers in the first place... So people put out shitty tools, then just iterate after the community shows up and finds out there are lots of rough edges (see: mongo, react, dart, etc).

The last I'll say on the subject is that "developer evangelists" are basically paid marketers/advertisers.

Nativescript also has this thing where it was popular years ago, but has recently seen a surge in popularity -- you have projects like nativescript-exit[2] (which provides a cross platform way to exit the app from JS) that have code from 2 years ago. This is actually a really great point for nativescript, because solidly written plugins like nativescript-exit really are solid -- I very recently used it in a project and it just worked. The integration points available in Nativescript have a very high potential (not to say other platforms don't).

[0]: https://www.youtube.com/playlist?list=PLOU2XLYxmsIK0r_D-zWcm...

[1]: https://www.youtube.com/watch?v=R9C5KMJKluE

[2]: https://github.com/dvabuzyarov/nativescript-exit

NativeScript really? i had enough of XML in the last 20 years, it's also Telerik, well it's enough of that as well. I really like Fluter's new mindset.

lots of grammatical errors in this comment... but this one was the worst:

"lacks almost none of the advances" -> "lacks almost all the advances" (I was talking about the typing stuff...)

Apologies for the repeating of several points... This comment is pretty badly written and I can't edit it now.