I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.

For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.

All to say that this decision is worth considering without even taking LLM assistance into account.

When VSCode came about and had great integration for a language I was primarily using at the time ( Typescript ) I switched to that and was happy for the comparatively low config required. My Helix switch came about just because of how VSCode absolutely chewed through battery usage when I was out and about.

One thing I've struggled with is simply remembering everything it can do. I made a Desktop Mat[0] to help remind me ( literally just finished it so will see how helpful it is when the printed version arrives ).

[0] https://git.sr.ht/~netshade/helix-deskmat

> But, come on: you never took us too seriously about K8s, right? K8s is hard for us to use, but that doesn’t mean it’s not a great fit for what you’re building. We’ve been clear about that all along, right? Sure we have!

which already starts the post in a bad space for the reader. I have cognitive whiplash from what is intended. "We DON'T like Kubernets UNTIL WE DO but then WE MIGHT NOT IN THE FUTURE". Clear meaning is far more appreciated.

> More to come! We’re itching to see just how many different ways this bet might pay off. Or: we’ll perish in flames! Either way, it’ll be fun to watch.

is like nails on the chalkboard for me.

Could it just be that investing in Apple could be seen as "I get all the upside of any benefits I would get in investing in TSMC, with the additional upside of getting exposure to all of Apple's product decisions in non-chip related markets ( eg financial, content, et al )?" Like, if TSMC invented a new fab process tomorrow that was amazing, that'd be cool, but it'd be unlikely to make a substantial increase in stock prices in its future as that sort of is how TSMC normally behaves. That's their whole business. But Apple has a history of unlocking new markets and adding new cash flows, plus doing a pretty good job maintaining their current cash flows, so you get more upside on Apple, plus a hedged exposure to TSMC?

I say all that with full acknowledgement I'm just like, playing a guessing game at professionals here.

I've been happy with it thus far, even though I should note that my usage is pretty low stakes / trivial. It has just enough of what I want of modern language conveniences that I'm not sad about using it. I certainly derive some happiness from having a zero impedance inclusion on the iOS and server side; conversely, were I to use Rust, my early reading seemed to indicate I' have to navigate a bit of FFI and library inclusion on the iOS side that I'd much prefer not to.

So, at hobbyist level, it's been fine. If I were to go purely on technical merits and language niceties I would have chosen Rust, as the depth of language features and standard library features is really really nice for me, but the fact that I can just have something that works in either of my desired platforms has made it okay to deal with a slightly less mature (IMO) ecosystem.

Also, as a note, I've done just a tiny bit of SwiftWASM with this same toolset, and it's not bad either. Pretty far behind Rust's WASM capabilities in my experience, but accomplishes what I need and is generally nice. Tokamak ( a WASM-friendly UI framework like SwiftUI ) has been nice in my initial usage as well. I'm definitely at a firm hobbyist level of using this stuff tho, no production anecdotes to give you unfortunately.

Obvs it would be great if they covered 100%, but if you're trying to cover your ass right now, it's worth asking your provider about.

Also, I know that some makers ( Eli Lilly in particular ) also offer need-based aid programs to provide insulin. If you reach out to them and they're manufacturing, I believe you can get the insulin at near free if not free. ( This is also true for many medications that fall into the commonly-used category, you can explore manufacturer sites to see if they provide aid for a particular drug that is in your list )

Last year's (and somewhat, continuing) chip shortage will combine with a view in the US that chip-availability is a national security issue. At some point, the US will make a strong case for in-nation chip fabrication as a national push, whether that be favorable business conditions for companies like Intel, or negative business conditions for foreign chip providers. Intel already sees this, and is playing to that future game; maybe not necessarily win Apple back ( as they say ), but to play to a future environment where many companies that aren't 3T mega corps to not have very many attractive domestic options other than Intel.

Certainly I'm just playing a guessing game here, but that may be a potential future market they pitch to someone. "Apple will continue to play their own game, but here's a whole other market we see in the future".

https://www.reddit.com/r/bashonubuntuonwindows/comments/5ece... - My last check.

Comments URL: https://news.ycombinator.com/item?id=13259260

Points: 3

# Comments: 0