If only Microsoft had a app development framework designed to allow developing apps for multiple mobile + desktop platforms with as much shared code as possible.

https://dotnet.microsoft.com/apps/xamarin

Yep, we moved away because MS themselves are simply not serious about it.

Cross-platform development is like communism. An unattainable utopia. There's no "magicking-away" the idiosyncrasies of cross-platform development with abstraction layers. It's simpler to use native tools and go for the best each platform has to offer while keeping the L&F UX as similar as possible.

React Native and (arguably) Flutter are going through a golden age right now. Major companies like Tesla, Coinbase, and Shopify have adopted them, and the developer experience has never been better. I'm not sure why it worked now, but didn't work for Xamarin / Ionic, though.

For Xamarin I would answer that with: Flutter and React native are 'light' on the developer: you get instant feedback. Xamarin, at least when we dropped it 2 years ago, was really slow and, besides c# which we will use on the server, hardly pleasant or light. I think these days, the developer needs a smooth experience (once the tons of crap has been installed and set up, which is why I prefer Flutter over react native) so things that are not that will fall over. I think, after that, comes author influence: so if you take that, you get to RN, Flutter, Xamarin, Ionic if you sort them by EasyOfDev,AuthorInfluence.

Popularity means popularity. It doesn't mean utility. There are plenty of dumb things large companies use. OTOH, there are also many unsexy, little-known, ubiquitous technologies essential to certain sectors of the economy.

I've never used it in anger, but I thought Xamarin probably had the most pragmatic approach. Their recommended path was to have a common core of business logic, but to build native UIs for each platform you wanted to support hooked into that logic.

There's a new project called MAUI that also handles desktop: https://github.com/dotnet/maui

It's basically rebranded Xamarin Forms. Outside of bundled Windows apps, Microsoft is going all into web technologies for consumer apps now. Even within bundled Windows apps usage of .net is almost nonexistent. Built in OneDrive client is written in Qt!

It's really sad to me that Xamarin doesn't get more love and adoption.

It's slow, bugged as hell and the result is subpar compared to a real native app... At least it was like that when I tried it (again) 3/5 years ago

My SO just finished a term project that used Xamarin.Forms. Conceptually the framework is perfect then you actually use it and want to off yourself. MAUI, if taken seriously and isn't only a rebrand, could be quite an accomplishment and a great tool.

I'm not sure about the state of Xamarin Forms these days, but back when I worked with it a few years ago even the sample apps had memory leaks on iOS. I agree that conceptually it was amazing, as was Xamarin itself. If Forms doesn't have leaks these days it would definitely be a great way to build cross-platform apps.

This is how MS divided.

I see where you're coming from, but Microsoft already builds an entire office sweet as native apps across 4 of the 5 platforms you enumerated.

Which means they know extremely well what a costly and complex process it is.

I'm not denying that it's a complex or costly process, just lamenting that they don't care enough. Of course, the problem is compounded for me by the fact that at any given moment I end up having 3 different enterprise chat apps open on my work laptop for collaboration with outside parties.

And the result of that knowledge is a worse experience for users. However you frame it, users are losing because MS doesn’t want to shell out the cash for good UX.

Losing, but still buying in.

The users aren’t really, their bosses are, most likely because it gets bundled in a contract with Office and Exchange etc.

Outlook is switching to WebView2-based UI like this soon. As for Excel, here's its PM saying "When you look at the overall allocation of resources on the team, a huge percentage is working on web app improvements" https://twitter.com/jones206/status/1388162347059978243?s=20

But the mac version has never been the same as the Windows version.

Actually the Office team is integration more and more React components in the office programs.

Perhaps the effort/reward they get from office release does not apply to a freemium chat service that’s constantly updating?

Office is special because it's such a cash cow they can afford to make 4 different versions of it.

They don't have feature parity though. For example, power query doesn't work on mac.

I don’t think that connecting the 4 buttons of functionality in 5 frameworks is all that much work, when the bulk of the work is backend. Also, it is a trivially scalable problem, where you can just throw 5x as many people at it.

I get the popularity of electron and other cross-platform tools for small startups, but for Microsoft..

> Also, it is a trivially scalable problem, where you can just throw 5x as many people at it.

Having done exactly this work it's really not as simple as throwing 5x as many people at it.

Though to be clear, I am an advocate of native apps on each platform and am not a fan of "wrap a webview around it" type fake-apps. That said, we need to be honest about level of complexity here.

The problem with maintaining 5x native apps is not just the cost of hiring 5x as many people - as you scale towards more platforms the inter-team coordination overhead increases exponentially.

