Why do business people love cross-platform so much?(pickaframework.com)
pickaframework.com
Why do business people love cross-platform so much?
https://pickaframework.com/articles/cross_platform_boss/
31 comments
Well, it's not the software side that's difficult. Generally, it's the user interaction story that's troublesome. In terms of games, it generally a question of console, mobile, and PC/Mac. In that sense, the size of screen, the controller and/or gamepad versus keyboard/mouse versus touch input. Each will give players different advantages than players on other platforms. It's a bit more difficult to do cross-platform game and keep it consistent, fun and fair - even more so for multi-player online games. If only it were simply a question of just porting the software, then we'd see a lot more of it, IMO.
Also, in regards to cross-platform frameworks and games: it's the additional latency, as well as the overhead (but almost certainly the latency) of any cross-platform compiler/library/framework that kills things. Games are right on the edge of a 12 millisecond per frame boundary (or less!) and every cycle usually counts for games these days (especially on limited mobile processors).
Also, in regards to cross-platform frameworks and games: it's the additional latency, as well as the overhead (but almost certainly the latency) of any cross-platform compiler/library/framework that kills things. Games are right on the edge of a 12 millisecond per frame boundary (or less!) and every cycle usually counts for games these days (especially on limited mobile processors).
> as well as the overhead (but almost certainly the latency) of any cross-platform compiler/library/framework that kills things
You say that, but plenty of games, including twitch shooters, have been successful using Unity and Unreal, both of which support a pretty large number of platforms.
You say that, but plenty of games, including twitch shooters, have been successful using Unity and Unreal, both of which support a pretty large number of platforms.
Sure, but those are both engines - not general purpose frameworks and/or libraries. They're specifically designed for games and game-like programs. Granted, I didn't really make that distinction, so your point stands. However, even if they do solve the latency issue (usually), game balance for cross-platform use is still very much an open game-specific problem.
It also doesn't have the regulatory hurdles of medical devices or aerospace. So that's nice.
Psst…OpenGL ES is deprecated as of iOS 12. So that's one platform you're going to have to drop at some point :(
From the article: "Sign up for my email newsletter and get a free framework decision email course. You'll learn effective ways to research framework pros and cons." It's an ad.
Too many articles like this on HN lately - short, useless, lead to an ad. This looks like SEO crap, outsourced to Mechanical Turk or Upwork.
Too many articles like this on HN lately - short, useless, lead to an ad. This looks like SEO crap, outsourced to Mechanical Turk or Upwork.
Yeah, me feel the same. How do people game HN?
I recall seeing an interview with Paul Graham (IIRC), who said that developing web-based software allowed them to sell to Windows using customers without having to develop in Windows.
I think this partly explains the popularity of Javascript, Electron and Web apps among developers.
I think this partly explains the popularity of Javascript, Electron and Web apps among developers.
As a non-businessperson, I don't really like learning to use a program if it can't run on a Raspberry Pi/Chromebook/etc.
It seems too fragile to be worth investing too much time in; what are the chances I'll still be able to use it in a decade or two?
Web apps are a blessing in that regard, but OSS is still better and some companies do actually build their products for architectures other than x86.
While I'm on the subject, Eclipse versions later than 4.0 aren't built for ARM cores. What's up with that?
It seems too fragile to be worth investing too much time in; what are the chances I'll still be able to use it in a decade or two?
Web apps are a blessing in that regard, but OSS is still better and some companies do actually build their products for architectures other than x86.
While I'm on the subject, Eclipse versions later than 4.0 aren't built for ARM cores. What's up with that?
Yeah for most business web apps are great. Got a browser? There's a good chance we've got most of the work done and maybe we need to tweak some UI for your funky device, but otherwise you're ready to go.
Same can be asked, why do some like lock-in so much that they avoid cross platform development?
The important parts of your business are in the backend, and should be accessible in json format. If you have a good api, developing native clients should be simple and fast.
But what I have seen are very confident web frontend devs (and product managers too) who only consider web solutions, and dismiss native apps as being duplicated work.
But what I have seen are very confident web frontend devs (and product managers too) who only consider web solutions, and dismiss native apps as being duplicated work.
The important parts of your business are in the backend, and should be accessible in json format.
In my experience the backend of most non-tech and some tech businesses is a database and some trivial validation rules. Everything important is in the design of how the data is displayed on the front end.
In my experience the backend of most non-tech and some tech businesses is a database and some trivial validation rules. Everything important is in the design of how the data is displayed on the front end.
IME a lot of data display is backend, that's why data gets joined, aggregated, enriched, etc. The front end just formats the data, into a table, list or whatever the onscreen representation is.
Native development can also be cross platform vs lock-in oriented. Depends on what tools are used.
> and dismiss native apps as being duplicated work.
It's worse than duplicated work, it's duplicated different work.
It's worse than duplicated work, it's duplicated different work.
You got your iOS team, iOS backlog, iOS bugs, iOS build / deploy pipeline, Android team, Android backlog, Android bugs, Android build/deploy pipeline, Web team...
And if you do everything right, both app experiences will be mostly the same.
And if you do everything right, both app experiences will be mostly the same.
"Let's write our line-of-business app in ActiveX, everyone already has IE6 anyways"
Beware: This article reads like it was written by somebody who has never developed a mobile app. Thus, before you go down this road, read below.
- Cross platform does not mean you can share the UI/design. Different mobile platforms require different accordances that users are accomstomed to. So your design and code might have to be different, just as it would be for native.
- Just because you are using a cross platform framework does not mean you sidestep the nuances of the framework itself or that of the host platform. In fact, it just makes things worse because you have to code around these nuances. Due to the underlying way iOS/Android work (e.g. permissions or the differences between Android’s activities or UIViewController on iOS), you will still need a fair amount of platform specific code.
- Many cross platform frameworks have limited support for other libraries and if not you need to go native to support them. At this point you may as well be developing natively.
- The performance can matter quite a bit. However, unlike native your ability to do anything to resolve these issues is extremely limited. Maybe it doesn’t matter a ton depending on the use case, but people do notice. Only being able to solve it by dropping into native sort of defeats the purpose of cross platform.
When you add all these up, the benefits of cross platform get very muddled.
It is far better to prove out your app on one platform, get users, solve problems, and when you have more resources and a good process, go to other platforms. If you don’t succeed on one platform, not being cross-platform would be an unlikely reason.
In the case of React Native, it is possible to have a hybrid, which may let you get around some trade offs.
- Cross platform does not mean you can share the UI/design. Different mobile platforms require different accordances that users are accomstomed to. So your design and code might have to be different, just as it would be for native.
- Just because you are using a cross platform framework does not mean you sidestep the nuances of the framework itself or that of the host platform. In fact, it just makes things worse because you have to code around these nuances. Due to the underlying way iOS/Android work (e.g. permissions or the differences between Android’s activities or UIViewController on iOS), you will still need a fair amount of platform specific code.
- Many cross platform frameworks have limited support for other libraries and if not you need to go native to support them. At this point you may as well be developing natively.
- The performance can matter quite a bit. However, unlike native your ability to do anything to resolve these issues is extremely limited. Maybe it doesn’t matter a ton depending on the use case, but people do notice. Only being able to solve it by dropping into native sort of defeats the purpose of cross platform.
When you add all these up, the benefits of cross platform get very muddled.
It is far better to prove out your app on one platform, get users, solve problems, and when you have more resources and a good process, go to other platforms. If you don’t succeed on one platform, not being cross-platform would be an unlikely reason.
In the case of React Native, it is possible to have a hybrid, which may let you get around some trade offs.
>I would go so far as to say if you are building anything other than a game, performance is not really going to be an issue you’ll run into.
My experience is the opposite. Every application that's more complex than a guitar tuner starts to lag after it's been open for too long or when I'm viewing too many resources at once: Web browsers, website-specific browsers (e.g. reddit clients), mail clients, IM apps like telegram, etc.
Responsiveness is one of the most important aspects in a mobile app. It makes the difference between getting the job done and wanting to smash my phone with a hammer.
My experience is the opposite. Every application that's more complex than a guitar tuner starts to lag after it's been open for too long or when I'm viewing too many resources at once: Web browsers, website-specific browsers (e.g. reddit clients), mail clients, IM apps like telegram, etc.
Responsiveness is one of the most important aspects in a mobile app. It makes the difference between getting the job done and wanting to smash my phone with a hammer.
Answer lies in the question I believe, non-business users don’t necessarily know the details and like to pick something that’s cross-platform to meet their business objectives. Practically having two different teams in sync needs extreme collaboration between them, often I have seen other extreme when logic and calculations are computed differently by different teams and users of each platforms were given different experiences. For most business apps, cross platform serves well enough. Easy to extend an web developer to build these apps than having to learn different platforms. Web platforms serves well over time. There exists a certain set of problem spaces when native apps are better. Let the needs drive the decision to choose the platform - would be the wiser option. End of the day business pays for these apps. (I am a full stack Dev.)
People love cross-platform because the half-life of app programming knowledge is something like 4 months.
If you take your toes out of app programming for even a year, you're almost completely lost when you come back.
Cross platform means that you don't have to climb two learning curves simultaneously.
If you take your toes out of app programming for even a year, you're almost completely lost when you come back.
Cross platform means that you don't have to climb two learning curves simultaneously.
I'm not sure the premise is correct. It doesn't seem as though this has anything to do with business people or non-business people.
> That being said, if you’re making a game, it probably won’t work in cross-platform.
What? Ever heard of Unity, powering the majority of games out there?
What? Ever heard of Unity, powering the majority of games out there?
In sometime the discussion will be why business people love PWA so much.
They've been sold on shortened time to market.
The author's "business people" is transparently a euphemism for "clueless technologist" but what they actually care about is finance. Specifically, the time value of money and why they don't want to hire another two people to do Android and iOS in addition to the Web.
The marketing message from the cross-platform framework folks was aimed well and hit the mark. "Spend your time and money with us (or our consultants), not your expensive and peculiar developers. Together we'll achieve 3x the results for 1x the cost!"
The author's "business people" is transparently a euphemism for "clueless technologist" but what they actually care about is finance. Specifically, the time value of money and why they don't want to hire another two people to do Android and iOS in addition to the Web.
The marketing message from the cross-platform framework folks was aimed well and hit the mark. "Spend your time and money with us (or our consultants), not your expensive and peculiar developers. Together we'll achieve 3x the results for 1x the cost!"
Because when done correctly (VS Code) it fucking rocks.
I feel like gaming is the easiest thing to do cross-platform since you don't rely on any native UI and OpenGL is pretty similar on different platforms. Unity, Unreal Engine, and many others are designed to target many platforms.