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.
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 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.
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.
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.
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
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.
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.