Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Swift SDK for Android

swift.org

Post reply on HN
Print view View original

131–140 of 298 posts

Re: The Swift SDK for Android

#131

Post by [deleted] »

ryeights wrote: post #104
turtlebro wrote: post #103

Earlier quoted context omitted.

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…

I'm not hating, I'm actually working on a Flutter project currently. I don't understand why we need to pretend like the platform is perfect

[deleted]

Re: The Swift SDK for Android

#132

Post by morshu9001 »

VWWHFSfQ wrote: post #10

I think people will get excited about this and then quickly realize how painful it is to code in a foreign environment from the platform. How miserable it would be trying to write Java or kotlin targeting iOS apps. I think this will be the same. Just use the native tools and languages for the platform. Swift/Objc/xcode for iOS. Java/Kotlin/Android Studio for Android. You will be so much happier.

idk about Android, but native iPhone dev is pure torture. Hence React Native.

Re: The Swift SDK for Android

#133

Post by [deleted] »

akmarinov wrote: post #11
colesantiago wrote: post #3

What does this mean for React Native? Is Swift now going to be the de facto language for Mobile (and maybe Desktop) development?

Not a chance React Native is popular because there’s a thousand times more React devs than native devs. And people like to use what they know. Also React dev experience makes anything Swift related look like stone age technology

[deleted]

Re: The Swift SDK for Android

#134

Post by marcprux »

bsimpson wrote: post #126
marcprux wrote: post #119

Earlier quoted context omitted.

The Swift SDK for Android doesn't specify or mandate any user-interface technology, but leaves it open for other projects to build upon. For example, Skip.tools re-implements SwiftUI for Android by bridging it to Jetpack Compose, so you can use the same codebase for both your business logic as well as UI layer. We write about it at https://skip.tools/blog/fully-native-android-swift-apps/ and an example of an app on t…

Appreciate the response! Respectfully, the demos on your page look like impostors on Android. For apps that wouldn't bother supporting Android in the first place, maybe this is an improvement. But for apps that want all customers to feel considered, that's not a direction I would recommend. Would still like to see a call out to this in the blog post above ("For UI, you can use Swift for business logic and use Android…

> the demos on your page look like impostors on Android

On the Android side, Skip apps utilize Jetpack Compose directly, which is the officially recommended toolkit for creating Android apps these days (https://developer.android.com/compose). It isn't mimicking native UI like other x-platform tools, but is actually using the Google-recommended API.

Re: The Swift SDK for Android

#135

Post by andrekandre »

orliesaurus wrote: post #60

Interesting to see excitement around this release... BUT beyond cross‑platform hype there's a practical question... what developer tooling will look like... Are we getting first‑class debugging, package management, continuous integration for Android targets... ALSO adoption often comes down to licensing and governance... open SDKs thrive when the steering group is transparent and responsive... And it's worth remember…

  > Are we getting first‑class debugging, package management, continuous integration for Android targets...
the most important part imo.

i'd love it if you could pull/push and build/debug changes to the shared code from android studio and build it all together there, that would reduce a huge amount of friction...

Re: The Swift SDK for Android

#136

Post by flutas »

orliesaurus wrote: post #60

Interesting to see excitement around this release... BUT beyond cross‑platform hype there's a practical question... what developer tooling will look like... Are we getting first‑class debugging, package management, continuous integration for Android targets... ALSO adoption often comes down to licensing and governance... open SDKs thrive when the steering group is transparent and responsive... And it's worth remember…

IMO the implementation (for me at least) is ... terrible. Why reach for this when it's, at the end of the day, just the exact same as NDK work in C++ but in Swift.

You have to use Kotlin / Other UI setup anyways (or their fully-native example, use OpenGL to draw the screen[0]), and on top of that statically assign the package path and class name in the Swift code, while making it an external func in the kotlin code[1]. You then also get to deal with the annoyances that come up with native libs.

kotlin side: /* * A native method that is implemented by the 'helloswift' native library, * which is packaged with this application. */ external fun stringFromSwift(): String

swift side: @_cdecl("Java_org_example_helloswift_MainActivity_stringFromSwift")

[0]: https://github.com/swiftlang/swift-android-examples/blob/mai...

[1]: https://github.com/swiftlang/swift-android-examples/tree/mai...

Re: The Swift SDK for Android

#137

Post by timsneath »

ranie93 wrote: post #130
mosura wrote: post #37

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 }

Ha! But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null.

You use this construct for unwrapping nullable fields, for example something like this:

guard let httpResult else { return }

Note that you don't need to assign the value to itself in modern Swift. This line takes an optional (httpResult?) and returns early if null. If not, you can use it with strong guarantees that it's not nullable, so no need for ? or ! to unwrap it later in the scope.

Re: The Swift SDK for Android

#138

Post by CBMPET2001 »

timsneath wrote: post #137
ranie93 wrote: post #130

Earlier quoted context omitted.

guard let self = self else { return }

Ha! But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null. You use this construct for unwrapping nullable fields, for example something like this: guard let httpResult else { return } Note that you don't need to assign the value to itself in modern Swift. This line takes an optional (httpResult?) and returns earl…

I've seen that exact pattern used to safely unwrap a weakly captured 'self' within a closure (to avoid retain cycles)

Re: The Swift SDK for Android

#139

Post by [deleted] »

kridsdale3 wrote: post #113
bsimpson wrote: post #86

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…

The Browser Company did an amazing job of porting SwiftUI to Windows, where the element primitives in the language map to native Windows UI C++ classes under the hood. Perhaps the future of Swift for Android is similar, where SwiftUI will map to Jetpack elements. That would be cool. Remember on iOS and MacOS, SwiftUI is not "native". It's a description language that system frameworks interpret and create NSViews and…

[deleted]

Re: The Swift SDK for Android

#140

Post by hbbio »

weird-eye-issue wrote: post #123
virtue3 wrote: post #114

Earlier quoted context omitted.

Having worked a long time with client teams as a lead - this is always the biggest pain in the ass. At one of my last phase startups I started shifting all our business logic stuff into our graphql server and treated it like it was part of the client teams. (we had ios/android/web as independent full apps with a very small team of devs). Business logic is the real killer. Have one person suck it up and do it in types…

So your takeaway is that business logic should be done on the server. Hasn't it always been like this?

Has been the true core vision of the web if not mobile. If I remember correctly, that is how the original Basecamp was implemented, or Craigslist (still is?)... or this very website
Post reply on HN