261–270 of 298 posts
Earlier quoted context omitted.
And not just off-line, but as we learned last week, if us–east-1 is down you have spotty connectivity, not hard down, and your device needs to not cook your users; literally in the case of Sleep8.
We've really hit a strange level of dystopia when your bed doesn't work because a server is down
Earlier quoted context omitted.
Flutter has a long-standing issue where every interaction is subject to a 1-frame delay on iOS (P2 since 2022)… https://github.com/flutter/flutter/issues/110431 Not to mention the stuff with shader compilation lag
Sure you can find some issues if you look at it hard enough. In the real world scenario, it's very possible to ship a performant, functional app in Flutter and has been for some time now. It also brings some of the best development experiences with Dart, consistent declarative paradigm & hot reload. Like all things, it's a trade off, for me it's very hard to merit maintaining 2x native apps. There are many, many peop…
Flutter apps on iOS just do not feel native, that’s a fact. It doesn’t mean you’re a bad person for using Flutter.
Earlier quoted context omitted.
The issue with that approach is that the state of the art for iOS dev is about 15 years behind the state of the art for Android dev. The amount of simple things that are incredibly painful for iOS devs to do is astounding. Some of that is because xcode is horrific, some of it is that the ecosystem is starved by disinvestment from Apple. I've talked with colleagues in several companies and the story is always the same…
Exact opposite experience :)
Earlier quoted context omitted.
I’m curious to hear where you think this is a showstopper. I’ve been testing some Flutter apps lately and other than some mismatches in platform UI elements they have been smooth. I wonder what you would think of apps like Kagi News.
I don’t mean to say it’s a showstopper, but it is certainly noticeable to anyone accustomed to using iOS devices. I suspect the situation on Android is better where Google has access to the native platform code. Flutter has a secondary problem which is (IMO) a dearth of well-made libraries and showcase apps. Most everything feels half-baked. The Kagi News app, which I have just installed, doesn’t seem to fall into th…
The most important question for every cross platform framework is what happens to the UI? Adobe products (both the Creative Suite, and their Flex Builder environment for Flash app) had their own design system that felt foreign on every platform it shipped on. If you wanted something that felt native, you had to reimplement e.g. Apple Aqua in Flash yourself. Flutter goes out of its way to do that work for you, aiming…
It's worth noting that this doesn't add any expectations for how your UI is built. The example shown in the screenshot continues to use Jetpack Compose (Android's native UI) with Kotlin invoking Swift business logic. You can also use other UI frameworks on Android, of course, including some that are written in Swift. One nice thing about this implementation is that it shares many of the same characteristics as Swift…
- TypeScript: we have a few million lines already, but it runs poorly on Android midrange devices.
- Rust: very efficient on Android / iOS but on web there’s very expensive memcopy between WASM memory and JS. Safe but hard to write and refactor casually. Would be great for server perf tho. Async has many footgun for our JS devs. Biggest long term downside: borrow checker speed limit on developer velocity for business logic.
- Kotlin: can target JS directly avoiding bridge cost. iOS devs are uneasy about it. Async story is extremely confusing. Biggest long term downside: how Byzantine the JVM ecosystem is on the server.
Until I saw this Swift wasn’t really in the running. I need to explore the web target situation. Swift is maturing but still weak in ecosystem on non-Apple platform compared to other options. Still swift is moving towards a great combo of speed + safety + usability.
Biggest long term downside: type inference pain. Swift is the only language I’ve used that will tell me “the types seem wrong / ambiguous, but the compiler has no idea what your specific mistake is” and there’s no way to fix it other than trying random code permutations. I hit that one with node-swift yesterday and gave up.
Is there anything in the works for taming the type inference or some way to force-select which overload I want?
Earlier quoted context omitted.
Except Flutter hit a wall with the liquid glass on IOS and Material 3 on android since they implement all the widgets from scratch implementing the new UI language will take considerable amount of effort and they are saying this is not even their roadmap RN.
Liquid Glass is meh anyway. Apple's Windows Vista moment.
Earlier quoted context omitted.
Liquid Glass is meh anyway. Apple's Windows Vista moment.
I don’t like it much but it’s the platform look and users definitely notice when you spurn the platform.
I hope they actually stick with this. Swift embedded, for example, is a sort of proof of concept more than viable platform, and you end up battling that more than the problem you are trying to solve. It is a shame because aesthetically Swift is easily the nicest of the modern safe languages, but there have been really odd noises in the community about project leadership that sour things.
guard let self = self else { return }
The big problem with swift is “expression has ambiguous type” and “expression took too long to type check”. Those don’t trade in code aesthetics but are problems I’ve never had in another language.
Earlier quoted context omitted.
> What KMP (and I'm hoping Swift for Android) bring is the possibility to share a Kotlin (respectively Swift) library instead of sharing code with C/C++/Rust/Go. So that an Android/iOS team can keep using Android/Swift without having to introduce a third language for sharing logic. have gone down this route before, and tbh the biggest issue is dev ux (ios devs cant debug easily, model mismatches vs kotlin e.g kotlin…
> e.g kotlin exceptions cant be caught from swift FWIW the approach that swift-java takes in managing interop with Java (and potentially Kotlin) function calls means it is perfectly possible to to catch exceptions thrown by the JVM using wrappers that catch and rethrow them as Swift errors. So there would be a distinction here with bringing Swift calling into JVM-based code running on Android.
> catch and rethrow them as Swift errors
Earlier quoted context omitted.
> The most important question for every cross platform framework is what happens to the UI? I kindly disagree. The first feature I want from a cross-platform framework is that it lets me write a native UI. That's why I like KMP: I can just share a framework with an iOS app built with SwiftUI. Sharing business logic makes a lot of sense in a ton of cases and has been done forever (C/C++/Rust/Go libraries, etc). Sharin…
Indeed, "cross-platform UI" can only be as good as the average between all the platforms it supports and it usually ends up costing a lot more than using the native UI kits of each platform. Kotlin Multiplatform has been and continues to be the "happy path" for buildings apps in our studio - native UI + shared business layer. Also, in terms of API stability and mental load, Kotlin is a lot more productive than Swift.…
care to elaborate ?