I've been toying around with multiplatform frameworks like RN and Flutter for a side project of mine but they never feel right. I'd rather use the native UI per platform and have a nice way to share business logic. KMP exists 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. With a little foresight of keeping shared code in a Swift Package, it seems like that's getting more and more possible which is great to see.
> 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 only tinkered with Android apps in my spare time, but never managed to deploy anything to iOS.
Also, outside the US, iPhones are a 10 % niche product in private hands, but companies might use a lot of iPads or provide iPhones as work phones, so perhaps companies do think of both platforms as second class citizens (behind windows/browser as two other "OS-like" primary platforms)
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 environment for getting up and running and getting the core product shaken out.
Android can come later when you’re out of rapid iteration and have the bandwidth to deal with the idiosyncrasies of the Android world.
In large parts of the world, the iOS and Android revenue share are roughly 50/50 with the higher $/user of iOS and the higher market share of Android cancelling each other out. And that means everyone makes hybrid apps unless they're in a niche where that's impossible, which is rare. Only if they become very successful or raise massive funding (for that country), then they might switch to two native apps.
It's probably a US centric take you're replying to.
Having worked at multiple companies making apps in the US and the company I work at right now which is a company almost everyone knows the name of and the vast majority of our revenue comes from our native apps - practically every feature we build is iOS and web first and only if it performs well do we even consider adding to android most of the time. And it's primarily because product/execs know iOS users are more likely to pay for things.
It's sad as an android user myself, but android is very much a second class citizen in the US
Even ignoring global OS marketshare, iOS app store customers just simply spend a lot more money per user on the App Store vs Google Play (Google's Android app store). You gotta go where the money is to some extent to get paid.
Global revenues on the iOS app store have always been significantly larger than Google play, even with only ~30% of the global smartphone market.
Average amount of money spent means little in the context of parent's comment (revenue for a US company).
For instance, if you're Netflix, do iOS user bring you more revenue in the US ? What if you're Hertz ? What about Walmart or Costco ? The only factor will be how many of your users are on iOS vs android. It's a different story if you're a gaming company and target whales of course.
Even if you're a social media company, where network effect is everything and getting into everyone's pocket matters, you can still go iOS first. Snap ran with that strategy at first, and it hardly killed the company.
Notably, that's a situation that actually matters for cross-compatibility. There's no web client for SnapChat. Hertz & Costco could point Android users to the web with few repurcussions, IMO
This is still about the actual market share. iOS being 55%+ of the market makes that strategy viable in the US. You'd start with android instead if you were to launch in Korea for instance.
for us its pixel phones, you can choose iphone if you want but most of us want pixel. so for me its macbook + pixel. I think the iphone only is unique to US.
> KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first
This sounds US-centric to me.
The advantage of KMP is that it is pretty mature and it is used in big apps like Google workspace (Google Docs etc), so it feels like it may be in a really good position.
I used to be exited about Flutter when it started, but the speed of major releases (by the time I had rewritten my app for Flutter 2, Flutter 3 was out, or something like that) and it did not seem to get so much traction (Dart is fun, but well).
KMP builds on top of Kotlin, with big investment from JetBrains and Google. That looks extremely promising to me.
I think business-logic-in-JavaScript is something cross-platform folks shouldn't snooze on either, with the usual caveats of not doing anything performance-critical or where an asynchronous API would be awkward (to be clear, using JavaScriptCore or QuickJS or the like, not just running in a WebView)
But it'll run on iOS (v7.0+), Android (I think more recently) and of course web and server-side. And most importantly, it's hot-reloadable, as long as you don't run afoul of platform gatekeepers (i.e. use it for bug fixes and minor behavior changes, not like whole new features).
One of the frustrating things about mobile development is that once you ship a version, that version will almost certainly be running on at least someone's device indefinitely without being upgraded. My day job is even on step further back in that we have to get our customers to update the version of our SDK that they're integrating (which for many of them means contracting out because they don't have an in-house mobile dev team), before they ship an app update, which then needs to be installed by end-users, whose device might not even support the new deployment target…
(I've been trying to sell this to the bosses for the last 9 years or so, and never gotten the go-ahead, so there could be aspects I'm missing, but it always seemed like a huge missed opportunity).
OTA updates are definitely nice to have and I'm surprised there's not a way to do so with native iOS since RN and Flutter already support it. Technically it is possible with dynamic frameworks.
In practice though it's somewhat easy to workaround the lack of OTA with dynamic server configuration for clients.
This is not actually true. It’s allowed as long as you don’t make significant alterations to the app as a way to get around the App Store review process. It’s confusing because there are 2 areas of the policy that seem contradictory on this matter, but it is allowed.
no one in their right mind wants to bundle Chromium with every app install, and every Discord user hates mobile Discord app, which is, guess what? uses Chromium!
For JS driving the business logic you do not need a browser to run it. On iOS there is JavaScriptCore and there are other Javascript runtimes out there that are quite small.
That said, it is true that Javascript may not be the right choice for every app and some developers may be used to better language features and performance than that.
It’s more complex now since they shipped the new renderer, but essentially serializes the react UI tree to JSON and passes it to native which parses and renders native components
The issue with that approach is that the state of the art for iOS dev is about 15 years behind the state of the art for Android dev. The amount of simple things that are incredibly painful for iOS devs to do is astounding. Some of that is because xcode is horrific, some of it is that the ecosystem is starved by disinvestment from Apple.
I've talked with colleagues in several companies and the story is always the same: the iOS repository is a patchwork of horrible patterns that shatters when you update to the latest iOS target.
At my current employer it takes 4 iOS devs longer to implement things than it takes 1.5 Android devs (0.5 because the other .5 is spent being Team Lead and architecting, planning, endless meetings etc).
When I talked with the KMP team at Google they were mentioning that their most enthusiastic user base at Google was iOS developers, begging to be saved from their tooling nightmares.
I'm sure some defensive devs will show up here but I've been at 5 different places over my decade at work and every single one of them has had endless struggles hiring iOS devs, maintaining iOS projects etc.
This is already possible with .NET and MvvmCross: a shared core library plus native UI projects for each platform. UIKit feels great in C# and it’s all been working quite well since Xamarin times, with access to the Nuget ecosystem.
Not at all, but it’s important not to mix up Xamarin (nowadays just .NET) which is basically native bindings for C# and Xamarin.Forms UI framework (nowadays MAUI) which is write-once approach like RN.
The former is exactly what you are talking about: building native UIs twice and then sharing the common logic.
Very neat, thanks for explaining. The only drawback I've seen in the past with apps using .NET is the binaries end up pretty huge due to the runtime. I'm assuming that's still the case here? I wouldn't be surprised if this is also an issue with Swift for Android but I haven't looked yet.
It's not too bad, about 12-15 MB for the runtime on iOS. I'd say the main downside compared to other cross-platform frameworks is the lack of official hot reload (it's possible but really clunky) for building UIs.
Otherwise, I’ve been working with it since 2018, my app now has around 500k installs on both stores, and I’ve encountered very few issues related to the stack itself. Mobile .NET has been steadily improving, and LLMs have made the two-native-UI approach much easier: after building an iOS UI, I ask Claude to repeat it on Android for the same view model and get about 80% done instantly.
react native do uses native UI per platform in contrast to flutter or compose multiplatform. React Native improved a lot - it's not the same technology that has been 5 years ago. Especially this year there were plenty of improvements also regarding speed but in react native and community plugins (new architecture rolled in, react compiler, hermes v1, nitro modules, flash list v2, legend list, react native skia, react native webgpu, expo use dom) Tooling in JS/TS ecosystem also improved a lot.
Yes it uses native UI by wrapping the underlying frameworks, but that still means there is a layer in between that has to be updated with fixes and new features. Every RN project I've tried in the past turned into a dependency mess since you find edge cases that are not supported by the framework.
It's definitely gotten better like you said but I just prefer to work with the native platform code even if it's a bit of extra effort.
So this seems similar to https://temporal.io/, am I reading this right? I used that briefly a few years ago and it was pretty nice at the time. It did make some features much easier to model like their welcome email example. Would love to hear from someone with extensive temporal experience, iirc the only drawback was on the infra side of things.
I've been thinking lately that maybe we need a new AI-friendly file format rather than continuing to hack on top of PDF's complicated spec. PDF was designed to have consistent and portable page display rendering, it was not a goal for it to be easily parseable afaik, which is why we have to go through these crazy hoops. If you've ever looked at how text is stored internally in PDF this becomes immediately obvious.
I've been toying with an idea of a new format that stores text naturally and captures semantics (e.g. to help with table parsing), but also preserves formatting rules so you can still achieve fairly consistent rendering. This format could be easily converted to PDF, although the opposite conversion would have the regular challenges. The main challenge is distribution of course.
Not really sure what you mean by a "human-friendly" file format, can you elaborate? File formats are inherently not friendly to humans, they are a bag of bytes. But that doesn't mean they can't be better consumed by tools which is what I mean by "AI friendly".
As others have said the Sagrada Familia is incredible and I had high expectations given all the controversy around it. I've visited many historic churches during my travels and it's my favorite one. Really neat to see it reach this stage.
Why would a company like Lyft/Uber partner with Waymo at this point? That sounds like doing a deal with the competitor who _will_ completely kill them off in the future.
Not necessarily. Does Waymo really want to run all the additional infra and services and people ops required to be a full soup-to-nuts ride hailing service?
I mean, they do today, but maybe they don't want to be in that business.
You can never rely on support reps to escalate UX issues to product teams for a couple reasons.
First, from their perspective if they are able to solve an issue by following their script, even if it took 20 convoluted steps, everything is working normally. People are used to occasionally dealing with workarounds so it's not a big deal in their mind.
Second, it's not in their interest to report UX issues. They are measured by the number of tickets they close, so the issue that gets a lot of inbound support and they know an easy workaround for is nicely boosting their numbers. Eventually these things get fixed by product and they move on to doing the same thing with other tickets.
Perverse incentives. They are judged by how long the call takes, and every time they escalate a common problem that the devs could fix, now their numbers will go down and they'll get punished for their good work.
Dell at one point pulled the plug on outsourcing their tech support. They spotted this moral hazard partway through the process and decided it was better to keep it in house.
On the opposite side of moral hazard, early in my career I worked for a large web security company in tech support. We were not permitted to escalate to engineering at all. Often this meant the only solution was to apply our own, unofficial code changes!
However I strongly doubt your point about "It's not going to replace anyone's job" and that "they also free up the human agents to do higher-value work". The reality in most places is that fewer agents are now needed to do the same work as before, so some downsizing will likely occur. Even if they are able to switch to higher-value work, some amount of work is being displaced somewhere in the chain.
And to be clear I'm not saying this is bad at all, I'm just surprised to see so many deluded by the "it won't replace jobs" take.
Personally I like the UI for https://conductor.build/ a lot more than this, although I'll have to give it a try.
I see a lot of commenters asking why a GUI is necessary. When you're running several agents in parallel it becomes very handy compared to the terminal. I can easily see the status of each which I haven't found a good equivalent for when using terminal tabs. Also it handles automatically creating git worktrees for each agent which is great.
I agree with others that this is not how Tailwind is meant to be used. For example, the approach shadcn (https://ui.shadcn.com/) takes is much better IMO.
Creating helpers like `btn` makes it very difficult to understand how it works and is not very customizable. Shadcn creates an actual component for you in your codebase and is just trivial Tailwind styles to modify.
I tried shadcn and didn't like it. I don't want a new component in my source tree that I have to maintain.
For nearly everything, I won't need to customize it (and if I do have to customize often, it probably means that particular component library wasn't a good choice).
And for the rare cases where I do need to customize something, I can always go into the source of the component library, copy what I want out into my project, and edit it.
> this is not how Tailwind is meant to be used
Who cares? If it works, and makes the development process easier, and doesn't cause problems, then that's a good thing.
The problem I have with shad is that it’s react based, not HTML based.
So if I want to use shad, I can’t mix and match static HTML partials in with app code. To maintain a consistent theme, I would need to make literally everything react.
> I agree with others that this is not how Tailwind is meant to be used.
I mean, whatever it's "meant" to be used like, Tailwind is popular enough that it ends up being used in a lot places where how it's meant to be used is a terrible fit. (Big apps, with existing UI code, can't assume a monolithic technology stack, an actual design system with tokens that is not just a react component library, etc).
Ultimately, these are webapps and 99% of what we do ends up being the same shit over and over: "here's a button, here's a card", etc and all ends being like what DaisyUI, Bootstrap, etc offers and I'm glad DaisyUI is there to make Tailwind feasible for the people who are hot on it (don't realize it might not be a good fit for what they are doing.)
Yea sure, there are still some spots where I might find DaisyUI helpful, like building a quick internal admin page for something. And another commenter pointed out this works in non-react projects unlike shadcn. But I would know going into it that it will be a pain to customize/maintain, should I ever need to do that. Maybe that's already the expectation for people familiar with Bootstrap though.
My advice is more cautionary for folks who search "Tailwind components library", see DaisyUI as the 4th result, and think "great!"
I've been toying around with multiplatform frameworks like RN and Flutter for a side project of mine but they never feel right. I'd rather use the native UI per platform and have a nice way to share business logic. KMP exists 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. With a little foresight of keeping shared code in a Swift Package, it seems like that's getting more and more possible which is great to see.