The complexity of coordinating 4 teams to ship in lockstep on 4 separate platforms isn't double the complexity of 2 teams on 2 platforms.

There are a bunch of intersecting factors here:

- product management has extreme load - new features need to be designed for every supported platform at the same time, increasing complexity in feature definition. Some features aren't possible on some platforms, so that increases scope and complexity of the features as we include fallbacks or exceptions.

- engineering has to happen (roughly) in lockstep with one another. It's not acceptable to ship a new feature only on Windows and not Android - they don't have to launch on the same day, but neither can they launch a year apart. This means you have multiple engineering teams that basically have to move at roughly the same speed, even though they are developing on completely differently platforms.

- underlying platform changes affect your ability to move in lockstep - iOS and Android both have significant yearly updates that create additional testing needs. Both platforms also introduce more significant OS-level features that you want to add support for than the older/more mature platforms like macOS or Windows. This throws another wrench in having your teams progress in unison.

There are real advantages to cross-platform frameworks, even though I dislike them from a UX perspective. In particular I have beef with the use of web views, which while offering incredible consistency between platforms is probably the least CPU/RAM efficient way to do literally anything. A huge part of why computers feel slower than ever is the pervasive use of web views for everything.

I really, really wish we had a better cross-platform solution than a thing with an ill-defined render cycle, bases literally all rendering on an XML-like structure, and has all processing stuck to a single thread on an interpreted language. Yikes.

Thanks for this POW!

Microsoft is a $2T company, I feel like they could afford to do it right.

Regardless of what the financial markets value them at, their resources are proportional to profits, not market cap.

That aside, they also have lots of products and teams and some have more budget and resources than others.

Saving some memory usage in teams for more than double the development costs, is probably an unattractive position for that team. It also makes it hard to keep features consistent across platforms (as it is, teams struggles with that!)

Apparently they favour fucking it up several times.

The market cap doesn't tell you anything about the available resources a company has.

For example... Gamestop's market cap did this recently - https://www.macrotrends.net/stocks/charts/GME/gamestop/marke... - the company doesn't suddenly have more money to spend on projects.

Not a great example since they sold over a billion worth of stock. They do actually have more money now.

Microsoft generates more money than they know what to do with so they return large amounts in dividends and probably stock buybacks (I haven't checked for MSFT specifically, but it's all the rage these days.)

That's essentially the opposite of what GME did.

MSFT dividend yield is nothing to write home about. Less than 1% per year at the moment.

That's mostly because of the stock run-up, I recall it was around 3% late last year.

Balance-sheet aggregation != perfect execution consistency.

- DOS 4.0

- Microsoft Bob

- Windows ME

- Windows Vista

- JScript

- MSJVM

- Zune

- Eliminating all/most easter eggs

https://www.infoworld.com/article/2612971/microsoft-s-13-wor...

You can make many, many mistakes as a giant company, so long as they're not fatal. ;-)

Zune was good.

“Plays for sure” Oops, doesn’t play at all.

How can an organisation start a Web/Desktop project which can never ever be _good_ (not to mention great) and frustrate and annoy its customers all the time? If native is a mess, how is outsourcing the mess to the user justified?

What's the alternative? Be only on one platform? Not viable today. Implement 5 different apps, usually not viable.

The platforms are fragmented and the user pays the costs of that in the end, one way or another.

If you hide it by increasing development costs, the price of the app ( or amount of ads or premium only features) must go up to compensate and the user pays the cost as well.

Edit: downvote all you like, there is still no magical solution.

> What's the alternative? Be only on one platform? Not viable today. Implement 5 different apps, usually not viable.

Why are we pretending in this thread that there aren't any cross-platform toolkits?

Using that is an entirely valid trade-off between "putting a webshit in its window" and "you have to develop 10 separate native apps".

Are you talking Qt? Xamarin?

Those are pretty sucky by comparison to both web and native and they don't feel native.

The problem is not that cross platform toolkits don't exist, it's that they're aren't any good enough.

Also why are we pretending in this thread that it's impossible to write electron or web apps with more reasonable memory usage? Look at vscode.

Electron, as much as I hate to say it, is one of the best options available.

The Qt apps I use are much better than the Electron apps I use.

It must be very hard to write Electron apps with more reasonable memory usage if VS Code is the sole example anyone ever has.

Sublime Text is my reference for reasonable memory usage and performance. VS Code doesn't measure up.

> Why are we pretending in this thread that there aren't any cross-platform toolkits?

I'm not aware of any cross-platform toolkit that works on windows, mac, linux and the web aside from, well, a browser.

> Using that is an entirely valid trade-off between "putting a webshit in its window" and "you have to develop 10 separate native apps".

