Whatever the merits of this project -- and it does seem to be useful -- they should be a little clearer about the fact that it's not actually part of the "official" svelte framework.
I'm sure they consider it a tribute but it fees a little deceptive that they're cloning the svelte docs look and feel without any kind of "who we are" statement.
Moreover, it was made by one of the folks who brought TypeScript support to Svelte (https://github.com/halfnelson/svelte2tsx), so although it may not be explicitly pushed by the core team, it was still made by a significant core contributor.
I'll note that React is the only web renderer that gives official blessing to a native framework, and that's because it's also the only web renderer that built one themselves rather than leaving it to the community.
I’ve done a couple React Native apps and never again. They’re fine at first but if you let one sit for a few months there is a combinatorial explosion of complexity among shifting incompatibilities of different versions of javascript libraries, the framework, android/iOS versions, build systems, etc. it becomes a nightmare. I’d much rather just learn Kotlin/Swift and have only one ecosystem to maintain.
At the time I used it, it was almost worth it just to use RN for Android even if you did iOS in Swift, just because styling on Android was so hellish ("There must be some non-crazy way to set a default typeface for my app. Right?" LOL wrong; "setting this color on this Material input field must be easy" LOL nope, welcome to Java metaprogramming just to set a goddamn color), the documentation-suggested way to structure apps was so bad that you'd be reaching for other solutions anyway if you valued your sanity (I wanna say Square was at the forefront, here? It was some company like that. Like your best bet was just to find their libraries and blog posts and do exactly what they did, ignore the official docs), and in some cases the native libraries for Google APIs were less-capable than the Javascript ones anyway (Maps was one, I remember—god, what a surprise that was to find out).
But that was like 5 years ago so maybe it's gotten better.
Although I haven't used it, Jetpack Compose exists now, so that and SwiftUI are pretty similar. On a previous project I was contracting on, the CTO managed to bash out a basic Android version of the iOS app I was working on without any Kotlin experience by going through the SwiftUI views one by one and implementing them in Jetpack Compose.
I think most users would prefer an RN app over a Flutter app, especially on iOS, because the RN app will feel much more native because it renders using native views, instead of a Skia framebuffer.
I had bad experiences with it 7 years ago, but really good experiences with it recently. If you stick to native modules managed by expo you'll be in a great place! You can run into dependency hell if you use a random react-native npm module that was last updated 5 years ago.
Maybe it got better but when I was using RN, it felt fine at the first 3 months; then we found out that it is a hell to work with JS and React Native dependency. To the point we needed to forked multiple project to make it worked. And in the end, we still need a considerable native code for our app. It might just be better to start from scratch with native iOS/Android.
I have a mobile app sitting around. Wrote it in 2020ish, Corona year. The mobile app is written in flutter and the server is in Go, you probably know by now where I'm heading with this.
I cannot even express how hellish and nightmare that whole flutter thing is: I'm worried about the engine itself (there were breaking changes in the typing system itself that I'd need to worry about), the libraries and packages to update. And not to even stop at the building (signing) stage with the whole ruby shenanigans that needs to match and work well with xcode.
This is a very weird thing to say when expo is literally one line installation and it does not require you anything to be installed (even XCode) on machine for most projects. It is literally 10x times easier than just writing in Swift.
> It is literally 10x times easier than just writing in Swift.
I feel Swift as a language is a lot more productive than TS/JS personally. I've found things like React Native and Expo etc. more of a liability than a help for businesses that are heavily reliant on mobile.
If you don't need any native plugins other than those provided by Expo Go, then yes.
If you do need other libraries, or add native code yourself, the package system becomes a nightmare. It is NPM packages on top of Cocoapods on top of a XCode/Swift/Objective-C compile process. Only slightly better on Android.
Want to make a change to a library? Good luck getting linking working on your local setup.
Cordova had exactly the same issues. I'm not sure if Ionic Capacitor is better, but this is one area where Flutter is miles ahead.
in 2023 it is a one liner to add native modules, very easy to link via normal cocoapods or gradle, then almost zero configuration.
Flutter is a joke because it reimplements literally what apple intended to perfect - rendering pipeline, a lot of things impossible to make good without using native api.
When it works it's that simple. When it doesn't - perhaps because of some incompatibility between the native model and a recent Expo update, it's hours of debugging through the different layers to figure out what's going on. That's my experience starting a React Native project in 2023.
Flutter has issues with not using native UI, but I've found the package system with native modules to be way simpler and less issues. Unfortunately you're still stuck with Coacoapods though.
If you want to submit it to the app store you'll need to install XCode anyway to build it and submit it. Might as well just start there and have it configured right from the beginning.
No, you do not, you can use a free service by expo that would build in the cloud. Literally requires zero setup. Local build is needed only if you are sensitive to security, but many banks started to use it. Also native plugins became so easy to use it is a joke how simple it is comparing to cocoapods and some cryptic libraries.
Expo's workflow is so perfect comparing to pure native, it is not even comparable. To do iOS development you need: Swift Packages, Cocoapods and XCode at least. Whils in general it is simple, but cocoapods constantly fights with apple and xcode to not crash anything. While expo also uses cocoapods, it is much more stable because you can always just delete a native project and regenerate it from scratch and it will work.
I am not even starting to discuss how complicated is development for Android - literally everything now have 5+ different APIs for a simple things like "please encrypt this string" or "take a photo". React Native and Expo has perfect packages that solves real problems and work with a few keystrokes.
I'm glad it works for you. One thing I've learned from bitter experience is "don't swim upstream". Meaning, you're likely to have problems when you're using tech outside the way it was intended. Apple intends apps to be developed in Swift with XCode, so that's what they support and when they develop new features that's what they have in mind. They don't care about Expo and if they do something that breaks Expo or Flutter or any other third-party service, that's not their problem and they aren't going to do anything about it. Expo et al are always going to be second class citizens to Apple.
Cocoapods are on their way out. I use Swift Package Manager on new projects and it's literally a couple clicks to install whatever package you want. Haven't had any problems yet.
Writing a Windows app, MacOS app, Linux app, iOS app and Android app is a nightmare because of the insanity and divergence of the SDKs.
They could all have a common API with OS-specific extensions - but instead of that, everyone is trying to make their own API. As a result, developers just write everything in electron/WebKit/WebView.
I wish there was an open standard API for writing native desktop/mobile apps that OSes could adhere to (that the EU forces them to adhere to, haha).
Given that GUI applications share a lot of aspects between platforms, I'd love to see an open "Vulcan"-like standard that defines a GUI API for native platforms.
OSes can interpret calls to that API such that the result looks congruent with the platform's design language - while the application code itself remains portable between platforms.
It's really not that hard to define, there's just no willingness to do so from OS vendors as it would erode their efforts to build walls around their platforms
POSIX became a standard because the US government needed software interoperability with their hardware. It wasn't enforced, but you'd miss out on the government contract lottery if you didn't adhere.
If we value competition in the OS space, it would be wise to support an initiative that would make the OS itself unimportant
Really important to note, this isn’t react native, its NativeScript.
The two have some fundamental differences — React Native is complex because the React ecosystem is full of complexity. NativeScripts biggest problem is more ecosystem size.
While I'm a huge Svelte fan, this project hasn't really gotten very much care and attention over the last few years.
Which is honestly fine. React and React Native I think do a much better job of filling the niche of people who want to build native apps with web tech.
That being said, I think with the progress that Safari has made in implementing PWA support, the increased hostility of Apple toward native developers, and browser improvements like WebGPU coming out soon, I really hope that we no longer have to build native apps for like 95% of use cases. The only major hurdle to this is Apple continuing to treat web apps as second class citizens on iOS and only begrudgingly adding APIs to Safari to make good native experiences.
We've been working with Capacitor recently which is the current iteration of webview-to-native. Basically you just build a website and run it through a compile step to output iOS and Android. The ergonomics of the build process and integration with native features is definitely a bit lumpy, but we've been very successful at building an all-in-one codebase that will power web, ios and android with minimal drift.
> The only major hurdle to this is Apple continuing to treat web apps as second class citizens on iOS
If you add a site to iOS' homescreen it automatically becomes a PWA. The best example I found of a site fully leveraging this feature is Cryptee[0]. They talk about the PWA thing here: https://crypt.ee/download
I think it's convoluted relative to a Smart Banner. Smart Banners give users a clear call to action, and they're not buried in a menu somewhere.
It's hard to make this point without linking to a screenshot, but the share menu is incredibly bloated. To get to the add to home screen button a user has to know it's in the share menu (which is just an unlabeled icon), and then scroll past the following menu items:
- An options button (which leads to another menu)
- Air Drop
- Share via text message (with several different contacts listed individually to share with)
I agree it's MUCH better than it used to be (and huge credit to Jen Simmons and her team for making this possible). However Safari APIs are still WAY behind Chrome/Android and I think this is probably intentional to push developers into using the App Store so Apple can collect their 30% tax
My company tried using this a few years ago to build a cross platform app (and hopefully share a lot of code with our svelte web interface). We made a lot of progress in 3-4 months of trying, but we ended up running into too many odd bugs and edge cases that were difficult to debug. We eventually switched to Flutter for the mobile codebase.
No doubt this and nativescript have improved since then, but from my early impressions, I wouldn't have recommended nativescript for anything other than the simplest of interface needs.
Also the old Cordova equivalent and Kivy. Take mobile development and try to shoehorn a browser-based solution (they don't want) into it. Now you've got two problems and not enough expertise available to help.
Did they have JS _AND_ React experience beforehand? Or did they just pick RN because it was the cool thing on the block?
I foundered on my first attempt at an React app (side project) coming from a C,C++,Java and non-React JS background, but the second one(professionally) after I've had exposure to some React got released and an fork of it is still in use today. And the company I work with has 2-5 other apps out for customers using RN/Expo (thanks to the positive experience I had).
We're also strict about using TypeScript though so we're not chasing basic type bugs (since debugging is a tad weaker with RN/Expo even if it's usable if shit the fan only occasionally) and we have plenty of React experience outside of it, biggest "quirks" are often RN/Expo upgrades if we haven't maintained things in a while (the oldest app used a relatively early version of Expo though) or platform specific notification crap (that I've heard is painful regardless of Expo/RN).
Please stop spamming the same link. If you have something you'd like everyone to see, just make it a top-level comment on the submission. And a bit more substantial commentary on why we should visit it would be nice.
It's the basis of their entire product. On top of that they've built cross-platform wrapper for many UI things. And on top of that, they've integrated several toolkits.
They just market it the other way around, which i.m.o. is not helping them with traction. Right now they're always competing with many other products (react native for example), even though they have a very unique product.
I have built many mobile apps in the last years. I always used web technologies rendered inside webviews, using tools like capacitorjs.
Since I am very concerned with user experience, I always considered the perceivable UI rendering performance as highly important. For contemporary smartphones I cannot see any benefit in using tools like react native, flutter, nativescript in contrast to rendering inside a webview.
I think UI libraries like ionic are indistinguishable from native UI components. At least, to the best of my knowledge, there is no real user study, which proves the contrary. So why should one use such cross-platform tools and not use svelte directly with a webview?
I very much doubt Ionic is visually indistinguishable from native UI components, but I'd love to try if you have a good demo link.
My guess is it crosses a "good-enough" threshold for usability, and it feels objective, ex. maybe scroll performance is the same.
I strongly believe users notice things feeling "off" in a way that's either subconcious or hard to communicate, and that's why it matters.
The reason why I use Flutter instead of JS is for a number of reasons beyond perf / native controls. The shortest version is iOS / Safari makes web apps extremely obviously a worse version of a native app.
But I'm picky.
I just upgraded macOS and got a "you must accept new T&C" dialog. Accidentally scrolled on it vertically. It did the rubberband effect showing a white background, and I said to myself: "lo, how the mighty Apple has fallen!"
Because they run JS on main thread while react native tries to minimise it at all costs (only keeping rendering and animations, but not layouts for example).
Tauri Mobile seems far from production-ready, but more importantly, the reason to use something like Svelte Native instead of Tauri Mobile is to avoid web views in favor of a platform-native experience.
Is the goal here to reach a minimum subset of basic Android UI functionality? I don't see any push to try and replicate a MD3 feature-set here for example.
I'm sure they consider it a tribute but it fees a little deceptive that they're cloning the svelte docs look and feel without any kind of "who we are" statement.