I actually half built a solution where the Flutter engine was running on Xamarin (hence coded in C#), and got a basic hello world app running. It does have the downfall of slower boot times and larger file sizes though.
But I abandoned it because its too big of a project for a one person side project.
This post actually highlights more of XF's downfalls than positives. I've been a big XF developer for years, and XF has many positives but this example just shows that they needed SkiaSharp, Lottie, and native platform code just to get their app out.
Not to mention the need for additional components such as horizontal scroll, carousel view etc.
If you look at Flutter, most of this app could be done with just the Flutter SDK. Haven't really played much with RN, so not sure how that compares.
That's fair, but I think that XF has a good story around integrations with other frameworks to fill its gaps: SkiaSharp has the SkiaSharp.Views.Forms namespace, for instance, and there's solid documentation on integrating the two, right there on Microsoft's Xamarin.Forms docs. Actually, speaking of docs, Charles Petzold's book on XF is an awesome resource -- I've not seen commensurate investments in documentation made by XF's competitors (admittedly it's not something I track that closely). Similarly XF's ability to add a native control directly to a StackLayout via extension methods makes it fairly straightforward to just drop in a native component if that's what you want to do.
I think it's a reasonable strategy to say "hey, we're not going to be able to solve all the problems, and it's probably not the right way to spend our time even if we could. What we will do is make integration with other solutions straightforward so we're not the bottleneck". Making a strategic choice not to be the bottleneck seems like a good call regardless. That said, the things I've found to be a hassle are things like getting OpenGL working on UWP from C# (tractable, but that's really not how I want to be spending my time).
But yeah, wow what a difference it's made having Microsoft throw their resources at it. My current codebase lets me build for iOS, Mac & UWP at present (I'll get to Android at some point), with really not very much effort. Being able to debug on the Mac version rather than waiting for iOS deploys is just about enough to repay the time investment on its own. I'm anxiously awaiting them getting their web platform support up to snuff -- I'd dearly love to never have to JavaScript again. :)
On the other hand this app would work across desktop OSes as well, whereas Flutter not, as it isn't their focus.
Given past experiences, I am sceptical of using languages not part of platform SDKs for production code.
When I do use such third party languages then the eco-system plays a major role in the decision, and for .NET vs a language clinging for survival, the decision is obvious if I care about having the same code in production in the next couple of years.
I understand the need for some apps to work on desktops, but I haven't personally done any of these before. Just iOS and Android, is all clients ever seem to ask me. So of course Flutter wouldn't work well for desktop atm. But FYI: it is being looked at - https://github.com/google/flutter-desktop-embedding Even seen an MS employee contributing to it as well.
As for Dart, its similar to C# in a lot of ways and certainly is gaining traction. I didn't have any difficulty writing Dart code.
Dart might be similar to C# in syntax, it just has like 1% of libraries available to C#, no IDE support at the same level as C# and no commercial value to put on the CV.
When comparing programming languages one always must look beyond grammar and language semantics.
Flutter is trying to be Dart's Rails, it remains to be seen if it will actually accomplish it.
How are pure Ruby projects doing in the market outside plain Rails apps?
The next step in my view is the addition of quality components to the Forms base, and they are doing just that at the moment. I have reviewed and given input for CollectionView, FontIconSource and other specs that are actively being worked on. I saw Miguel demo-ing my input in .NET Conf in the demo Shell app, so they are listening! You did a few stellar Pull Requests yourself, with the Label Spans.
I took them a long time to restructure the project after Jason Smith's leave of absence, but I think David Ortinau is doing a stellar job and the GitHub project is an exemplary open source project. It needs more community involvement, and the F100 stuff you helped drive was very, very good. Next to better components and adding more resources this is another challenge for the project at hand.
I agree it is a bit of a Linux on the Desktop story, "next year", but taken the task at hand (so many platforms), the pace is not that bad. In the mean time I can produce good apps with a few extra libraries, so what...
Its great they seem to be listening to you, they never really listened to me. F100 was brought about because they weren't listening, and the community had to do things they wanted because Xamarin weren't ever getting around to it.
I put a lot of effort into XF, and at the time, it was the best x-plat development environment (for my usage) around. But Flutter has really highlighted its shortcomings and I don't hold much faith that Shell is going to bring it to the front again.
A healthy ecosystem and easy bridging to native isn't a downside at all.
But this article is saying look how awesome XF is at all these pretty animations and functions, which are mostly done by other components or custom native code.
And they aren't quick and easy to implement either. But you then compare it to Flutter, and you could do most of it right off the Flutter SDK.
To me it highlights where XF lacks in a cross platform development. Especially when you think of the knowledge you have to know to bring in to use all these components. ActionScript, Skia, and each platforms native API usage.
The tax breaks for the middle class are only temporary. Most CEO's are praising them because it's great for them and shareholders. Most CEO's acknowledge they will use the additional profits to perform share buy backs.
While the middle class got something, the majority went to the wealthy, and as per my previous comment on shares, they are not going to be flooding it back into the economy.
Also US corporate taxes were about median for the world, they were not absurdly high, you should check out some countries in Europe for that.
See this NPR[1] article which listed the previous US corporate tax rate as the highest of advanced economies. This included France, Belgium, Germany. Also fun fact, go visit Dublin and see all the tech companies (Google, Facebook, Microsoft, etc) who have a Europe HQ there. The reason, they have a 12.5% corporate tax rate.
That is a very bad policy to have though because it encourages wasteful spending on tax avoidance and rewards the companies that do it. It also gives an artificial competitive advantage to the largest companies, who have the scale to invest in complex tax avoidance schemes, at the expense of smaller more productive companies.
If you see the chart just below the first one, the actual tax rate is roughly median with the rest of the world. The CBPP[1] article explains further.
While some countries offer low tax rates or incentives, they are to attract international business because they have no other means to attract them. The US is not like Ireland in this respect.
US companies have had record profits recently. The big tech companies like Apple are hoarding cash reserves. Why is giving them more cash going to change their approach?
This email is completely unverified. Apple certainly has its targets on app generators, but not Xamarin, React Native or other similar technologies, that I have seen. The email contains grammatical errors and has not been received by any other developer, that I know of. It is highly likely to be a fake.
It looks like it mixes true and false information. If it turns out the content is actually genuine, in spite of imperfect English, the underlying meaning could be that Apple will reject template-based apps generated by frameworks mentioned, and not that all apps created by them would be banned. This seems the most logical conclusion. Apple definitely wouldn't disclose such a huge policy change via one small letter to one developer, it makes no sense at all.
Yes, it looks like they took a legitimate email, and added in that line causing all the fuss. That line is what seems out of place, and has the grammatical errors. The fact they mention Trillian also removes the legitimacy. Unless people are creating apps with an old school messaging service?
Great concept. One issue with the dynamically appearing forms is you don't know how long they will go on for. This will lead to people abandoning the form even though they may be 1 step away from completion.
Thats the part that makes PayPal unbearable. As mentioned above I have had questions asked from my merchant provider over transactions but at no point did they freeze my account. They called me, sorted out the issue and my business kept running as usual.
I'm curious because I've heard similar rants about many products that process payments for merchants- Paypal, Amazon Payments, Google Checkout, etc.. I'm interested how your provider is able to circumvent all this red-tape that larger companies seem to have.
My merchant provider is with my local bank. If you deal with a bank it suprisingly much nicer than dealing with merchants such as Amazon, Google or PayPal
I would just recommend getting a payment gateway and merchant account. I am with eWay which only costs $350 per year + 50 cents per transaction. My merchant account costs a bit less per year plus a percentage of the transaction which is less than 50% of PayPal's transaction charge.
It takes longer to setup and I wouldn't really recommend them for micro businesses but they are certainly great for small businesses.
But I abandoned it because its too big of a project for a one person side project.