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

271–280 of 298 posts

Re: The Swift SDK for Android

#271

Post by sunnybeetroot »

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?

OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user.

Re: The Swift SDK for Android

#272

Post by sunnybeetroot »

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.

OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user (yes you also have it on the server).

Re: The Swift SDK for Android

#273

Post by kristianp »

palata wrote: post #99
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 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…

>> The most important question for every cross platform framework is what happens to the UI? >I kindly disagree.

You're still discussing the question of UI though, whether it's native or not.

Re: The Swift SDK for Android

#274

Post by raspasov »

palata wrote: post #199
raspasov wrote: post #161

Earlier quoted context omitted.

React Native is pretty good at cross platform but yes, it must be tested right away on all platforms. Retrofitting an iOS-only React Native app to Android later is possible but can be of a pain, at least initially.

My experience as an Android user is that React Native apps don't feel "Android native". Maybe it's because I only notice the apps that have the poorer UI, I don't know.

React Native apps can be made to feel native but it takes some knowledge and skill. In certain cases, a bit of native code might be required instead of off-the-shelf libs.

For example, I was looking for a way to perform certain computations on a stream of frames from the camera. Most libraries available I found would send the image frames to the JavaScript side first and do the computation there. Unfortunately, that was never 60fps because the amount of data being copied/serialized was too large. The solution was to write a bit of custom code that performs the computation on the native side and only ship the computed result (tiny JSON) to the JavaScript side. The end result was easily 60fps and felt 100% native.

Re: The Swift SDK for Android

#276

Post by turtlebro »

marcellus23 wrote: post #262
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…

This seems like a pretty defensive comment in response to pointing out some objective flaws in Flutter. It’s fine to admit it’s a trade off, but a trade off necessarily means there are some downsides. 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.

It's not a fact, it's the opinion of a rather small group of elitist iOS super users. Native is an utterly overrated concept these days and in no way the solution to build an app with good UX. Users don't care whether you use SwiftUI, Components or Widgets. Users don't even know what a native app is. Stop acting like it's the only true holy way.

Re: The Swift SDK for Android

#277

Post by weird-eye-issue »

sunnybeetroot wrote: post #271
weird-eye-issue wrote: post #123

Earlier quoted context omitted.

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

OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user.

Your API should be fast enough and hosted on the edge so that the server side validation is instant feedback

Re: The Swift SDK for Android

#278

Post by marcellus23 »

turtlebro wrote: post #276
marcellus23 wrote: post #262

Earlier quoted context omitted.

This seems like a pretty defensive comment in response to pointing out some objective flaws in Flutter. It’s fine to admit it’s a trade off, but a trade off necessarily means there are some downsides. 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.

It's not a fact, it's the opinion of a rather small group of elitist iOS super users. Native is an utterly overrated concept these days and in no way the solution to build an app with good UX. Users don't care whether you use SwiftUI, Components or Widgets. Users don't even know what a native app is. Stop acting like it's the only true holy way.

"native" is a term that has meaning, and Flutter is not native.

Re: The Swift SDK for Android

#279

Post by sunnybeetroot »

weird-eye-issue wrote: post #277
sunnybeetroot wrote: post #271

Earlier quoted context omitted.

OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user.

Your API should be fast enough and hosted on the edge so that the server side validation is instant feedback

There are external factors apart from your own API that can impact latency, for example a user could be in an area of poor internet connection or have a slow connection. Users do not live in our perfect development environment bubble where everything just works, it’s important not to assume that.

Re: The Swift SDK for Android

#280

Post by weird-eye-issue »

sunnybeetroot wrote: post #279
weird-eye-issue wrote: post #277

Earlier quoted context omitted.

Your API should be fast enough and hosted on the edge so that the server side validation is instant feedback

There are external factors apart from your own API that can impact latency, for example a user could be in an area of poor internet connection or have a slow connection. Users do not live in our perfect development environment bubble where everything just works, it’s important not to assume that.

If it takes 1 second for a small percent of users to get form validation back it won't impact the business
Post reply on HN