[HN Gopher] Swift on Android: Full Native App Development Now Po...
___________________________________________________________________
Swift on Android: Full Native App Development Now Possible
Author : mihael
Score : 281 points
Date : 2026-01-03 23:39 UTC (23 hours ago)
(HTM) web link (docs.swifdroid.com)
(TXT) w3m dump (docs.swifdroid.com)
| mihael wrote:
| I just released Swift Stream IDE v1.17.0, which now supports full
| native Android app development entirely in Swift. You can build
| apps without touching XML, Java, or Kotlin.
|
| Under the hood, projects are powered by SwifDroid, a framework I
| built that handles the Android application lifecycle, activities,
| fragments, and UI widgets (Android, AndroidX, Material, Flexbox)
| while automatically managing Gradle dependencies. The IDE
| compiles Swift, generates a full Android project ready for
| Android Studio.
|
| This is the first public release. Both tooling and framework are
| open-source and MIT-licensed.
| canadiantim wrote:
| Congrats, I've definitely been looking to just centralize with
| Swift. Great work!
| liuliu wrote:
| One thing useful for Swift is it's native interop with C / C++
| libraries. These are often presented as SwiftPM or Bazel
| dependencies. How do you handle SwiftPM dependencies?
| fingerlocks wrote:
| Probably using the compiler flags directly? I've never heard
| of a Bazel dependency in Swift, and precompiled c++ was a
| huge pain in SwiftPM a year ago. I work on ObjC++/Swift/Metal
| as my day job and just use a Makefile because it's easier
| nicoburns wrote:
| Interestinggg. How does binding Java/Kotlin code into Swift
| work?
|
| (we're trying to do something very similar with Rust instead of
| Swift)
| mihael wrote:
| It works primarily through the jni-kit library, which handles
| JNI bindings between Swift and Java/Kotlin. You can check out
| the full docs here: https://docs.swifdroid.com/jni-kit/
|
| On top of that, the IDE also auto-generates required
| Java/Kotlin classes on the fly, for example, for Activities.
| satvikpendem wrote:
| For Dioxus?
|
| I was looking into something similar, on Flutter it uses
| FFIgen and JNIgen, might be something to look into on the
| Rust side. From what I've seen, it's quite difficult from
| pure Kotlin to Rust, as I was looking for the equivalent of
| the flutter_rust_bridge package when experimenting with
| Compose Multiplatform, as I have some crates I need to use,
| but I ultimately gave up because it was not straightforward
| at all.
| lukeh wrote:
| Another approach is swift-java, which uses Swift macros and
| also supports Panama.
|
| https://github.com/swiftlang/swift-java
| pjmlp wrote:
| Panama will probably never make it to Android, given
| Google's behaviour on updating Java support.
| w10-1 wrote:
| The threshold question is crossover: what Android development
| experience is required for Swift developers, and what Swift
| experience is required for Android/Kotlin developers? By saying
| "without touching XML, Java, or Kotlin", are you implying that
| Swift developers without Android experience could be
| successful?
|
| Then the questions is: roughly what percentage of Kotlin or
| Flutter apps could be writable in Swift? Today and next year?
| wiseowise wrote:
| That you don't have to touch Android Studio/Intellij is already a
| huge improvement. Awesome job.
| shelled wrote:
| And Gradle? Does skip the Gradle and that nightmare of a
| dependency management and handling?
| mihael wrote:
| Yes, exactly. SwifDroid automatically wires all the necessary
| Gradle dependencies, so you don't have to manage them
| manually.
| nicoburns wrote:
| Does it still ultimately call into gradle to perform the
| build?
| mihael wrote:
| Yes, since we need Gradle dependencies in order to build
| rich UI with AndroidX or Material Design. But if you're
| interested in a minimal approach without Gradle, check
| out the example by @purpln here:
| https://github.com/purpln/android-example
| mavamaarten wrote:
| I'm totally biased towards Android development using Gradle
| and kotlin.
|
| Gradle can be a pain, but if I look at what our neighbors at
| the iOS team experience (constantly having to manually merge
| project files, not being able to simply import some
| libraries, ...) it's hardly a nightmare.
|
| Specifically adding dependencies is super easy? Just specify
| which repo they're in (mavenCentral or Google or whatever)
| and add dependencies under "dependencies". When running or
| syncing, Gradle does the rest.
| crowbahr wrote:
| Touching xcode to avoid touching Android is like touching
| concentrated hydrochloric acid to avoid breathing a fart
| cosmic_cheese wrote:
| I think IDE preference leans further towards subjective than
| many believe.
|
| I find that IntelliJ IDEs are fine, but not nearly as amazing
| as they're often hyped up to be, and similarly while Xcode
| has problems it's not nearly as bad as is often claimed.
|
| My experience is somewhat colored by Android Studio and JVM
| ecosystem stuff like gradle and proguard though, which have
| been more cumulative pain for me than anything Apple-side in
| a long time (Cocoapods was pretty gnarly but SwiftPM has
| fixed that).
| bigyabai wrote:
| There's definitely room for subjectivity, but my hard drive
| space is finite. And XCode takes up more room than all of
| my Jetbrains software combined.
| ezfe wrote:
| Xcode download is only a couple GBs
| bhawker wrote:
| 12-20 GB, and only that if you don't want to run software
| on any iOS simulator.
| jshier wrote:
| Xcode 26.2 is a 2.1GB download, which expands to 8.63GB
| on disk, which includes the macOS SDK. The iOS SDK and
| simulators are another 8.38GB. Luckily Xcode versions can
| share iOS SDKs now, so you only need to install them
| once. Really the biggest disk eater is Xcode's default
| behavior of creating a huge set of simulators for every
| platform.
| bigyabai wrote:
| At 8.6gb of disk usage, they could include the entire
| macOS Mojave ISO disk image[0] and still have ~930 MB to
| include fit the IDE. It's just unprecedented.
|
| [0] https://archive.org/details/mac-osx-mojave-iso
| realusername wrote:
| Indeed, and unless that changed since, the Mac downloader
| isn't even capable of resuming downloads properly so if
| anything happens while you download these 13GB, it's back
| to square one.
| BrandonSmith wrote:
| For years, my team uses the third-party tool `xcodes`...
| `brew install xcodes` or use the
| [GUI](https://www.xcodes.app/).
|
| It allows you to easily install and maintain several
| versions of Xcode (beta / RC versions).
|
| And, more importantly, uses aria2 for HTTP download,
| which has resumability.
| bigyabai wrote:
| Now _this_ is the stuff that Apple should be Sherlocking,
| but doesn 't.
| dagmx wrote:
| You're counting the development SDK against the IDE.
| Xcode itself doesn't require that space, and you'd need
| that space regardless of IDE choice if you were targeting
| the platform.
| sweetjuly wrote:
| The linked article states that you'd use VSCode, so no
| touching Xcode.
| saagarjha wrote:
| Xcode, for all its faults, is largely pleasant to use. This
| is not true of Android Studio, which looks and works as a
| Java IDE (derogatory).
| realusername wrote:
| You can't be serious, Xcode is the worse IDE I ever used,
| while Android Studio isn't great, it cannot be compared to
| that.
|
| Xcode is so sluggish it's slower than an electron app
| despite being native, the xcode app upload is so broken
| even Apple released a third party tool to bypass their own
| IDE and its undocumented config files look like from the
| 90s and do not work well with git.
|
| The UI is sort of okay but that's not going to cut it. You
| can feel the decades of cruft in this IDE, it feel like
| using Borland.
| rwyinuse wrote:
| I've used Jetbrains IDE's for most of my career, and after
| that trying Xcode felt like going back to Medieval times.
| wiseowise wrote:
| Have you even opened the link? It uses VS Code.
| tonyhart7 wrote:
| it is time to ditch flutter/react native for these type of
| technology (kmp,swiftdroid) ????
| kllrnohj wrote:
| They target different things. kmp/swiftdroid let you share
| business logic, but not really the UI. Although this is
| SwiftUI-like, it's not actually swiftui and doesn't behave as
| such. So you'd be doing platform-specific front ends, which
| isn't necessarily a bad thing but it's different from the
| promise of Flutter/React Native which is the same UI everywhere
| saubeidl wrote:
| With KMP, you can also share UI code with Compose
| Multiplatform.
| vips7L wrote:
| Isn't that still like alpha or beta for iOS?
| saubeidl wrote:
| It's stable: https://www.jetbrains.com/compose-
| multiplatform/
| websiteapi wrote:
| jeez so many ways to do things -
|
| react native flutter ionic
|
| and now swift.
|
| it seems dart + flutter still is the only way to do all targets
| (cli/web/iOS/android/desktop) though. react native being very
| close (albeit needs electron).
|
| it surprises me that this hasn't been perfected. surely some big
| company would look at their balance sheet and see it's worth it
| even if you take a 10% performance hit on each platform, assuming
| you can share 90% of the code.
|
| does swift have a good web story or is wasm the main way?
| desktop?
| yk09123 wrote:
| I find Kotlin Multiplatform to be far and away a better
| experience than flutter
| websiteapi wrote:
| Kotlin Multiplatform does seem pretty appealing, but haven't
| looked into it very much
| flax wrote:
| Could you explain why? I have been interested, in theory, in
| Kotlin Multiplatform. But I'm already very comfortable in
| Dart and Flutter. I have decades of experience with Java,
| Javascript, and quite a few years with Typescript. Kotlin
| feels like a different kind of language, one I find grating.
| I think this is primarily aesthetic, but it's still enough to
| make getting over the initial hump annoying. As petty as it
| is, I think the lack of statement-terminating semicolons is a
| major reason I do not like it. I would welcome a factual list
| of things that make the KM experience better for you.
| BoorishBears wrote:
| Funny you say that since Dart is the primary reason most
| people I know don't want to use Flutter.
|
| There's been a trend of improved DX for languages used in
| app development:
|
| ObjC -> Swift
|
| Java -> Kotlin
|
| Javascript -> Typescript
|
| ...Dart feels like the before with no after, even though it
| got traction in the era of the Afters.
| vips7L wrote:
| Darts pretty good. It has a lot of modern features,
| nullable types, pattern matching, sum types, and factory
| constructors; some really good build tooling. It can
| compile fully AoT.
| saagarjha wrote:
| It's not very good if you're comparing it against Kotlin
| or Swift though.
| satvikpendem wrote:
| Eh, it's getting there, slowly at first but more rapidly
| now. It now got tearoffs, I explained in another comment
| but
|
| > _if you have an `enum Color { red, blue }` and a
| function takes `Color`, you can just do `f(.red)` not
| `f(Color.red)`_
|
| Dart is getting new features pretty fast, they really
| started focusing on the DX more after Dart 2 and now
| especially after Dart 3. Macros were supposed to ship but
| it was incompatible with the goals of fast compilation,
| so other sorts of smaller features will ship instead.
| virtualwhys wrote:
| Big turnoff with Dart is the lack of json (de)
| serialization -- kind of shocking to have to resort to
| source code generation libraries in a modern language.
|
| Also, statement based instead of expression based, and
| not immutable by default are kind of a drag; not the end
| of the world but a bit unpleasant, IMO.
| satvikpendem wrote:
| Serialization support is coming, probably this year. As
| for statements vs expressions, it does have some
| expressions such as if and for inside lists but changing
| it wholesale to an expression based language would be too
| much of a breaking change.
| virtualwhys wrote:
| Serialization support has been coming for years, I lost
| patience.
|
| Otherwise, yes, some support for expressions, some
| support for immutability, no support for optional semi-
| colons, no privacy modifiers so "_" littered everywhere.
|
| I just found it to be an exceedingly ugly language when I
| used it a couple of years ago. Yes, some more pleasant
| modern functionality has been bolted on since then, but
| it's unfortunate that Dart was chosen as the backing
| language for Flutter, which is an awesome mobile
| framework.
| satvikpendem wrote:
| Serialization has always been possible via libraries, so
| most people were doing fine with that, what is coming is
| native serialization support, but in practice it will be
| functionally the same, ie rather than you running
| build_runner, the compiler will do it for you. I'm not
| sure what you used but that's what you were hung up on,
| there were always ways to solve it.
|
| Dart is a pragmatic language, it has everything you need
| and has a lot of benefits too, such as sound null
| checking (very few languages have this, Rust comes to
| mind), JIT and AOT support (Javascript / TypeScript such
| as for React Native doesn't, and Kotlin is just getting
| there with Kotlin Native but it still has a lot of
| issues), and now more functional programming concepts
| with algebraic data types via sealed classes and pattern
| matching.
|
| What language would you have chosen when Flutter came out
| circa a decade ago, or, we can be even more charitable
| and ask what language would you use today if you were to
| implement Flutter? I'm curious because everyone has their
| own ideas but they all don't work for one reason or
| another.
| vips7L wrote:
| I thought dart could natively deserialize via
| dart:convert? It just only decodes to lists and maps, you
| have to manually map into classes.
| realusername wrote:
| It's a matter of taste, even just the swift example on
| this website makes me raise eyebrows.
| wiseowise wrote:
| It is great if you're comparing it against Kotlin or
| Swift, unless you're stuck in an era of 1.x Dart.
| websiteapi wrote:
| isn't this just because Dart is way newer than those?
| it's from the 2010s. it's really modern in comparison
| (same generation as Kotlin swift and typescript)
| BoorishBears wrote:
| > Dart feels like the before with no after, _even though
| it got traction in the era of the Afters._
|
| It's aged like the recent languages but feels clunkier
| like a language that's much much older.
| mdhb wrote:
| Dart is hands down the best modern language out there for
| app development right now what are you even talking
| about? I understand that maybe a lot of people haven't
| used it or maybe haven't used it in years and that
| probably drives a lot of the FUD but for those who use
| it, it has stupidly high ratings from developers who use
| it and has for years.
| BoorishBears wrote:
| It's not FUD when you make something terrible* and that
| reputation doesn't immediately slough off.
|
| And I just checked the Dart release notes from all of
| 2025: https://dart.dev/resources/whats-new
|
| Great progress! But smells a lot like the language I had
| it pegged for when "underscore as a wildcard" lands in
| February 2025, 2 years after pattern matching lands.
|
| How did they ship pattern matching in 2023, with a
| million examples of how to do it right already hashed out
| and in the wild... and then not figure out a wildcard
| symbol for 2 years?
|
| -
|
| * Dart was awful, lost to Javascript because no one rated
| it highly enough to justify moving off Javascript, and
| was practically dead until Flutter dusted off the corpse
| and pivoted away from their browser goals... so super
| weird revisionism to act like we're talking about some
| beloved evergreen language.
| wiseowise wrote:
| You seem confused and indeed spreading FUD.
|
| Dart wasn't awful. It wasn't adopted at the time because
| it had a distinct runtime that would require splitting
| web in two which nobody wanted. On top of that it gave
| Google too much power, because now they would control
| both runtime (V8) + language (Dart).
|
| TypeScript won and became king because it was pretty much
| JS 2.0 instead of JS++ like Dart.
| BoorishBears wrote:
| In your version of history Dart was always a great
| language... but Google was simultaneously too powerful
| for other vendors to allow Dart to proliferate, but also
| too weak to sustain it themselves _despite Chrome going
| on to do just that for many many web standards._
|
| I'm sure that's a really cozy idea, but doesn't pass the
| "common sense" test: a bit like your random misuse of the
| term FUD.
|
| -
|
| The simple reality is it wasn't very good, so no one was
| rushing to use it, and that limited how hard Google could
| push it. ES6 made Javascript good enough for the time
| being.
|
| Dart 1.x had a weak type system, and Dart 2 was adding
| basics Kotlin already had almost 2 years earlier: that
| was also around the time I first crossed paths with
| Flutter, and honestly Flutter _by itself_ was also pretty
| god awful since it was slowly reinventing native UI /UX
| from a canvas.
|
| (It was a lot like Ionic: something you used when you had
| a captive user-base that literally couldn't pick a better
| product. Great for Google!)
| wiseowise wrote:
| Have you even used modern Dart?
| vips7L wrote:
| Kotlin doesn't feel right to me either. I did a portion of
| AoC in it this year and it was surprisingly more verbose
| than I expected. I think the thing I liked the least was
| trailing lambda syntax combined with how verbose it was to
| define variables with types.
|
| It also inherits all of the bad parts of the JVM. Crappy
| build tooling (gradle), and then the slow startup and high
| memory usage.
| cosmic_cheese wrote:
| Coming from writing a ton of Swift (and previously
| Obj-C), Kotlin's ergonomics feel kinda off. It also feels
| like it's different for the sake of being different more
| often than I'd like.
| Larrikin wrote:
| Can you give concrete examples? I played with Swift in
| school after already making the dive into Kotlin. It just
| felt like Kotlin but trapped on Apple. Part of the
| program even included a course in using a different
| language every couple weeks where we went through Scala,
| Lisp, and some others just to see what they could do.
|
| Currently Kotlin is far and away my favorite language but
| I also haven't looked into the newer languages recently
| and am interested in hearing pain points people have.
| Especially if it isn't annoyances with Gradle
| cosmic_cheese wrote:
| Broadly speaking, Kotlin deviates from popular
| conventions more than Swift does. For example, Kotlin
| expects you to use inline if statements where in Swift,
| ternary operators work like they do in C, JavaScript, and
| many other languages.
|
| There's also things like Swift's guard statements that
| can help make intent clearer and read a bit more nicely.
| myHNAccount123 wrote:
| Same opinion. It just feels off. Why use `fun` for
| function declarations instead of func or function?
| Dropping () before { makes it hard to tell what runs
| first. It feels like it's trying to be different for the
| sake of being different. I'm not able to quickly skim
| kotlin code like other 'C-like' languages and tell what
| is going on because it's trying to be too clever.
| llmslave2 wrote:
| You're just not used to it.
| vips7L wrote:
| https://steveklabnik.com/writing/the-language-
| strangeness-bu...
| satvikpendem wrote:
| I used Kotlin as well and it just feels off too. The
| package support is a major thing, as I don't want to mess
| around in Gradle, I want something that Just Works(tm).
| Dart 3 has much of the same feature set as Kotlin now with
| sealed class support, it's just not as functional, but it
| recently got tearoffs so you don't have to specify the
| class, just the property, similar to Swift (ie if you have
| an `enum Color { red, blue }` and a function takes `Color`,
| you can just do `f(.red)` not `f(Color.red)`).
|
| The main thing though is that Dart has pub.dev and a CLI
| that makes it extremely easy to add packages, via `dart pub
| add`. If I do want to go more of a functional route I'll
| just use Rust instead, it has all of what Kotlin has and
| more, plus a similar streamlined package management as Dart
| in the form of `cargo add`.
| cageface wrote:
| The last time I looked at it was far less mature on non-
| Android platforms than Flutter. Has that changed?
| crowbahr wrote:
| Flutter has been abandoned by all the large companies -
| Google is throwing their weight in on KMP and has laid off
| the flutter teams.
| websiteapi wrote:
| I heard of the flutter layoffs, but my understand is that
| it was unrelated to KMP. fwiw google still uses flutter
| cageface wrote:
| This is a large exaggeration. There are still a lot of
| people working on Flutter at Google and large companies
| continue to adopt it.
|
| Google's wildly popular NotebookLM is a recently released
| Flutter app, for example.
| satvikpendem wrote:
| This is completely incorrect. Large companies like
| Canonical are all in on Flutter even now, they're making
| it the default for desktop UI development in Ubuntu and
| are writing a lot of their own apps in Flutter.
|
| The "layoffs" were not any of the core team, it was just
| an offshoring, of infrastructure devs at Google that
| happened to work on Flutter builds, to Europe where they
| rehired for the same positions there.
| mdhb wrote:
| Just straight up making shit up here. WTF are you talking
| about?
| palata wrote:
| Google Workspace has been moving to KMP. They said at
| KotlinConf that it has replaced their decade-old
| transpiler from Java to ObjC, which is very impressive.
| wiseowise wrote:
| Source?
|
| > Google is throwing their weight in on KMP
|
| Hahah.
| satvikpendem wrote:
| That's funny, I found it the exact opposite, not the least of
| which is that it requires a JetBrains IDE to even run it.
| VSCode or neovim with Flutter and really most every other UI
| framework like React (and Native) work great.
|
| Regarding KMP specifically, I didn't find it much use to only
| write business logic in one language, while still having to
| rewrite the UI up to 6 times (mobile, web, desktop), I'd
| rather have everything all in one.
|
| Compose Multiplatform looks promising as it's Flutter-like in
| that it renders its own UI but it's still quite early, I know
| they say it's "stable" but when I used it, it really didn't
| seem so, plus the package support is extremely lacking
| compared to Flutter and of course the behemoth that is React
| (and Native)'s npm.
|
| These days I'm looking forward to Dioxus, they're making
| their own native renderer similar to Flutter but especially
| for web, they are _not_ doing the canvas trick, because they
| actually use plain HTML and CSS as their markup languages so
| they can compile directly to browser standards sites while
| still having a non-webview experience on mobile and desktop.
| wiseowise wrote:
| In what way? It's an unfinished, hot garbage bolted on top of
| Gradle. Flutter is light years ahead in terms of polish and
| development experience.
| palata wrote:
| I think you're confused. It's not "something on top of
| Gradle". For instance to run on in Swift on iOS, it has to
| compile to native, and then it wraps it in a C interface
| and finally in a Swift interface. This has absolutely
| nothing to do with Gradle.
| kenferry wrote:
| The bigger hit than performance is usually user experience
| quality and "write once debug everywhere".
| websiteapi wrote:
| true - though I don't think that's inherent, more just the
| mentality of one who might pursue this.
| wahnfrieden wrote:
| Swift on WASM also got very good last year. SQLite in WASM too.
|
| Flutter is still bad on iOS and macOS. No Liquid Glass (except
| some weird hack attempts that look and behave badly). Liquid
| Glass isn't an optional decoration, it's the name of the new
| system-wide UI. Leaving it out of your app is like committing
| to iOS 6-era skeuomorphic design after iOS 7.
|
| Edit: Several cross-platforms frameworks can do Liquid Glass:
|
| - SwiftUI by using Skip for Android
|
| - SwiftCrossUI
|
| - React Native
|
| I'm glad to see that I can finally target iOS as the first-
| class citizen, using Apple technologies, and then run that code
| on other platforms. Instead of having to use frameworks that
| treat iOS as secondary when it is by far the biggest money-
| maker for most apps.
| websiteapi wrote:
| in my experience wasm on web, though it works, has too slow a
| first page load time for slow connections.
| wahnfrieden wrote:
| Embedded Swift WASM is very small now. But it is still
| behind on some useful capabilities like having a
| replacement for Codable (which last I read may be getting a
| more performant replacement). Regular Swift WASM got a lot
| smaller too last year though.
| websiteapi wrote:
| interesting - do you have a good example of a non-trivial
| web app that uses swift wasm?
| wahnfrieden wrote:
| Goodnotes
| cageface wrote:
| I've had very good experiences with Flutter on iOS and macOS.
| It's actually a lot easier to get good performance in Flutter
| than SwiftUI.
|
| No cross platform stack can do Liquid Glass yet. You have to
| wonder if that was one of design goals.
| gumby271 wrote:
| I'm pretty well convinced it was a goal too. If it wasn't
| then shame on them since it doesn't accomplish anything
| else well.
| d12bb wrote:
| It's nice developer experience indeed. But for me as a
| user, I hate it. Looks nothing like an iOS app, often even
| worse than fckng webviews...
| wahnfrieden wrote:
| All those approximations at Liquid Glass are infuriating
| to use and make every app that does feel cheap and gross
| satvikpendem wrote:
| > _Edit: Several cross-platforms frameworks can do Liquid
| Glass:_
|
| This is pretty funny because you just listed SwiftUI three
| times but in different configurations. They're not _truly_
| cross platform, they just wrap Apple 's native design code.
| In contrast, I can (and do) use a package like
| liquid_glass_renderer to get Liquid Glass everywhere, on all
| my devices, with one codebase.
| wahnfrieden wrote:
| If this is the current state of it, I can spot a dozen
| details that are wrong or missing: https://x.com/imadethese
| works/status/1973765948218941771/vid...
|
| Maybe it will get there... Meanwhile I would rather use
| technologies that provide the full experience on the
| platform where it matters, and would never want those
| liquid components on platforms like Android or Windows
| anyway.
| satvikpendem wrote:
| Well, the library is literally 3 months old, and it's
| made by one person as an OSS package, so yes, I'm sure
| you can spot those wrong details. Still, it'll get there,
| especially once Flutter gets official support for Liquid
| Glass, as they are planning on working on it later this
| year or into next year, currently they are refactoring
| their current design library code.
|
| > _and would never want those liquid components on
| platforms like Android or Windows anyway._
|
| That's where we disagree then, I like the design itself
| but don't like it stuck on only one platform. I make apps
| with wholly custom UI designs, not following any
| particular OS' "native" design, and that's why Flutter is
| so powerful, because I am not constrained to what pixels
| I can render to a screen, nor should I be.
| dangus wrote:
| > Liquid Glass isn't an optional decoration, it's the name of
| the new system-wide UI
|
| Of course it's optional. Some of the most popular apps on the
| planet ignore the local UI conventions of their parent OSes
| entirely.
|
| TikTok is a Flutter app. It looks identical on iOS and
| Android. It uses basically no native UI elements.
|
| It's a pretty well-known strategy to create apps that look
| identical on all platforms so that you lessen your customer
| confusion and your support burden. The fact that Spotify,
| Facebook, Uber, and Reddit look exactly the same no matter
| what platform you're on is more important than complying with
| OS design guidelines and UI elements.
| neonmagenta wrote:
| Exactly. Branding and UX are breaking out of the box for
| guidelines in the successful platforms. You want to be able
| to pick up any device and have the user know exactly what
| theyre doing
| wiseowise wrote:
| Thank God I'm only using web versions whenever possible.
| dangus wrote:
| Which also have consistent branding and UX with the apps.
| wiseowise wrote:
| That's fine, as long as I have native OS
| dialogs/settings.
| d12bb wrote:
| > Spotify, Facebook, Uber, and Reddit
|
| And I hate every one of those apps (well, back when I used
| Facebook, years ago, I did), because they're just bad iOS
| citizens. I, as most iOS users do, don't care what apps
| look on Android. For Android users, it's the same with iOS.
| Making shitty cross platform apps is all about branding and
| saving some money for developers, nothing about the users.
| dangus wrote:
| It's cool that you are a non-conformist badass but their
| wild popularity proves that a native app experience
| doesn't matter.
|
| What does "bad iOS citizen" even mean?
|
| It's not even about saving money for developers, it's
| about the fact that your users expect a consistent
| experience.
|
| Imagine if you watched an NFL game on NBC and the on-
| screen graphics were different if you were watching on a
| Samsung TV versus an LG TV. That's the issue with native
| app UI elements (and it would quite literally be an issue
| with content apps on smart TV app platforms which are way
| more fragmented than iOS versus Android).
| d12bb wrote:
| Your conclusion is false, as you're mixing stuff that
| shouldn't be mixed here:
|
| 1. Spotify, Uber etc are popular because of their
| product, not the pure quality of their apps. People use
| Uber because they want to cheaply get somewhere, and
| Spotify cause that's there all their shared playlists
| are.
|
| 2. People buy whatever tv is on sale when their old one
| breaks, but the vast majority will stay with their phone
| platform, so couldn't care less what their apps look on
| the other platforms out there.
|
| So, native experience does matter, but obviously only as
| one of multiple deciding factors.
|
| > What does "bad iOS citizen" even mean?
|
| Doesn't look like native apps, doesn't feel like native
| apps (come on, most multi platform frameworks don't even
| get the scrolling right, one of the most basic forms of
| interaction), doesn't use all of the platforms features
| to their fullest, as applicable for the type of app.
| wahnfrieden wrote:
| What I meant to say in my original message is that if you
| are using system default-ish iOS UI styling, Liquid Glass
| is not optional decoration. If you have your entirely own
| UI and design system, sure you don't need it. But many of
| these Flutter apps or other such toolkits are using it to
| approximate system default UI except either without the
| Liquid Glass parts or with uncanny and incomplete
| approximations of it.
| uripont wrote:
| I thought TikTok used native implementations and Lynx
| (their cross-platform framework)
| dangus wrote:
| I dunno, the ByteDance logo is on the Flutter web page.
|
| But it really doesn't matter either way. The point is
| that TikTok doesn't follow any OS conventions.
| cyberax wrote:
| React Native doesn't use Electron on mobile, it's a
| misconception. But it does depend on interpreted JavaScript on
| iOS and Android.
| websiteapi wrote:
| I mean on desktop
| avtar wrote:
| React Native doesn't depend on Electron for desktop apps
| either. It renders using native UI components and don't use
| a browser engine.
| websiteapi wrote:
| I know react native for windows is a thing, but is it on
| par with electron these days? my understand is that it
| was way beyond, but I could def be wrong
| LorenDB wrote:
| Qt/QML can do all those targets as well (although it is
| admittedly jankier on mobile than Flutter or Swift would be).
| palata wrote:
| I never understood that. Qt is C++. The only valid reason to
| use C++ is "not having a choice" (which happens to me, too).
| But if you write a mobile app, I find it extremely weird to
| choose C++ instead of a modern language.
|
| Disclaimer: I have seen teams writing mobile apps in Qt, and
| it was systematically a lot slower to develop, with a lot of
| pain, and resulting in worse apps. Even if you only have C++
| devs, I would argue that it may be worth giving them the time
| to learn a modern language and write the mobile app with it.
| SchwKatze wrote:
| There is also Dioxus
| satvikpendem wrote:
| I was initially uninterested in Dioxus because they just used
| webviews but their native renderer is really interesting now
| because it has a lot of strengths, using plain HTML and CSS
| as the markup language so that they don't have to render to a
| canvas on the web like Flutter, Compose Multiplatform or many
| other WASM based renderers do, as they can just, well, ship
| the HTML and CSS directly. But then on mobile and desktop, it
| _will_ be rendered without a webview, so you get all the
| benefits of each platform.
| topspin wrote:
| > it surprises me that this hasn't been perfected
|
| It shouldn't. It's never really been perfected across native
| GUI APIs after 40+ years: just various degrees of "good
| enough," plus fobbing it off to web stacks.
|
| Anyhow, I've been playing with gioui, which is golang rendering
| in a lightweight <canvas>-like. Really nice: fast, small, cross
| platform GUI with just Go. Scale expectations appropriately.
| wahnfrieden wrote:
| Somehow I never heard of this. How does this compare with
| SwiftCrossUI? Skip is also very compelling (as it runs actual
| SwiftUI natively as Swift and translates it to Compose).
|
| I see - compared with SwiftCrossUI and Skip, this is SwiftUI-like
| but only for Android. The other two allow you to write SwiftUI or
| SwiftUI-like, and run on both Apple platforms + Android (or
| elsewhere).
| mihael wrote:
| It's a different approach with different goals.
|
| SwifDroid is about native Android development in Swift. You're
| not writing cross-platform UI. You're writing Android-specific
| UI in Swift, using Android's own view system and APIs directly.
| The goal is to enable full, idiomatic Android apps entirely in
| Swift, including activities, fragments, AndroidX, and Material,
| without touching Java, Kotlin, or XML.
|
| While the others focus on "write UI once, run anywhere," often
| with trade-offs in UX, SwifDroid focuses on writing natively
| for Android and having full control from Swift.
| dave_sid wrote:
| Using a common language between platforms, whether it's Swift or
| Kotlin always sounds great on the surface but I don't think adds
| the expected efficiencies when it comes to the crunch. I expect
| teams would always still end up with two codebases, with enough
| differences and workarounds to make it that you might as well
| just enjoy using Kotlin or Swift as you need to. Knowing two
| languages isn't all that bad. Most developers learn many
| languages during their careers and switch between them without a
| thought. Just my opinion tho, I'm sure this is a good project.
| isodev wrote:
| Knowing two or more languages is kind of liberating even.
| People love shiny but there are no shortcuts in this case.
|
| Also, given <waves hands at everything>, I'd never consider
| becoming even more dependent on some big bad corp. And even if
| one is to put that aside somehow, Swift is a painful language
| ... would be such a self own to have to use it even in places
| you're not forced to.
| myko wrote:
| Shocked to hear Swift described as "painful" (well, maybe the
| new concurrency stuff)
| isodev wrote:
| It's always been unpleasant but you could find a balance to
| make it work. Since Swift 6 it's just headache as a
| service. If only we weren't forced to use it..
|
| Also picture this. Every time you run swift build, you get
| a mental image of Cook dining with Trump. It's very hard to
| stay focused and creative in that ecosystem rn.
| saagarjha wrote:
| I have unfortunate news about the tech industry in
| general.
| isodev wrote:
| Indeed, but it doesn't hurt to be a bit more selective
| and future thinking when choosing a stack or tools.
| willtemperley wrote:
| Bill Gates, Tim Cook, Mark Zuckerberg, Satya Nadella,
| Sergey Brin and Sundar Pichai were all there dining with
| Trump.
|
| Weird how Tim Cook gets so much hate, when the rest of
| them didn't. He didn't say anything notable except a bit
| of ring-kissing: "I want to thank you for setting the
| tone such that we can make a major investment ..."
|
| Then Sergey Brin starts talking about how he's happy
| about Trump pressuring Maduro:
|
| You're applying a lot of pressure to Maduro and I think
| that's phenomenal for an American president to actually
| be applying pressure there uh in Venezuela and then
| hopefully in Cuba and so forth. So there's a lot of um
| civil rights work that you're leading. we didn't get a
| chance to mention. Um I also just wanted to mention um we
| don't have to get into all the uh details talked about in
| the Oval Office, but uh I think it's a real incredible
| inflection point right now in AI and the fact that your
| administration uh is uh supporting our companies instead
| of fighting with them."
|
| So, reading between the lines a little, i.e. Google
| looking depose dictators and burn lots of oil to keep
| their AI slop churning is totally fine:
|
| https://www.youtube.com/watch?v=MvbKA-Te8QE
| einsteinx2 wrote:
| So Swift is painful to use because Tim Cook once had
| dinner with someone you don't like?
| oefrha wrote:
| Yes, these cross platform frameworks speed up developing easy
| and boring things but actively gets in the way the moment you
| venture out for more esoteric platform-specific features.
| Overall time savings is questionable, especially in the AI age
| where you get a lot more speedup for the easy and boring things
| with better documentation and more training corpus. Not
| recommended (from someone who made the switch back to separate
| native codebases), unless your app can basically be a web app
| anyway.
| tcoff91 wrote:
| Yes building a native app has fewer layers of abstraction and
| often has better DX than building with a cross-platform
| framework where you have to work around bugs that inevitably
| exist in the framework.
|
| Cross-platform frameworks I find are more about making sure
| that your apps stay consistent across platforms over time as
| they are maintained. Features land on all platforms at the
| same time.
|
| I worked on a product that had been around a long time and
| had a separate macOS, windows, iOS, android, and web apps. It
| was a big a big shit-show when product leadership wanted to
| make large scale changes across all platforms in unison. For
| that product though it really did have to be native to each
| platform and I don't think any cross platform framework could
| have worked for that particular product.
|
| Having worked with both native apps & cross-platform
| frameworks, I do think there is value in cross-platform
| frameworks as long as the framework allows you to drop down
| to native platform specific code easily where needed.
|
| When it comes to mobile, I think that React Native has some
| serious benefits:
|
| - Fast refresh: incredible DX improvement to be able to just
| save a file and instantly see the behavior of your app update
| without rebuilding and reinstalling. - Server-driven UI via
| React Server Components (still experimental): Companies like
| AirBnB spend a ton of engineering effort to build their own
| bespoke server-driven UI frameworks. Expo Router is bringing
| React Server Components to native apps. - Automatic deep
| linking: If you also ship your app for the web using Expo Web
| & Expo Router, then all your links work perfectly as deep
| links into your app because your web app and your native app
| have the exact same routing. If you use next.js with solito
| for your web app instead of Expo Router, you can also keep
| your web app in lock-step with your native app without having
| to use Expo Router for your web app. - Over the Air Updates:
| You can ship changes to your apps instantly without app store
| review. - Can drop down to native easily: These days you can
| easily build an expo module or if you need really high
| performance build a nitro module and leverage the native
| platform APIs where you really need it. I mean look at react-
| native-vision-camera, it's so much easier to use than the
| native camera APIs. - LLMs are way better at react than they
| are at swift & kotlin development.
|
| If I wanted to build the next TikTok though I'd 100% go full
| native.
| muzani wrote:
| Kotlin and Swift are both very similar, and where they are not,
| we don't really want the abstraction. I agree, it's cool, but I
| doubt we'd use it.
|
| I'm leaning towards Swift being the 'better' language, but even
| in this case, something like KMP has been around longer and is
| more stable.
| monegator wrote:
| Which is what we're doing. The moment your app isn't some
| webview react crap and start using any non basic (or even
| basic) features you end up with two codebases. For example,
| anything using foreground services or requiring runtime
| permissions.
|
| The only framework i found that really bridges the gap is B4X,
| but you still need to have two separate projects, because of
| services, and #if blocks for the things the framework doesn't
| abstract (which, to be frank, is really just advanced uses of
| peripherals and libraries)
|
| The two OS' are just so fundamentally different.
| leptons wrote:
| >Knowing two languages isn't all that bad. Most developers
| learn many languages during their careers and switch between
| them without a thought.
|
| One of the most revered programmers in my circle, who's been
| coding since the early 1970's asked me once, "how many
| programming languages do you know?". I started rattling off a
| few, and he stopped me. He said "I only really know the last 2
| languages I used".
|
| Jack of all trades, master of none. If someone asked me to code
| in PHP, Perl or any of the dozens of languages I've used in the
| past today, just no way. No thank you. Yeah, I used to be very
| proficient with lots of languages, but no way am I going dust
| off those brain cells. Assembly is probably the only language I
| can really get into on different platforms without a huge
| cognitive context switch, because it's just straight forward,
| no kooky abstractions.
|
| That said, I've used Javascript for front-end, back-end as well
| as database (mongo), and it was absolutely great to not have to
| context switch constantly. I've also done lots of different
| systems with a wide variety of other languages glued together,
| and it hasn't been as effortless as using one language for
| everything. YMMV.
| wiseowise wrote:
| Many times this. I'm always skeptical if people saying they
| know 5+ programming languages beyond surface level.
| dagmx wrote:
| A lot of language concepts are shared and abstract. It's
| not hard to know many languages proficiently.
|
| I do agree a lot of people over estimate how much they
| know, but I work with multiple people who know at least 5
| languages well.
|
| For me myself, only counting things I've shipped at scale,
| I'd know C, C++, Swift, JavaScript, Python, Rust, MSL,
| HLSL, GLSL, MEL. There's enough in common between them that
| I think it's quite doable.
| pjmlp wrote:
| When you work in enterprise consulting, it suffices to know
| a language good enough to deliver.
|
| It is common practice to be thrown at random projects
| regardless of the programming project.
|
| What is valued is the soft skills, and the ability to swim
| when thrown into the cold water, no matter how.
|
| Yes it kind of sucks, however the Pandora box is long open
| and only an implosion of the capitalist enterprise culture
| would fix it.
| ChrisMarshallNY wrote:
| But it does allow engineers, trained on one platform, to work
| on the other.
|
| Long ago, I took a few months, and learned Android programming
| (using Java, which was the native choice, back then). I ended
| up not really enjoying it, and eventually abandoned it, but my
| goal was to write fully-native Android.
|
| I'm a big believer in fully-native development. I've worked
| with cross-platform frameworks for decades, and have _never_
| enjoyed any significant success.
|
| For that reason, I'm a bit skeptical of the chances for this
| framework, but admire the work and dedication that went into
| it. I sincerely wish them luck.
|
| _> Most developers learn many languages during their careers
| and switch between them without a thought._
|
| I've worked with quite a few, over my 40+ years of experience,
| but I don't really "switch without a thought." There's always a
| "context switch" overhead.
|
| For example, I am currently writing a Swift app (SwiftUI), with
| a PHP backend. I keep switching between the two. The biggest
| mistake I make in PHP, is neglecting trailing semicolons. The
| next-biggest mistake, is not surrounding if statement
| evaluations in parentheses. I've been working with PHP a lot
| longer than Swift, but not anywhere nearly as deeply. Swift is
| definitely my "native" language.
|
| My experience is that I can learn a working understanding of a
| language in a couple of weeks, but it takes _years_ to really
| get proficient. Think someone that speaks with a heavy accent,
| and someone fluent.
|
| Also, the language is often the least relevant aspect. SDKs,
| stdlibs, and frameworks are where most of the work lives. They
| can take a _long_ time to master, and are usually "moving
| targets," undergoing constant evolution (like the language,
| itself).
| meindnoch wrote:
| >But it does allow engineers, trained on one platform, to
| work on the other.
|
| The programming language is the most surface level detail
| when learning a platform.
|
| The libraries, the frameworks, the OS services, the app
| lifecycle, the UI idioms are the hard part, and those cannot
| be abstracted away (of course you can try, but you'll end up
| with an inconsistent mess that doesn't feel native in any of
| the supported platforms, at which point you should just
| create a website).
| pjmlp wrote:
| > using Java, which was the native choice, back then
|
| It still might be, as Kotlin isn't used on the lower layers
| below JetPack libraries, despite Google's resistance to
| modern Java adoption.
| agentifysh wrote:
| Really bizarre to see all the dogpiling on Flutter/Dart, it's
| fine. Google isn't giving up on it and we aren't going to
| suddenly switch to something else. In fact I have no desire to
| use React Native which the community seems to always point to
| Expo, a paid tool with metered usage.
|
| My only gripe is that there is no 3D game engine for Flutter,
| again Dart is great, lots of solid packages like GetX just make
| the overall development progress as advertised.
|
| People also sleep on the fact that Flutter can do web application
| and target all 3 desktops and this shit is all free without
| needing a 3rd party tool like Expo because the RN core experience
| is lacking and you need to depend on another vendor.
| satvikpendem wrote:
| > _My only gripe is that there is no 3D game engine for
| Flutter, again Dart is great, lots of solid packages like GetX
| just make the overall development progress as advertised._
|
| Yeah they're going to work on 3D afterwards (potentially, the
| main dev for 3D left the Flutter team and is back on Android if
| I recall correctly), it's not a huge priority right now. Also,
| it's not recommended to use GetX, there are some issues with
| it, a major one being it's like a framework within a framework,
| and it essentially rewrites a lot of Flutter. Better to use
| Riverpod, Bloc, Signals, ReArch or something else.
|
| For 3D however, I've been looking at Dioxus which is in Rust,
| they're making a native renderer the same as Flutter (ie not
| webviews) called Blitz, and they're making good progress on the
| mobile side. This renderer can embed Bevy, a game engine also
| written in Rust, _and Bevy can also embed Dioxus native,_ which
| I thought was really cool, it 's bidirectional embedding.
|
| I didn't know Expo explicitly made you pay, I thought it was
| only optional. Now that I look at it, seems like it's for high
| priority builds but still, can't we just build on our own
| servers? If not then that's a big con, I don't want to rely on
| an external service just to build my app.
|
| What are you making in Flutter?
| aleph_naught wrote:
| You can build on your own machine. I have github actions that
| trigger a local macos runner for local expo android/ios
| builds.
| tcoff91 wrote:
| Expo is free, that was misinformation. EAS costs money but is
| optional.
| RantyDave wrote:
| Likewise. It took me a while to "get" flutter but now I'm here,
| I 'aint leaving.
| tcoff91 wrote:
| Calling Expo a paid tool with metered usage is just flat out
| misinformation. You can promote your preferred tech without
| lying about alternatives.
|
| Expo is a free open source framework that costs absolutely no
| money to use. You do not need to pay expo any money ever.
|
| Expo Application Services is a set of cloud services that you
| do not have to use to use Expo. You can set up your own on-prem
| build infrastructure with fastlane and never use EAS Build. You
| can self-host your own EAS Updates server. You don't have to
| use EAS Hosting for web apps. Expo is far less coupled to EAS
| than Next.js is to Vercel.
|
| Flutter for the web is terrible compared to React Native Web.
| It's a great way to get your company sued for violating the
| Americans with Disabilities Act. It literally renders to a
| canvas almost like the Macromedia Flash apps of old. There's
| also React Strict Dom now which absolutely blows flutter's web
| support out of the water while still supporting react native:
| https://facebook.github.io/react-strict-dom/
|
| I just looked up an example flutter web app and it's completely
| invisible to the screen reader when I enable VoiceOver:
| https://flokk.app/#/ . The screen reader literally announces
| 'web content is empty'. You can't even select text to copy it!
|
| Also, as far as integrations with game engines:
|
| https://github.com/calico-games/react-native-godot
|
| If you want complex 2D graphics like you can do with flutter,
| react native can also use the Skia rendering engine just like
| flutter with react-native-skia.
| Qiu_Zhanxuan wrote:
| Flutter for the web is lacking but for iOS/Android/Windows
| it's ideal.
| tcoff91 wrote:
| The DX may be ideal but they are not very ideal for your
| iOS users. Painting pixels vs composing native views is not
| great.
|
| I'd rather put up with the more painful DX of react native
| because I care more about the quality of the app vs the DX
| agentifysh wrote:
| saying Expo is "free" is disingenuous. sure, you can self-
| hosts and duct-tapep pipelines together on-prem, but at that
| point you're just paying in devops hours (https://github.com/
| expo/expo/issues?q=is%3Aissue%20state%3Ao...) instead,
| something which is not part of flutter DX
|
| your comparison for web is a lazy trope. If a Flutter app is
| invisible to VoiceOver, thats on the developer for ignoring
| the semantics tree, not the framework
|
| ironically, your point on React Strict DOM actually shows how
| much of a mess RN web approach is. Flutter solved cross-
| platform consistency at the engine level years ago while
| React is still trying to force the DOM to behave.
|
| I much prefer a compiled language than the runtime
| uncertainty of RN. composing native views sounds ideal until
| an iOS update changes and breaks your layout, or JS bridge
| chokes during a complex animation edge case that will get you
| digging through github issues. Flutter is rendering natively
| on the GPU without the overhead. I prefer shipping a
| consistent app over debugging why some react-native-* is
| dropping frames on a budget phone because of JS thread
|
| Overall, I find your blatant marketing advertisement of Expo,
| very suspicious, digging through your past comments I see
| similar promotion of Expo and RN. You can see Expo's pricing
| (https://expo.dev/pricing#plan-features) which clearly shows
| its a classic open-core funnel scheme to get developers to
| build dependence and end up paying for build credits
| never_inline wrote:
| > lots of solid packages like GetX
|
| I haven't touched flutter in two years, but isn't getX a
| kitchen sink library disliked by everyone?
| agentifysh wrote:
| 11k likes on github means everyone hates it? it is anti-
| pattern which might turn people off sure.
| vanillax wrote:
| What is the point of this. just use flutter or react native.
| Octoth0rpe wrote:
| Some people have a strong background in swift already and would
| like to use that experience for Android dev. That's a perfectly
| reasonable goal.
| daveidol wrote:
| If you already have a Swift app it could be worth considering.
| Or if you are targeting like 90% iOS users and just need
| Android support to check a box.
| akmarinov wrote:
| Imagine if people said "just use swift and kotlin" back before
| RN and Flutter - we wouldn't have them
| z3t4 wrote:
| Why is mobile development so shitty compared to PC? Why cant you
| make an hello world in asm for a mobile device?
| saagarjha wrote:
| You can. It would be about as bad as writing hello world in
| assembly for PC, which is why nobody does it.
| surajrmal wrote:
| It's all about where the stable ABI exists. You can do anything
| in practice, but if you stray off the happy path it will result
| in pain. On PC OS, everything used C (or in Linux, syscall)
| ABI. On android the ABI is java based, and on iOS it's
| objc/swift based. These are deliberate choices and while they
| make some use cases more difficult, they are optimized for the
| use cases the companies care about. I'm personally preferential
| to a language agnostic IPC boundary being the abi, but that has
| its own cons as well.
| dagmx wrote:
| You're conflating ABI with primary language for frontend
| development.
|
| Android, iOS and "PC" all use the C ABI at their C stack
| level. They just have different languages available for their
| primary SDK.
|
| Windows doesn't use a C api primarily for example, so your PC
| example is wrong. Mac shares the same frameworks as iOS so is
| no more Swift/objc than iOS. It's just that you can't really
| ship electron (JIT) or easily use Qt (licensing) on iOS. But
| you can just as happily develop entire apps in the same C as
| you could on a "PC". Case in point, blender builds for iOS.
|
| Android is definitely the most out-there of the platforms
| because the jump from JNI to Java SDk is quite large but that
| is completely orthogonal to what you're incorrectly claiming.
| Your comment is conflating completely opposite ends of the
| stack, but if we go by your definition, Android is Linux just
| as much as Linux distros on desktop.
| pjmlp wrote:
| ABI is the language used to write the OS, thus OP is kind
| of right.
|
| While Windows has moved away from pure C, and nowadays has
| ABIs across C, C++, .NET, COM, WinRT interfaces, you can
| still program Windows applications in straight C.
|
| The caveat is to only use APIs up to Windows XP, and
| Petzold's book to follow along.
| dagmx wrote:
| They're describing higher level API that may have a
| separate ABI than the lower level system.
|
| But like I said, they're conflating the lower level ABI
| with the higher level API/ABI.
|
| All the systems they mentioned have an equal C ABI
| available for talking to the core system.
| pjmlp wrote:
| Small correction.
|
| On PC, MS-DOS did not use C, rather interrupts and there was
| no common C ABI.
|
| On OS/2, a mix of C ABI and SOM, with C, C++ and Smalltalk as
| main languages.
|
| Windows started only with the C ABI, nowadays it is a mix of
| C, C++, .NET, COM, WinRT, depending on the subsystem.
| deergomoo wrote:
| https://gist.github.com/nicolas17/966a03ce49f949dd17b0123415...
| palata wrote:
| A ton of native apps are written on mobile. On desktop, there
| is a trend of shipping a full browser together with a goddamn
| webapp instead of making a proper desktop app. I wouldn't say
| that desktop is more successful there...
| vivzkestrel wrote:
| Been out of android stuff for a while, can someone kindly
| elaborate here
|
| - best way of making apps last i checked was swift for ios and
| java for android
|
| - i read somewhere java got replaced with something called kotlin
|
| - then i heard they added something called flutter that works on
| both android and ios
|
| - react native / "web browser based" was already a form of dev i
| think which was considered the most non performant solution out
| there
|
| Is this swift on android another layer like the above ones? the
| most performant layer is always native right?
| satvikpendem wrote:
| React Native is not webview based, it's basically a translation
| layer that takes your JSX markup and turns it into SwiftUI /
| Kotlin UI code, native on each device.
|
| Personally I like Flutter, a lot of people, even hardcore
| Android native devs, say Flutter could be the way to go for
| Android development in general [0].
|
| [0]
| https://old.reddit.com/r/androiddev/comments/1np26m4/do_othe...
| palata wrote:
| I liked Flutter 1.0, but then it broke my codebase with 2.0,
| and again with 3.0, which made me swear never to use it
| again.
|
| The good ideas of Flutter, IMHO, got implemented in native
| Android (Kotlin + Compose).
| satvikpendem wrote:
| I don't mind not having backward compatibility especially
| when it's for a growing framework that's not feature
| complete. Those versions are semantically versioned so you
| didn't need to upgrade if you didn't feel like it.
|
| Jetpack Compose and Compose Multiplatform is nowhere near
| what Flutter does, it's essentially still Android only as
| their other OS support isn't really stable, even if they
| say it is. I tried to make an app and gave up and went back
| to Flutter.
| palata wrote:
| > Those versions are semantically versioned so you didn't
| need to upgrade if you didn't feel like it.
|
| This is only valid if you write a trivial app. If your
| dependencies migrate to the new major version, eventually
| you have to do it as well.
|
| Cross-platform frameworks are generally not terrible for
| trivial apps; the pain comes when the app get
| complicated. But then if it's a trivial app, I can write
| it natively in the different languages I need to support,
| so there is not much need for a cross-platform framework.
|
| Of course if your alternative is Qt, then Flutter is
| better :-).
| palata wrote:
| > then i heard they added something called flutter that works
| on both android and ios
|
| Flutter is just another cross-platform framework that happens
| to support Android. I think it brought good ideas that since
| got implemented in native Android. I am still against cross-
| platform frameworks anyway.
|
| Kotlin-the-language has evolved into compiling for different
| targets instead of just the JVM. So with Kotlin MultiPlatform
| (KMP), you can compile your Kotlin code as a native executable
| (instead of a JVM one) or as an iOS framework. So that you can
| share a Kotlin library between e.g. Desktop, Android and iOS.
| The difference with Flutter is that KMP is not a cross-platform
| framework; just a way to "cross-compile" a library, if I can
| say. Just like you may share a C++/Rust library between iOS and
| Android, you can share a KMP library.
|
| And Swift is also trying to get there, though it is less mature
| than Kotlin in that respect.
|
| The advantage is that you can cherry-pick the library you want
| to depend on. Maybe your Swift team wrote advanced logic in
| Swift and it makes sense for you to call it from Kotlin instead
| of rewriting it, just like you may depend on a C, C++ or Rust
| library. And it is different from a framework like Flutter: if
| you go with Flutter, you write the whole app in Flutter.
| aprilnya wrote:
| I wonder how this compares to Skip[1]? This seems to be focused
| entirely on Android, as opposed not making existing iOS SwiftUI
| code work on Android. I assume that might lead to better apps but
| any practical examples?
|
| [1] https://skip.tools/
| mvkel wrote:
| Just in time, right when Apple is quietly abandoning it
| mobiledev2014 wrote:
| That's one I haven't heard yet, do elaborate
| akmarinov wrote:
| He might be referring to Apple abandoning SwiftUI as there's
| a rumor going around about it.
| dickersnoodle wrote:
| Rumors are worth exactly what you pay for them.
| steve1977 wrote:
| Any sources for this? Reason I'm asking is I have some old
| knowledge in Objective-C, earlier Swift and AppKit/UIKit
| and I'm considering brushing up my Swift and also learn
| SwiftUI.
| mihael wrote:
| https://www.youtube.com/watch?v=pL8Ex0Co8fA
| solidsnack9000 wrote:
| Apple is abandoning Swift on Android?
| pjmlp wrote:
| I think you are confused with Objective-C.
| thedumbname wrote:
| How to make a HTTP call and parse JSON response idiomatically?
| pjmlp wrote:
| Kind of, because this always has to go via JNI in the end, given
| that 80% of the API surface is only exposed via Java.
|
| These efforts are always to celebrate, however they always end up
| with leaky abstractions.
|
| Just like on the other way around one needs to be aware of
| Objective-C for success, or .NET/COM on Windows.
| larusso wrote:
| The fun part is that now you need to bind against swift and
| objective-c for success on Apple systems. They no longer
| provide obj-c frameworks for all the new things. So you have to
| double hop and deal with both or deal with it on a framework by
| framework level. Talking from a Unity background here where the
| interop with obj-c is kinda smooth due to the c# -> c
| marshaling. But swift needs a bit more work.
| pjmlp wrote:
| With a caveat, Metal is written in a mix of Objective-C and
| C++, with Swift bindings.
|
| Thus you can do anything Metal with Objective-C and zero
| Swift.
|
| Also, writing drivers, even in userspace is still mostly C++.
|
| Going on a tangent, even if Swift isn't everywhere still, I
| would like that Microsoft would be half as serious as Apple,
| regarding .NET use on Windows, however they aren't even
| serious with C++.
| iamcalledrob wrote:
| The reverse -- building for iOS in Kotlin -- is an interesting
| option that on the surface appears to be a best of both worlds.
|
| You get (1) access to JVM APIs as normal on Android, and (2)
| Fairly full-featured interop with ObjC, Swift and C APIs
| elsewhere, and (3) A pleasant language with excellent IDE
| support in IntelliJ.
|
| The `expect fun` / `actual fun` stubbing for different
| platforms also works in a fairly low-drama way. You can also
| share UI with Compose Multiplatform (less mature), or just
| write native views.
|
| The downside (of course) is that non-JVM targets like iOS can't
| use the JVM ecosystem, and most of the Kotlin ecosystem assumes
| Kotlin/JVM. This is slowly changing though, and isn't a
| structural flaw.
|
| Also, you're going to end up with Gradle in your toolchain,
| which will torture your poor soul.
| pjmlp wrote:
| Yeah, the JVM ecosystem is what makes Kotlin interesting, and
| the main reason why Google begrudgingly updates Java support,
| when Android starts to lag behind the current Maven Central
| trend, currently Java 17.
|
| I agree regarding Gradle, thankfully the time I used to do
| Android native development is behind me, even if I keep up
| with Google IO sessions, and ADP Podcast.
|
| How is Kotlin Native maturity nowadays?
| iamcalledrob wrote:
| I've found Kotlin/Native to be fine, but very basic. It's
| limited due to lack of ecosystem and minimal stdlib, though
| this is improving.
|
| There are things you might expect to be able to do
| trivially (e.g. formatting a timestamp into a date string)
| had no off-the-shelf approach last time I tried. You'd need
| to roll your own, or pull in an existing non-kotlin
| library, e.g. something from C.
|
| I think a lot of issues stem from existing APIs being
| designed around Java types that will never be available
| without the JVM.
| fuomag9 wrote:
| The cookie consent definitely feels not legal in europe
| mihael wrote:
| Thanks
___________________________________________________________________
(page generated 2026-01-04 23:01 UTC)