kall

I have had good success with using xcodegen and only a project.yml checked in. Claude can get tripped up on managing the xcode project xml.

However, before that, i set up a blank project in xcode, used the xcode github integration to create a new repo on github, set up one xcode cloud workflow and use it to push one build to testflight. That way, you get all the automatic config of app ids, profiles etc, and xcode cloud can not be enabled other way. Then tell claude to migrate to xcodegen and to run it in CI automatically.

I've started to develop iOS apps from scratch using only claude code web (no mac), by setting up a "Branch Build" workflow in xcode cloud, and a skill that teaches claude how to check builds and fetch logs.

Along with a workflow that pushes any merge on main to internal TestFlight, the dream of developing iPhone apps on the iPhone finally lives. I've tried most options for this over the years and they never stuck.

These are simple apps that build in 1-5 min on xcode cloud. For larger builds it probably won't work so well.

It is confusing because between all the different levels of being static or server side rendered or client side rendered, next.js can pretty much do (and potentially mix) them all, right?

I'm quite confused on _why_ they want next to act like this? You can use anchor tags to force a browser navigation, but what does it get you? You're still loading JS bundles and it's not like <Link /> breaks anything like history or open in new tab. People put turbolinks in their rails app to get something that works half as well.

You could also use unstable_disableRuntimeJs on some pages and your <Link /> will still fully degrade to act like a completely server rendered page.

Aside from the points below, it's implemented in Safari IIRC?

Keyboard Maestro should do that handily.

Two options: a reverse proxy or you serve both from the same system.

For reverse proxy you can go the old and trusted route with e.g. Nginx, go fully managed with something like external rewrites on Vercel, or even hack together your own thing with edge workers.

For all from one system, whatever you're using for your backend, be it React (with Next.js) or Ruby on Rails, can probably also serve any kind of static content, but it might not be worth intermingling that based on your situation.

You can also just hop on, without any planning, in Germany anyway, and the price will only be expensive, not outrageous.

An ICE is no different than a bus in this regard. A flight is a totally different story, probably planned weeks in advance and stress starts on the morning the day of.

I don't know of another way that reaches the same security model as secure httpOnly cookies, which are the recommended way to do session cookies.

I'm pretty sure what they are looking for is that something like a Link that takes a route name and a params object that are both typed.

I guess it's a matter of anecdotes. I certainly don't have enough data (one + a half apps with countless updates) to make any serious claims. For us google has been more trouble, but I've heard other bad stories about apple too.

I'm freshly frustrated because I'm dealing with a random metadata rejection (on an "internal testing" build! nothing has changed!) just now.

Google would just tell you that your app metadata does not comply with the Play Store terms of service and let you figure it out by trial and error.

Yeah, I've found App Store rejections to be harsh (functionality is not useful? ok) or restrictive, but always parseable. I even successfully asked the reviewer if a certain change would remedy the issue, they said yes, I resubmitted and that was that. Took about 2 days in all.

Play Store rejections are either an algorithmic mystery or reviewer incompetence. I don't mean reviewer incompetence in using the (maybe unintuitive) app. I mean their internal review UI had some kind of unrelated error and they sent me a screenshot of that. Their own console UI even sort of urges you to just resubmit with a potentially meaningless change instead of opening an appeal / request. Feels like it's the worst of both automatic and human review.

It's great, but I wish there was some more interesting stuff you could do with the results of that query, other than show an outline or table.

The inline programmability of DataView and the Grid views etc are pretty killer. Unfortunately Obsidian is not for me, so I hope Logseq catches up.

OmniOutliner has had some kind of formulas for a very long time, however they work like an actual spreadsheet, where each outline row can have additional number and formula columns.

I don't think it's all that useful, outside of some basic "making a shopping/packing/project list" type calculations. It's worth checking out if you're interested in the history though.

This is an impressively well stripped down app. It's all I ever wanted from OmniOutliner (remember when it shipped with OS X?).

Unfortunately, I've been drawn in by the linking functionality in Roam/Logseq and cannot go back to a simple outliner, though this makes me want to.

