Get the top HN stories in your inbox every day.
bearjaws
DecoPerson
I did this and never looked back.
It’s called a “WebView app” and you can get a really good experience on all platforms using them. Just:
- don’t make any crazy decisions on your fundamental UI components, like breadcrumbs, select dropdowns, etc
- add a few platform-specific specialisations to those same components, to make them feel a bit more familiar, such as button styling, or using a self-simplifying back-stack on Android
- test to make sure your webview matches the native browser’s behaviour where it matters. For example, sliding up the view when the keyboard is opened on mobile, navigating back & forth with edge-swipes on iOS, etc
I also went the extra step and got service workers working, for a basic offline experience, and added a native auto network diagnostic tool that runs on app startup and checks “Can reach local network” “Can reach internet (1.1.1.1)” “Can resolve our app’s domain” etc etc, so users can share where it failed to get quicker support. But this is an app for small-to-medium businesses, not consumer-facing, and the HTML5 part is served from the server and cached. I haven’t thought much about what you might need to do additionally for a consumer app, or a local-first app.
adastra22
I have never once experienced a WebView app that I would say had “a really good experience.”
serial_dev
It’s because if a webview app experience is good, you don’t notice it, you only notice if it’s bad.
A while ago saw a blog link on HN that explained how Apple uses it everywhere and we never notice it because they are done well. Of course I can’t find that link now, I summon the HN gods…
creichenbach
I've done it before on a personal project and I was pretty obsessed with user experience. For example, I changed the way buttons work (because they were natively links with Cordova, which trigger upon tap, not "finger lift", like native buttons). Also, implemented some gestures to e.g. switch between pages (tab-style navigation). While not really in line with system UI (wasn't my goal), I think usability is quite decent.
In case you're interested, the app is named "QuickÖV" - not relevant to anyone outside Switzerland, but just for trying it out: https://play.google.com/store/apps/details?id=com.billhillap...
torginus
I have experienced the opposite with Zed, which has its own bespoke UI framework - it behaved somewhat unexpectedly and didn't work exactly how I'm used to an UI to behave giving me this uncanny feeling.
This kinda shows you how much effort and experience goes into getting an UI framework right, and the long tail quirks (of which there are a zillion) matter for UX, and while I appreciate they took on the task of breaking away from the browser, it's understandable why someone wants to ship an app on time and budget goes with a web based solution.
erlend_sh
I use Voyager, a client for Lemmy, on a daily basis and it’s my favorite mobile (iPad) app. Voyager is the spiritual successor to the Apollo client for Reddit.
https://github.com/aeharding/voyager
The app uses Ionic’s Capacitor, which to my rudimentary understanding is the webview-based upgrade of Cordova. I’ve had far fewer issues with this app than the likes of Bluesky (react native) and Discord (I think also react native but not sure).
The webview approach seems to be the only way for a one-person team to feasible provide a cross-platform app with an app-store presence. Another promising alternative to Capacitor is Tauri Mobile which does essentially the same thing, but mobile doesn’t seem to be a high priority for them.
kelvinjps10
Obsidian. In android it's the best markdown editor.
sheepscreek
Well you haven't used the cutting-edge latest breed. Try using Uber in a browser. There's many high-quality apps today where you honestly cannot tell that it's a website running in a browser. There are many many more but I can only think of Uber off the top of my head.
hjort-e
Do you use iOS by any chance? On android I've very noticed performance problems. Even in apps like Discord and Instagram. But Google maps and Duolingo are pretty bad at times for example. So it's not webviews that are the common denominator here
gcanyon
Gathering all the metaphors (I know) here for reference:
- "All toupées look fake. I've never seen one that I couldn't tell was fake." [1]
- All CGI in movies looks fake. It jumps out at me every time I see it."
- All WebView apps suck. Every one I've seen has a bad obviously-web-derived UI.
arcanemachiner
I made a (hobby) project that utilized this strategy (Flutter + wrapped webview app), and it honestly seems like the way to go for my needs.
mesm3
Using webviews on native platforms can look very appealing from a management perspective: a single codebase, simpler coordination, reduced UX overhead, and faster iteration cycles.
However, from the user's side, this approach often results in a buggy, inconsistent experience that lacks the responsiveness and smoothness of a true native app that elusive "snappy" feeling (i know, I hate that word too)
Companies usually choose this route because it's cheaper, but that same "cheap mentality" often seeps into the overall product quality. Corners get cut, bugs get ignored, and long-term maintenance becomes a mess.
From a developer's perspective, it's a nightmare You're essentially expected to deliver on three platforms doing the work of three people for the same $ In theory, any web developer could handle it. In practice, you need to understand all the native platforms just to maintain some basic, stable integrations even with frameworks like React Native.
The result? Maybe 20% of your time goes into actual feature development, 30% into testing, and the remaining 70% into fixing obscure, platform-specific bugs while working overtime under pressure from cost-driven management.
In my experience, developers will do almost anything to avoid dealing with the native parts of this kind of setup those tasks usually get dumped on whoever is most "familiar" with native, because it's such a pain to handle.
And let's not forget QA testing across these hybrid layers is an absolute nightmare as well.
In the end, my view is simple: If a company can't afford dedicated native teams, they probably shouldn't build a native app. (Of course, smaller apps with limited complexity should be fine)
bickeringyokel
This comments spot on. Coming from a guy that used to do mobile professionally as a one man show where the company had multiple apps and multiple stacks. I had the least pain from the ionic stack which I guess is a happy middle ground, but even then there's always some new app store requirement changes to adhere that's almost a full-time job in itself.
sebmellen
Works until you need complex native code for things like automatic image capture assisted by a bounding model.
littlecranky67
There is no reason you can't do that via web. Image capture in a canvas gives you access to the raw image pixmap data.
tiborsaas
Isn't there a high chance your app is going to be rejected from app stores because you use a web view? You can change your whole app completely upon approval.
Or you ship your HTML/JS and not just embed a URL?
hjort-e
It's mostly shipped with the web assets. But yes that would make it very difficult to get approved by Apple. Not by Google though
DecoPerson
Not a problem if you’re deploying using MDM.
lenkite
Do you use some framework for "WebView app" ? Like Tauri, etc ? Or is everything coded from scratch ?
DecoPerson
I just rolled my own. I always find frameworks bring too many “weird errors” that waste my time trying to figure them out. Also, they’re just another thing that needs upgrading eventually, and they love to COMPLETELY change their APIs between each major version. (“FrungisFactory is deprecated! Try the new async-fibre-layout BloopisGrid now before we completely delete that thing that worked perfectly for you!”)
The platforms provide more than enough capability to build basic WebView apps with minimal effort, and usually the DX is good.
simjnd
What is your app? Would love to try it out to get a feel for the experience.
cyberax
That. And specifically, fuck Apple and their prohibition on JITs.
We have a React Native app that shares some code with a webapp, and that needs to do some geometry processing. So we're constantly playing the game of "will it interpret quick enough". Everything works fine in browsers, but in a RN app it often slows down to unusable speeds.
Torn
Could your processing work in a webview? i.e. webgl or webasm or similar and you communicate with it via postMessage. Something like Polygen might help with the scaffolding, but I have not tried it personally
cyberax
No, it's far too brittle. The latency is also terrible. In our case, we had to reimplement some parts in C++ to have reasonable performance.
Razengan
Using apps made with Electron or those so-called "universal" UI frameworks I wish nothing more than for everything to be native.
They always have to give up some basic or hidden conveniences that native controls get for free, so they always feel slightly different and "off" in a weird way which induces a constant vague annoyance while using them, like walking with a little pebble in your shoe, or a sitting in an chair that isn't balanced right.
It's funny how even after 50 years UI still isn't "solved" ..before writing a universal API, we don't even have universal consensus, or at least some kind of standards authority, on how controls should behave.
Hell not even users can’t agree, as would be seen on any comments about this topic, on stuff like whether lists should scroll up when swiping down, or scroll down when swiping up :')
szundi
[dead]
spease
I started with desktop applications, so my go-to for GUI has been Qt, especially QML. It works on Windows / MacOS / Linux as well as iOS and Android. I think there’s now a way to compile QML to webassembly as well. It also has a ton of support classes that are loosely analogous to the various *Kit things supplied on iOS and Android.
The downside is that the core of Qt is in C++, so it’s mostly seen (or used for?) embedded contexts.
I recently used Slint as well, which isn’t anywhere near as mature, but is at least written in Rust and has some type-safety benefits.
SwiftUI is pretty good too, and I wish I got to work on Apple platforms more.
To me, the simplicity of creating a “Button” when you want a button makes more sense, instead of a React component that’s a div styled by layers of CSS and brought to life by JavaScript.
But I’m kind of bummed that I started with that route (well, and writing partial UI systems for game / media engines a few times) because most people learned web apps and the DOM, and it’s made it harder to get the kind of work I identify with.
So it’s hard for me to recommend Qt due to the career implications…but at the same for the projects I’ve worked on, it’s made a smaller amount of work go a longer way with a more native feel than electron apps seem to have.
bob1029
If you still need to wrap a cross-platform web experience in a native container, I really begin to lose the plot. Once you are engaged with the iOS code signing monster, you might as well go all the way into the ecosystem.
To me, the web is the way around the app stores and codesign. I know how to visit HN on my iPhone despite there not being an official native app for it. It can work. The challenge is making it work in your particular case. Fear that the user wont know how to access the product seems to be a primary factor driving hyperbolic takes on how consumer apps must be built. Perhaps a bit of marketing budget (scan this QR code / visit this link) could eliminate a very expensive tech problem. Why fight visibility in the crowded App Store when there are countless other advertising channels you could pour your resources into?
> native code for the native notifications, GPS and healthkit / health connect.
Modern web can address everything here but the HealthKit item. You could consider handling this with a simple companion application that is exclusively about the collection and transfer of the data while respecting user privacy & consent procedures.
exhaze
Push notifications and mental real estate by being “an app” are the primary business reason (based on both statsig experiments I’ve seen across my career as well as some intuition about behavioral psychology regarding the app mental real estate bit).
scosman
I try this every decade. Love the first few months for speed. Then I end up paying the price later when I want to integrate "new OS feature X" or make a system gesture/style/animation feel native.
Lack of swipe for back on iOS is usually the easiest way to tell I'm looking at a web view.
But it's been about a decade so I'm due...
qw
Swipe to go back can be implemented in frontend.
It's been a couple of years since I used it, but I think the Ionic framework has this feature.
hjort-e
Lack of swipe back actually isn't an indicator. Apple doesn't even follow that pattern everywhere
port11
I see some downvotes but you're correct. For example, in the App Store feature cards swipe left only bounces the card, you have to keep swiping to close. Swipe down closes it at once. It's not that far from the usual but has always felt strange to me. This same gesture won't close Home's new accessory card.
seanwilson
> its nearly better to write your business UI 3 times one for each platform.
Anyone have any experience of doing this for a complex and long-life app?
Sounds like a nightmare that would increase friction and decrease development fun by x10 because of the huge overhead and tedium of having to keep your features and tests in sync across platform for every change you want to iterate on, and requiring developers be proficient at multiple stacks.
I get the usual complaints about bad webview implementations, but separate native codebases sounds like a prohibitively enormous tradeoff if most users only perceive the UX as being a little better than a good webview implementation. I feel like I'm missing something that native codebases is suggested as if it's a simple alternative, or this is coming from people that aren't actually involved in this?
skydhash
You don’t do that though. You write your logic in a common languages and then the UI is an external layer you switch with build settings. The thing is, yiur choice is usually c|c++. Or an embedded language like lua. RN has gone the latter route and then extend it further by using React as a DSL for the UI.
seanwilson
> You write your logic in a common languages and then the UI is an external layer
Isn't reimplementing all your UI widgets, views, layouts and interactions for multiple platforms still a ton of work though? I'm not meaning people using things like React frameworks, but the suggestion of sticking to native only.
baduiux
I can share a bit on this one. I’m doing hybrid apps for the last 8 years and stick to Cordova on my day job but also tried Flutter and RN for a bit. As I’ve seen some other comments about the iOS/Android look and feel (swiping gestures, etc.), Ionic (or the Cupertino package in Flutter) is the way to go. Without this, it would be a lot of trouble. However, as the recent iOS 26 update has shown, neither Ionic nor Flutter is going to support the new liquid glass design (yet). Since we never went with “our app must exactly match the (apple) design guides” this is not a problem for us but I’m sure others would love to be able to adapt the new liquid glass style. I also never heard of any app being rejected due to being a hybrid app or not having the correct look and feel. Of course, you might see/feel that it’s not a native app but who cares. Back in the days we even used a OTA plugin (it was a MS plugin, don’t remember the name) to automatically ship new .js/.html files without going through the review process. If I remember correctly Ionic still provides something like this.
When it comes to native stuff it get’s tricky. As always it really depends on the use case of the app. In our case we develop a navigation app using a native SDK to show a map + turn-by-turn nav + offline maps etc. This is probably the most non ideal use case for a hybrid app. We developed a few plugins to share data between js /native to initialize the map etc. However, the idea of sharing business logic is long gone. There’s so much stuff that’s happening natively and each time we implement it on Android, we have to switch to iOS and implement the Swift version of it.
Some others have also mentioned that a single person now has to know three platforms (iOS, android and Cordova (in our case with ionic + angular). This is true and the real downside. I’m quite familiar with iOS and android yet I’d never call myself a native iOS / Android developer. Yet, I’ve to write so much native code regarding permission handling, geolocation, threading (Ui/non-ui) and there’s always a ton to stuff happening from version to version (e.g. 16 KB Page Size on Android, iOS support for rotation the device/adaptive layout on iPadOS, etc). This is where a lot of time is lost. And the time is not only lost there but also with unmaintained outdated community plugins you suddenly need to understand and fix.
nwienert
As a corollary, working with RN quite a lot, we just built an app for a client that was end to end finished and fully approved to both apps in a month, including pretty deep feature work and redesigning multiple screens. It includes the latest liquid glass native UI as well.
RN is a mess to get into, but once you've found a good stack you can really fly. We are working on a starter kit based off our experience that I think should represent the best possible starting point once it's released sometime before the EOY.
maxloh
I recently downloaded the Moodle app and was surprised to find it's powered by Ionic and a webview, which I only realized due to CSS misconfigurations that caused the app to fall back to Serif font for CJK glyphs.
Recent mid-tier phones are powerful enough that webview has a negligible impact on performance.
pzo
Looks in concept very similar to React Native. So now we have React Native, Lynx.js (ByteDance/Tiktok) and Valdi all based on React. I think competition is good for devs. But not sure if any of those will create ecosystem and community big enough and fast enough to React Native.
React Native grew a lot this year and a lot of things got or will be improved and copied from Lynx or Valid:
- 3 modes of compilation (AOT, JIT) from Valdi will be in static hermes (RN) in coming months.
- native binding generation -> RN already have such official generator and also nitro/nitrogen, they also working on Node-API
- executing animation and JS code in different thread (Lynx.js) -> worklet library in RN from swmansion
- tailwindcss support (Lynx) -> uniwind in RN land.
I think Lynx.js maybe have better shot at React Native since they want to support other frameworks instead of only React.
pzo
after small digging they have Full VSCode debugging [0] which is nice. RN have Radon IDE but it's a paid sub. What's interesting Valdi using Hermes (the one from RN) so maybe there is a way to retrofit this to work for RN. Wondering if they did AOT and JIT by themselve or they using static hermes branch or using only hermes in dev mode.
[0] https://github.com/Snapchat/Valdi/blob/main/docs/docs/workfl...
joenot443
I was at Snap during this project’s early days (Screenshop!) and spent a bit of time debugging some stuff directly with Simon. He’s a wonderful engineer and I’m thrilled to see this project out in the open. Congratulations Snap team! Well deserved.
xmprt
I'm surprised Snap of all companies invested in a cross-platform UI framework given how simple their app seems in comparison to more complex ones out there.
And more importantly, Snapchat seems like an app which could highly benefit from tight integration with native features (eg. camera, AR features, notifications, screenshot detection, etc.)
ingenieros
Perhaps for the same reason we got Airbnb of all companies to create Lottie. https://lottie.airbnb.tech/#/
These companies have super talented engineers and can afford to invest in skunkworks projects like these when they can’t find any suitable options in the market.
pols45
More like "super talented engineers" will keep increasing cost of such projects until they get told this stuff doesn't generate revenue/cost cutting is happening, so work more on ad tech, leave or find external free labor("community") to maintain it.
ramraj07
As far as Im concerned, Snapchat is onw of the most complicated apps thats routinely used by hundreds of millions of people. You yourself listed all the features they have. And every one of them is pixel perfect, with insane amounts of time spent perfecting the user experience of every single ome of those features. In fact, the success of Snap could be attributed to how pixel perfect the app is.
And then you call it simple?
Alifatisk
I share your opinion, but I think of the comment above like this. If something thinks your ui "just makes sense" and is dead simple to use, then you know you've perfected it. That is the best compliment you can get.
xmprt
You kind of just proved my point. If they want attention to detail and good performance then writing native is probably better. The simplicity that I was referring to was the number of views that need to be implemented. A cross platform UI framework would help if there were hundreds of views that needed to be built consistently but for the number of views in Snapchat, I think native implementations would probably be faster and cheaper.
As for the "success of Snap could be attributed to how pixel perfect the app is". I think the success of Snap can be attributed to a lot of things. But if you took a look at how unoptimized the Android experience was in 2017 when it was taking off I don't know how you could call it pixel perfect.
FridgeSeal
Snapchat, an app which half-assed picture taking so hard that it did so by simply snapshotting the camera preview, rather than bothering to take an actual photo.
dbbk
They did this so it would be faster. Obviously they didn't do it for the fun of it.
hummusFiend
Definitely one of the cooler projects to watch while I was there. I recall the goal was to open-source it from early on, so I'm glad to see it come to fruition!
stuckinaloop
Same! I've worked with Simon on this and tried (and failed) to port it to web. Truly a smart guy - and congratulations to the rest of the team!
IgorPartola
Would you use this framework for a project today?
daveidol
“Composer” ;)
mholm
I’m not sure I trust snap of all companies to make a good cross platform framework after how terrible their android app has been.
buffet_overflow
I think it’s been changed since, but wow was it weird finding out that instead of taking photos, the Android app used to essentially take a screenshot of the camera view.
kridsdale1
I worked on the camera in Instagram iOS for a while. There at least, there could be a 5,000ms latency delta between the “screen preview” and the actual full quality image asset from the camera DSP in the SOC.
I don’t know a thing about Android camera SDK but I can easily see how this choice was the right balance for performance and quality at the time on old hardware (I’m thinking 2013 or so).
Users didn’t want the full quality at all, they’d never zoom. Zero latency would be far more important for fueling the viral flywheel.
dmix
> Users didn’t want the full quality at all, they’d never zoom.
Dating apps use awful quality versions of the photos you upload too. Seems to be good enough for most people.
greysonp
I worked on the Snapchat Android back in 2017. It's only weird for people who have never had to work with cameras on Android :) Google's done their best to wrangle things with CameraX, but there's basically a bajillion phones out there with different performance and quality characteristics. And Snap is (rightfully) hyper-fixated on the ability to open the app and take a picture as quickly as possible. The trade off they made was a reasonable one at the time.
cosmic_cheese
Things have improved since then, but as I understand it, the technical reason behind that is that it used to be that only the camera viewfinder API was universal between devices. Every manufacturer implemented their cameras differently, and so developers had to write per-model camera handling to take high quality photos and video.
yalok
:) this is exactly how we used to do it even on iOS, back in the days before camera APIs were not made public, but Steve Jobs personally allowed such apps to be published in the iOS App Store (end of 2009) ...
IshKebab
That was the only way to avoid the insane shutter lag that was very common on Android phones at the time. It's called SnapChat not HoldStillForAMinuteChat so it made sense.
Blame Google if you want to blame anyone. They could have mandated maximum shutter lag times (maybe they do now, I don't know).
GaryBluto
I cannot possibly think of something I would want to use less. A Snapchat-developed UI framework where communication is done via Discord sounds like something carefully designed to repulse me.
noitpmeder
Tons of software projects have moved their communities to discord. Not saying it's a great thing, but you're self selecting out of the future.
GaryBluto
If the future is unable to think critically, I'll stay in the past.
nomdep
What would you use instead?
0manrho
Just because everyone is doing it doesn't mean it's a good idea, or that we should just shut up and accept it. That's the non-monied part of how enshittification proliferates: "Well everyone else is doing it!" "It's the future, get with the times and deal with it"
0manrho
I wholeheartedly agree for the same reasons, and I even use discord a lot (for personal/social reasons, not for support/business reasons).
digianarchist
> Valdi is a cross-platform UI framework that delivers native performance without sacrificing developer velocity. Write your UI once in declarative TypeScript, and it compiles directly to native views on iOS, Android, and macOS—no web views, no JavaScript bridges.
maxloh
If you are curious how components' state is handled, they employed the React class components method:
// Import the StatefulComponent
import { StatefulComponent } from 'valdi_core/src/Component';
// ViewModel + State interfaces for component
export interface TimerViewModel { loop: number }
interface TimerState { elapsed: number }
// Component class
export class Timer extends StatefulComponent<TimerViewModel, TimerState> {
// Initialize the state
state = { elapsed: 0 };
// When creating the component, start a periodic logic
private interval?: number;
// Initialize the setInterval that will update state once a second incrementing
// the `elapsed` state value.
onCreate() {
this.interval = setInterval(() => {
// Increment the state to trigger a re-render periodically
const elapsed = this.state.elapsed;
const loop = this.viewModel.loop;
this.setState({ elapsed: (elapsed + 1) % loop });
}, 1000);
}
// When component is removed, make sure to cleanup interval logic
onDestroy() {
if (this.interval) clearInterval(this.interval);
}
// Render visuals will depend both on the state and the view model
onRender() {
<view padding={30} backgroundColor='lightblue'>
<label value={`Time Elapsed: ${this.state.elapsed} seconds`} />;
<label value={`Time Looping every: ${this.viewModel.loop} seconds`} />;
</view>;
}
}
Liquidor
I miss the React class components. No need for 30 different and error prone useFunctions
sheepscreek
I looked at the source code (as an amateur application developer) and boy, is it over-engineered and complex! Then I remember having built a complex Cordova app more than a decade ago, where I had to make C++, JNI and Javascript interop all play nice and this project feels a lot like that. Lots of moving parts. I suppose this is just the way things are when you are targetting such different ecosystems as Android and iOS _natively_, at the lowest level.
As a solo-dev, I realize well that this project isn't for me. This could be a great tool for experienced folks who know what they are doing. I will stick to Tauri and React Native, it does 80% of what I care about with 20% of the effort. Or until someone builds a nice wrapper around this to make it easy to use (and also add targets for x86_64/aarch64 builds).
0manrho
This is a persistent and pervasive problem that I have with nearly any of BigTech's framework/tooling flavor-of-the-month.
Not only are they often overengineered (at least, for the vast majority of people's usecases), but adopting them means you're adopting a consistently moving target who's priorities are chasing whatever trend BigTech has convinced itself is The Next Big Thing(TM) - often reinventing the wheel yet again in the process - whether you're on board or not. Not to mention possibly getting caught up in change-of-licensing issues (eg Terraform switching to BSL/BUSL) or cult-of-personality drama by the maintainers (Wordpress)
There is a place for these frameworks, even beyond their use in the house they were built at and for, but for the vast majority of usecases, they're not merely overcomplicated, but continually changing in their complexity to boot.
hippo22
As an amateur, how can you tell that's it's overly complex? Do you understand what you're even looking at? Or do you feel that you should be able to understand it and anything above your ability to understand is "over engineered?" This seems like the Dunning-Kruger effect more than anything else.
hu3
A rule of thumb I like to use for measuring complecity for interactive visual stuff is to count how many layers there are between an action and the reaction.
For example, when a user clicks a button, how many calls and moving pieces are involved between the click and something happening on the screen as a reaction to that click.
Often it's a good indicator of how deep the rabbit hole goes.
sheepscreek
Basically you nailed it. I am an amateur “application developer” but I have 20+ years of software engineering experience, including many - building complex web applications. The thing I did 15 yrs ago isn’t even something a typical dev would be able to do. So even though it’s not what I have done a lot, I feel I am qualified enough to comment on it.
A bit like - a history teacher (me) commenting on an anthropology paper.
JaggerJo
Just write 2 native UIs in the 2 platform native languages and share a common core written in any language that offers a C like FFI.
How hard could it be?
imiric
I agree, this is the way. To be clear: I'm not a mobile developer, and have only dabbled with it over the years, but I'm generally familiar with the stacks.
If you want to simplify development of a cross-platform app, your work should start by architecting the software in a way that the core business logic is agnostic to the user interfaces. Then your web, mobile, and desktop GUIs, CLI, TUI, API, and any other way a user interacts with your program are simply thin abstractions that call your core components.
The complexity of each UI will inevitably vary, and it might not be possible to offer a consistent experience across platforms or to leverage unique features of each platform without making your core a tangled mess, so this is certainly not "easy" to do in practice, but this approach should avoid the bulk of the work of targetting individual platforms than if you had done it any other way. It should also avoid depending on a 3rd-party framework that may or may not exist a few years down the line.
JaggerJo
Agreed.
One extra clarification: If the quality of your app is business critical you should really use the native UI toolkit to offer the best platform integration and user experience.
If your app is not business critical (you just have to offer it - example: dishwasher app, ..) you might get away with using a cross platform toolkit like flutter or react native. But even then this adds a 3rd party dependency as you mentioned which adds risk.
Writing an App in Swift on iOS is boring. The same thing is true for writing an Android app using Kotlin/Java. This is a good thing. Now your developers can concentrate on shipping great features.
vmsp
I hear this and it makes sense but when I actually go about implementing it, it quickly falls apart.
Most apps are UI, remote requests and maybe some storage. What do you put in the common core? Android does HTTP requests one way. iOS does them another way. You go for the lowest common denominator an implement a third way, using libcurl or something?
Or do you just put business logic in the common core? Is there really that much business logic that doesn't issue requests or access a database?
JaggerJo
Excellent Points, this is where the answer is "it depends".
> What do you put in the common core? Android does HTTP requests one way. iOS does them another way. You go for the lowest common denominator an implement a third way, using libcurl or something?
If it's really functionality that cannot reasonable be shared don't share it.
It's probably more work to maintain bindings to a single API client in the core and fiddle with all the details of not using the native HTTP client implementations that it is to implement the API client twice.
Writing the API client twice is boring, but that's a good thing.
> Or do you just put business logic in the common core? Is there really that much business logic that doesn't issue requests or access a database?
The shared core is optional. You might have the need for it, then it's a good solution.
For an app like snapchat you'd probably share the video effects and have that in your core library.
vmsp
That's perfectly reasonable but, at that point, the argument becomes: build 95% natively and maybe there's a 5% "core" that warrants extracting into a common lib. Technically? That's excellent architecture. In terms of saving development time — which is where stuff like React Native comes in? Not so much.
pedalpete
This is the direction we are going, but at the moment we are doing iOS only, but with the plan of learning the users UX needs in iOS before investing in Android, which is a bit strange because most of our team are on Android, but our users are on iOS.
Every time I see a new project like Valdi, I am hoping for something that is truly magical and cross platform, but I'm always steered away by comments like yours and people saying "you have to do native".
For context, I am a dev, and I've done RN apps in the past.
JaggerJo
To me it's crazy how many people work on these seemingly simple applications.
How many people do you need to build JUST the native Android and iOS app for snapchat?
Is the "single" codebase really worth all the added complexity and additional risk?
I'd always go the native route if the user experience is business critical.
flanbiscuit
With Swift SDK for Android, you can write all of your code logic in Swift for both and only need write the native UI related code for Android and iOS.
IgorPartola
This looks promising. I would love to see more examples of what this can do along with screenshots. As is, there is a single Hello World and the components library is “coming soon”. But if it can deliver what it promises that would be pretty cool. React Native is I think the main popular framework in this space.
a2800276
Unfortunately no Linux, Windows or even HTML targets?
potato-peeler
What does using native view mean? Do they invoke native ui controls instead of drawing their own? Seems similar to boden - https://www.boden.io/
Get the top HN stories in your inbox every day.
Working at a company that uses react-native I wish nothing more than for the end of app stores and differing platform languages.
We're heavily considering just having a website next year with a mobile app using webview, and then native code for the native notifications, GPS and healthkit / health connect.
I feel like AI is changing the equation, its nearly better to write your business UI 3 times one for each platform.