Wow, thanks! this crackling has really gotten to bother me and I did not know it was as simple as restarting coreaudiod
34 karma · joined July 12, 2021
> Maintaining a significant new moving part in the dev process. KMP updates, management, integration, futures awareness, this all takes non-zero time.
If you're already doing that for Android, any additional tooling/infra churn for KMP is pretty negligible, except for a one-time cost of separating common kotlin code from android-specific code. KMP updates are just Kotlin updates.
> If an iOS dev wants to work on a KMP project what's the ramp up time? How much less efficiently can they contribute compared to a pure native app?
Two answers here: 1. Kotlin, the language, is quite similar to Swift, and can call ObjC APIs (or Swift annotated with @ObjC) directly via cinterop, so you're calling the same iOS SDKs. Compose is a declarative UI framework in the same vein as SwiftUI and React (and IMO with fewer footguns and quirks than SwiftUI, though there are some). It renders more like Flutter (via Skia) but it's not hard to embed as a component of a SwiftUI app. 2. KMP libraries can also export ObjC or Swift APIs, called in Swift. It's fairly common for there to be a shared business logic / service layer within an app, perhaps even shared view models, and leave the UI layer itself to SwiftUI and Compose for each platform.
Compared to something like React Native, I find that KMP is much friendlier and less opinionated about how you use it and how much you integrate it. You can use it to share a small module, or the whole app, or anywhere in between, and the seams at the boundary are not nearly as painful as you'd expect crossing languages.
> How much time is spent on problems, bugs, issues, related to KMP. This is guaranteed non-zero for any tool.
Hard to quantify, but in my time working on MapLibre Compose for the last two years, I've run into a handful of Androidx bugs, and much fewer KMP / CMP bugs. Even the same APIs, on the Compose Multiplatform side tend to have fewer pitfalls and bugs in my experience than on the Android side.
That said, the time I've spent dealing with _IDE_ bugs in JB IDEs has been far too much. These days, I spend much less time in an IDE, so it hasn't mattered as much, but I'd _like_ to spend more time there as ideally, even if agents are generating code, I want to read and navigate it in a nice environment.
> Is there less benefit to KMP with coding agents? ... just that some things are not as bad now.
Probably depends where you are on the vibe coding vs ai-assisted engineering spectrum. I'm a heavy AI user these days, close to 100% since Fable/Sol/Astra, but on code I care about, I don't vibe code, I still spend time to understand and refine at least the architecture, if not the line-by-line code. So still I prefer the single codebase because that's one fewer set of abstractions, of failure modes, of guardrails, of test harnesses, etc to worry about.
But if you care deeply about the native UI, using Compose on Android, SwiftUI on iOS, and then KMP for a shared core is an excellent architecture. The opposite, a shared Swift core, I think is also becoming more possible as Swift targets Android, though I'm unsure what the kotlin-on-android -> swift integration experience is like.
Generally, I'm very happy with the platform and it's only gotten better over the past couple years I've been deep in it.
I made a few dozen contributions from my iPhone while out on a walk last week.
Maybe you need absolutely 100% confidence your labels don't lie, but I and presumably others on this thread merely want to check for the presence of the label and the declarations on it. That's enough for me to sort my cables.
Maybe occasionally I'll come across a counterfeit cable (or more likely, a damaged cable, because I generally buy reputable ones) and have one underperform its label, but I can get rid of it then.
> It advised users to uninstall the software or update to its latest version.
This implies the government believes the monitoring mechanism was removed in the latest version. That's interesting information; if only the WSJ linked to it.
Here's a better source in Chinese: https://m.huanqiu.com/article/4SIOWXCLN6f where the government statement is reproduced and the guidance is specifically for versions 2.1.91 through 2.1.196.
> In a response to the allegations on Reddit, an Anthropic employee said on X that the code was part of an experiment the American startup started in March.
Seriously, why not link to the tweet? Here it is: https://x.com/trq212/status/2072079729331777817?s=20
> Hi, this is an experiment we launched in March that was meant to prevent account abuse from unauthorized resellers and protect against distillation. The team has landed stronger mitigations since then and we’ve actually been meaning to take this down for a while. We merged the PR and this should be fully rolled back in tomorrow’s release.
So, Anthropic intentionally included spyware targeting users in China, then removed it when it got discovered because they've since built "stronger mitigations". But if you just read the WSJ, you'd never know.
But they used to return thinking output directly in the API, and that was _the_ reason I liked Claude over OpenAI's reasoning models.
I came across it on ThePrimeagen's YouTube channel: https://youtu.be/u1WmiqlrqL0
function mutateArray(
arr: (string | number)[]
) {
arr.push(1);
}
const a: string[] = ["one", "two"];
mutateArray(a);
The most critical apps for me on mobile are banking, payments, transportation, and messaging. Banking I can’t do much about. Payments I can still handle with physical cards. Messaging is getting better thanks to people adapting proprietary services to Matrix, so with some effort you can use one open source client to reach them all.
Transportation is the area I’ve been working on. I’ve been getting MapLibre (an open source map rendering library) running on Compose Multiplatform, including Compose Desktop (so map apps built in Jetpack Compose could extend to Linux based phones like Librem) and also on Huawei’s HarmonyOS. If I can cover my everyday needs with open tools, then walking away from the Google/Apple duopoly stops being a thought experiment and starts being a real option for me.