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

221–230 of 298 posts

Re: The Swift SDK for Android

#221

Post by zigzag312 »

dvtkrlbs wrote: post #211
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…

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.

Re: The Swift SDK for Android

#222

Post by saagarjha »

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 }

Most use of this is misguided unfortunately :(

Re: The Swift SDK for Android

#223

Post by saagarjha »

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…

It’s nil in Swift, and what the other comment said ;)

Re: The Swift SDK for Android

#224

Post by tomburgs »

I've worked with Flutter, React Native, and now I'm building an app in SwiftUI.

I've found a few things in the process: 1.) Neither RN nor Flutter seems to be able to create truly native applications on iOS. I've never once seen an application made in either of them and thought it was a native iOS application. 2.) Unless your application must support both platforms, android (in an economic sense) is dead weight. I was shocked to see how bafflingly little android users contributed to our revenue. I've heard this from people in other companies as well. 3.) SwiftUI (and I assume UIKit) makes it really simple to create apps according to HiG. You can feel yourself fighting the framework whenever you deviate from what Apple wants you to do. I actually think this is a good thing.

I think Apple is doing something really smart here. They're not making SwiftUI cross platform, they're making it possible for you to re-use your business logic from your SwiftUI apps in Android apps.

The way see I see it they're saying — if you want to spend the least amount of time possible building a cross platform app use Flutter or RN. If you want to create a truly native experience on both platforms, but still re-use your core business logic, Swift is your friend.

Re: The Swift SDK for Android

#225

Post by saretup »

tomburgs wrote: post #224

I've worked with Flutter, React Native, and now I'm building an app in SwiftUI. I've found a few things in the process: 1.) Neither RN nor Flutter seems to be able to create truly native applications on iOS. I've never once seen an application made in either of them and thought it was a native iOS application. 2.) Unless your application must support both platforms, android (in an economic sense) is dead weight. I wa…

> android (in an economic sense) is dead weight

Well it depends on your business model. Android has much smaller user LTV in most cases (especially in apps with no ads and only IAPs/Subscriptions), but the CPI is also smaller, so the economies of scale are different. In certain situations it happens that iOS is not profitable but android is.

Re: The Swift SDK for Android

#226

Post by kurak »

I'd love to see a future, where I can use Swift as a bridge between Kotlin and c++ and then gradually port more and more c++ to Swift.

Does anyone know/understand what's the story for using Swift's interop with c++ on Android? Should this work right now? How?

Re: The Swift SDK for Android

#227

Post by [deleted] »

tomburgs wrote: post #224

I've worked with Flutter, React Native, and now I'm building an app in SwiftUI. I've found a few things in the process: 1.) Neither RN nor Flutter seems to be able to create truly native applications on iOS. I've never once seen an application made in either of them and thought it was a native iOS application. 2.) Unless your application must support both platforms, android (in an economic sense) is dead weight. I wa…

[deleted]

Re: The Swift SDK for Android

#228

Post by the_arun »

kurak wrote: post #226

I'd love to see a future, where I can use Swift as a bridge between Kotlin and c++ and then gradually port more and more c++ to Swift. Does anyone know/understand what's the story for using Swift's interop with c++ on Android? Should this work right now? How?

Future - Is it possible to run swift built OS to run on Android devices 100%? Is that a threat to Android as an OS?

Re: The Swift SDK for Android

#229

Post by virtue3 »

noduerme wrote: post #186
throwup238 wrote: post #174

Earlier quoted context omitted.

That’s the exact opposite of what the GP is suggesting. Read this again: > Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy. Move the logic to the GQL retriever so that clients don’t have to implement business logic.

Yeah, I understood what they said. I'm wondering why the previous owners of the code decided to put business logic in the client.

we had a lot of very talented iOS devs that started running away with feature development when the server team couldn't keep up.

This really hurt the android + web client teams.

Eventually our backend started changing (mono-rail -> microservices) and it turned into an absolute cluster of trying to massage/cram new data models into the existing ones the iOS team created.

Late stage startup and then post finding product market fit problems.

Re: The Swift SDK for Android

#230

Post by virtue3 »

forgotusername6 wrote: post #203
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…

What if you want your app to work offline?

It was a near real-time messaging application. So not really applicable (other than seeing messages you already received - which could be cached from previous sessions).
Post reply on HN