171–180 of 298 posts
Earlier quoted context omitted.
Android is way worse. iOS has way better APIs. Android studio is way better than XCode though
Agreed on SDKs/APIs. Compose improved the Android situation but it’s still a mess compared to UIKit. I’m more mixed on Android Studio. It’s fine I guess, but I wish its UI were more deeply customizable. Many of its design decisions irritate me.
I’m mostly in Neovim writing typescript (react native) luckily.
Does this mean there is no longer any excuse to not put iMessage on the iPhone?
Earlier quoted context omitted.
Agreed on SDKs/APIs. Compose improved the Android situation but it’s still a mess compared to UIKit. I’m more mixed on Android Studio. It’s fine I guess, but I wish its UI were more deeply customizable. Many of its design decisions irritate me.
Xcode is dogshit though… I’m mostly in Neovim writing typescript (react native) luckily.
With Android Studio, I'd say the ways that it being an IntelliJ IDE puts it above Xcode are cancelled out by other aspects of Android development, which can be abysmal. Swift Package Manager and Clang/llvm code stripping have never made me want to tear my hair out the way that Gradle and Proguard have for example.
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…
I guess I'm not clear on what you mean about putting business logic in the client. It can't only be on the client side. If you do so, then obviously you have to replicate it on the server to check that the client was sending the right results, no? Not to mention avoiding thread races and double inserts and whatever else may have gone stale on the server before you allow a client to validate something? Even if your co…
> 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.
Earlier quoted context omitted.
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
> Also React dev experience makes anything Swift related look like stone age technology How so?
- OTA updates, skipping Apple review for every little thing. Really speeds up builds too.
- Repack and module federation aren’t even possible on native
- running tests on iOS - 2 minutes minimum and having to boot the simulator in most cases. RN - seconds
- IDE with all sorts of plugins, that are impossible on Xcode, Rozenite
- AI trained on lots more React code, where they usually struggle to use Swift 6 properly
and a bunch more things
Earlier quoted context omitted.
> but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets traction. Is it? There seem to be a hundred million Java developers out there, that can do an Android app, plus even release that in-house or with minimal registration fees if single dev/sideproject. For Objective-C/Swift, there seem to be ten percent as many devs. I always…
It probably varies from area to area, but in the US iOS first is common. Having developed both, it makes sense. iOS is by far the more profitable of the two platforms and its support burden is substantially lower — far fewer versions to think about with the bulk of users running 0-2 versions behind, single form factor (only size variants), zero manufacturer skin quirks/bugs to deal with. It’s a more fertile environme…
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…
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 }
This looks not bad, but why would anyone use this in a world where Kotlin Multiplatform exists?
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 }
guard let self else { return }