81–90 of 172 posts
I just want to write Svelte and get native apps out the other end. I know we have SvelteNative but that's not great and is a big abstraction. React here is a bit of a bummer i'm not going to lie.
Earlier quoted context omitted.
FYI I've made a patchset that pretty much allows me to actually use the EAS --local builds offline and without an EAS account, so it's in fact possible, even though they, for obvious reasons (e.g. https://github.com/expo/eas-cli/issues/1606 ), don't encourage it.
Would you mind sharing this? I’ve only used expo for experimental non-production apps so far but it works be great to be able to do this if ever needed. Reading this thread makes me a bit more hesitant about using expo.
My full build process is somewhat more complicated to keep my $HOME clean and remove other impurities, but just these patches should be enough to enable offline building.
Without a doubt, Expo is one of the worst tools I have ever used. 1. I can't get a debug build of the app without using their cloud services. 2. Latest version of Android app to preview Expo apps did not work with latest stable Expo version. 3. Random build errors all the time due to some features being deprecated without being mentioned anywhere. 4. Tries to do too much and breaks quite often
This is the impression I've gotten recently testing their waters. Overall, my take has been to stay away from it unless the app I'm making is simple enough they have templates floating around the web and won't need further tweaking: similar to wordpress, great to have a certain type of app up and running fast but the minute you have to do extensive work on it, you'll wish death on it.
I just want to write Svelte and get native apps out the other end. I know we have SvelteNative but that's not great and is a big abstraction. React here is a bit of a bummer i'm not going to lie.
Why go through that many hoops just to use Svelte over React? They’re so similar, just go with the one with the best bindings to the native platform
As an example, some time ago, it was impossible to implement those iOS large headers that shrink to small once you start scrolling. Even though they were de facto standard in iOS for years already. Also the heavy layering of modals introduced in mostly in iOS 15 were basically impossible. Plus they heavily rely on subtle transitions like the 2nd layer scaling down, moving back and top edge peeking out at the top, so that the user gets a hint where they are in the hierarchy... Not sure if all this stuff works now, but generally Expo & RN were very slow to catch up with iOS and you had to rely a lot on dubious libraries, ending up with messy patchwork.
All these minor details are extremely palpable, even by standard users, and the experience just always feels a bit off.
I used to maintain Detox for iOS when I was at Wix, from 2017 to 2021. We ended up dropping support for Expo for plenty of reasons, some technical, some "political". The people reporting "issues" (more like asking questions) for their Expo apps, usually had very little technical understanding of any of the increasingly thick environment stack (the Expo layer, RN layer, UI framework layer, OS layer). They were basical…
This is at the core of my difficulty with cross-platform frameworks for Android and iOS. Dealing with the first-party stack presents enough problems on its own. Adding more layers to that easily compounds the frustration involved in getting anything done.
Earlier quoted context omitted.
It does. It's possible to make a patchset that lifts this restriction, though. If you're interested, I'd be willing to make it available.
The Expo setup that I use never calls into Expo servers at build time. For OTA updates, I've managed to get my self-hosted Expo update server working too, although I'm not using it at the moment, as its incompatible with the React Native New Architecture (it's the last expo package to lack this support - hopefully they'll add it soon).
My advice these days is to go in one of two directions:
- make a progressive web app. No, it’s not a native experience. But if your priority is cross platform then this is cross platform. Service Workers etc make it a ton more paletable than it was back in the day.
- make native UI and code your business logic in some kind of shared layer (Rust, Go, Kotlin Multiplatform). Native UI has come a long way too, as someone who speaks webdev I find SwiftUI and Jetpack Compose to be very grokkable compared to their predecessors, a lot like React if you squint a little.