zlacker

[return to "The Codex App"]
1. Olympi+EJ[view] [source] 2026-02-02 21:31:37
>>meetpa+(OP)
It is baffling how these AI companies, with billions of dollars, cannot build native applications, even with the help of AI. From a UI perspective, these are mostly just chat apps, which are not particularly difficult to code from scratch. Before the usual excuses come about how it is impossible to build a custom UI, consider software that is orders of magnitude more complex, such as raddbg, 10x, Superluminal, Blender, Godot, Unity, and UE5, or any video game with a UI. On top of that, programs like Claude Cowork or Codex should, by design, integrate as deeply with the OS as possible. This requires calling native APIs (e.g., Win32), which is not feasible from Electron.
◧◩
2. gloosx+I92[view] [source] 2026-02-03 06:38:10
>>Olympi+EJ
>This requires calling native APIs (e.g., Win32), which is not feasible from Electron.

Who told you that? You can write entire C libraries and call them from Electron just fine. Browser is a native application after all. All this "native applications" debate boils down to the UI implementation strategy. Maintaining three separate UI stacks (WinUI, SwiftUI, GTK/Qt) is dramatically more expensive and slower to iterate on than a single web-based UI with shared logic

We already have three major OSes, all doing things differently. The browsers, on the other hand, use the same language, same rendering model, same layout system, and same accessibility layer everywhere, which is a massive abstraction win.

You don't casually give up massive abstraction wins just to say "it's native". If "just build it natively" were actually easier, faster, or cheaper at scale, everyone would do just that.

◧◩◪
3. AdamN+as2[view] [source] 2026-02-03 09:07:13
>>gloosx+I92
The gap here is that the company has the money and native apps are so clearly better. With an interactive app a company like OpenAI could really tweak the experience for Android and iOS which have different UX philosophies and featuresets in order to give the best experience possible. It's really a no brainer imho.
◧◩◪◨
4. pimter+jy2[view] [source] 2026-02-03 09:51:43
>>AdamN+as2
> the company has the money

It's not about money. It's not a tradeoff in cost vs quality - it's a tradeoff in development speed. Shipping N separate native versions requires more development time for any given change: you must implement everything (at least every UI) N times, which drastically increases the design & planning & coordination required vs just building and shipping one implementation.

Do you want to move slower to get "native feel", or do you want to ship fast and get N times as much feature dev done? In a competitive race while the new features are flowing, development speed always wins.

Once feature development settles down, polish starts to matter more and the slowdown becomes less important, and then you can refocus.

◧◩◪◨⬒
5. AdamN+id3[view] [source] 2026-02-03 14:30:14
>>pimter+jy2
Yeah that's why startups often pick iOS first, get product-market fit, and then do Android. The fallacy that abstractions tout is that Android and iOS are the same.

They are not.

A good iOS app is not 1:1 equivalent to what a good Android app would be for the same goal. Treating them as such just gives users a lowest common denominator product.

[go to top]