I don't think I'm a fan of the animated cursor while typing. It somehow makes the typing feel slower, like it takes some physical effort for the cursor to push forward.

Opipramol is a weird one. It's among the most prescribed anti-depressants in Germany (and other European countries), yet apparently non existent in the US.

Monolith + a database, that's always implied, isn't it?

How you make the database connection work with serverless connection requirements seems like a minor issue. I haven't used it but it seems like next + prisma (+ tailwind lol) is the default stack of tutorial writers these days.

Isn't an average next app pretty much a monolith? It gets split into lambdas when you deploy it, but the development experience feels monolithic to me.

If I want to use some function, I often just import it and call it directly, instead of calling one serverless function from another over http. That means the function gets bundled into a few lambdas, but so far, I've had no issues with that. The monolith abstraction hasn't really leaked for me.

Another moat they have is the number of data center locations.

I am as obsessed with sub 100ms responses as the people at fly.io, so I think the one writer and many, many readers architecture is smart and fits quite a few applications. When litestream adds actual replication it will get really exciting.

> it won't work well on ephemeral, serverless platforms or when using rolling deployments

That's... a lot of new applications these days.

Well, Heroku Postgres is more "managed" than fly who basically just hands you some nice tooling to do it your self. I don't think they set up backup for you. For me personally, Point-In-Time recovery is maybe the most important thing about managed PG.

Also worth a mention are the free tiers of the "cloud scale" SQL new kids Planetscale (MySQL/vitess) and CockroachDB (mostly postgres-compatible).

Then there is supabase which also includes a postgres DB and AWS where you can run a small RDS instance free for 12 months.

Heroku is the classic free db (and free app hosting). Fly.io is an alternative that also gives you both.

On heroku you can create a bunch of free small DBs and apps, and on fly it's 3 services (container or db node) per account I think, but unlike Heroku, your apps won't go to sleep.

Looks great. I would love to see some development tooling (if it's license allows), that I'm currently considering self hosting: Posthog, Sentry and Jitsu (aka EventNative). If Sentry setup is too insane maybe GlitchTip. I don't know if you run Clickhouse (needed for PostHog) yet, but I bet it will be used by a bunch of self hosted apps in the future and would be worth it.

A very attractive option would be some kind of "Try on PikaPods" button, if you can somehow muster a very limited free tier, that these projects can put on their READMEs. A few have that with heroku and it makes them way more approachable.

The pricing is very attractive compared to running these things e.g. on RDS+Fargate (~25x). Most people would probably run on Digital Ocean or Hetzner Cloud which is closer.

I too wish hasura supported query caching in OSS. Not sure if you need to rewrite exactly, though. You could put something like GraphCDN in front of it or write your own cache layer that works similar to GraphCDN.

What browser does that? Don't they usually stay on the same page while it loads and then switch right to the nw one?

Congratulations to Tailscale. Imagine how many times you can migrate to a new novel database architecture with that kind of money.

Hasura is a rock solid piece of software that does pretty much exactly the right thing for me. Performance exceeds expectations and it's never once crashed or been the source of a bug in years of use. "lighter" is not convincing. Directus looks cool in the CMS/no-code space, but as a backend API hub I don't see anything there that would tempt me over hasura.

I feel like they see themselves as a database management tool, but with just a few tweaks (good UI for working with relations), could be a FileMaker / Airtable contender.

Yeah I agree. Just the combination of opening in excel on double click and being dead simple to spit out from any software makes it a winner. It helps that it's usable in plain text too.

If it would have used ANYTHING other than half the world's decimal separator as a value separator, it would be a no brainer. If it had been .psv (pipe separated values) the edge cases would be so few that we could just ignore them.

The section about trusting dependencies, the scenario where they go away, version churn etc doesn't resonate with me in regards to react.

I don't know any project in JS-land that is more serious about semver, backwards compatibility and reliable upgrades than react. If facebook dropped the project tomorrow, Vercel alone could probably continue to maintain it well.

I feel like google does web component frameworks like it does messaging apps. Each new one is the silver bullet. I wouldn't build on any google web framework personally, even if it claims to be oh so simple and lightweight.