People don't want to pay the cost of native apps, they want to be able to use apps everywhere and have new features often.

Abstract away the core of the product (data, connectivity etc) behind an internal interpreter, which is the same on all platforms and connects to native UI.

Microsoft easily has the resources to write 5 chat app UIs.

That's a hopelessly simplisitc way of looking at the situation. Every team at Microsoft has different levels of resources, and some would rather spend those resources improving their product rather than writing and maintaining 5 different versions of the frontend part of their product.

That's typically the smart choice.

I really don't care about Microsoft's internal organization or what team has how many resources right now.

We also have Swing in Java which is mature, performant, and works across all our desktop stacks. Mobile UI is different enough that you need to write a different interface anyway.

In other words: outdated, ugly and barely supports modern requirements such as high dpi. Apart from Jetbrains who put in a literal buttload of engineering, there is not a single Java Swing application that is not an absolute PITA to use.

Swing generally looks like the native widgets set. And how is it outdated? It's not like GUI programming has changed much.

I‘m sorry but have you been living under a rock? SwiftUI, UWP and Jetpack Compose are platforms that differ extremely from the way Swing works. Swing on macOS looks like OS X 10.9 (still uses Lucida Grande as the System Font), we’re 5 releases past that. On Windows, it looks like Vista, we’re past that, too, see modern apps such as the Terminal.

I don't think the inversion of control that SwiftUI or Jetpack Compose do on MVC is particularly fundamental. Factoring out the diffing of state when an observer is notified of updates into a single place can be a useful thing to do in certain cases, such as when a bunch of teams are all putting things on the screen and you don't want one of them to screw up the update loop for everyone (thus Facebook's use of React), but it makes the creation of composable views less straightforward, and you end up with the new problem of annotations to try to keep recalculation of the whole UI from being a performance problem. In MVC, a compound view can usually short circuit updates of its child views very naturally when there are no changes needed.

I just opened a couple of Swing programs on macOS. Other than not having dark mode, I couldn't see any major difference. I can't check it on Windows right now.

So, no, I don't live under a rock.

>We already have cross-platfrom UI engines called browsers

Someday we compile to WASM and have UI rendering on top of WebGPU?

It has been discussed but you're right it won't be any time soon:

https://github.com/WebAssembly/design/issues/273

really 6 distinct apps, because building native mac and windows apps doesn't mean you can drop the web version.

Most UI developers I know says that it's "reasonably pleasant", yet the is a shortage of "reasonably good" web developers on the market.

Electron fails to support even the most basic Mac behaviours, every electron app is immediately recognizable and frustrating.

Maybe mac users need to start paying for app instead of complaining about every app that doesn't use "native toolkits" or doesn't "support the most basic Mac behavior'. There's a reason that they don't, it's that mac users that care about this don't pay enough to justify a native app.

When and where it's a priority: creating a solid user-experience takes effort. If a project can't manage that when it matters, then their product or service is also going to suck in so many other ways their users will notice. Then native or not, it won't matter when everyone hates them.

Mac and iOS are relatively-straightforward, aren't terribly different, and share development resources.

Android (Kotlin) doesn't often lead to suicidal ideation.

Windows is meh.

Linux is so-so.

> So electron makes plenty of sense to developers

To mostly front-end developers who don't know much about the world outside of a browser.

> , even although it's an egregious resource hog.

Violating nonfunctional requirements to be usable, performant, and efficient.

> To mostly front-end developers who don't know much about the world outside of a browser.

Just for the record I'm a senior backend developer, who sometimes operates at CTO level in startups, and I suck at front-end development. But still electron makes sense to me. Or react native if it's mobile only.

The state of cross platform development is pretty bad.

It wasn't directed personally. The tendency is for front-end developers (the bulk of developers numerically) to treat software development like RMS does with emacs: everything extends from their perspective without consideration of perspectives or paradigms beyond their own. Embedded, native, real-time/mission-critical/fault-tolerance, resource-constrained, widely-compatible, ASIC/FPGA, and/or production-/shipping-scalable.

Cross-platform development will never be improved by N-times duplicated effort of abstraction layers on-top. The best that could happen is for OS developers to agree on common interfaces like UNIX/The Open Group for low-level operations, but for high-level media, UI, and common native development APIs more integrated than a patchwork of libraries like Qt, LibUV, etc.

I've worked on nuclear reactor simulators in F95, embedded industrial GPS equipment, deadline-oriented ad server meta-mediation, Fortune 500 client-facing consulting, compilers, functional programming projects, and now earn a paycheck doing SRE/PE since it's easy money to fund side-hustles.