Readit News[1] https://go.googlesource.com/proposal/+/refs/heads/master/des...
Customers would love to pay the 30% Apple tax for security and the great selection of apps.
The app store isn't just about making more money, it's about enforcing privacy and security guidelines for apps through the review process and through checks for unauthorized api usage.
Apple's product is privacy; they view privacy as a premium feature worth paying for, and 3rd party app stores that are the wild west for privacy are antithetical to this.
Separately; the simulator is cool and very helpful!
Appreciate that's kinda the point of the site, but if it's a ghost town then it's clearly petered out.
I'd rather have (2) really insightful comments than 300 trying to promote themselves.
Looking at how it's deployed, as an in process database, how do people actually use this in production? Trying to figure out where I might actually want to think about replacing current databases or analyses with DuckDB.
EG if you deployed new code
1. Do you have a stateful machine you're doing an old school "Kill the old process, start the new process" deploy, and there's some duckdb file on disk that is maintained?
2. Or do you back that duckdb file in some sort of shared disk (Eg EBS), and have a rolling deploy where multiple applications access the same DB at the same time?
3. Or is DuckDB is treated as ephemeral, and you're using it to process data on the fly, so persisted state isn't an issue?
What about a real-world workload? For example, I have 10 users a day on my new next.js app so I clearly need a RDS cluster for burst traffic.
Can read more here: https://tailscale.com/blog/database-for-2022/
There is no silver bullet, just a lot of lead ones and the answer to Apple's quality problem is to begin baking QA back into the process in a meaningful way after letting it atrophy for the last decade or so.
Hire more humans and rely less on automation. Trust your developers, QA, and user support folks and the feedback they push up the chain of command. Fix bugs as the arise instead of assigning them to "future" or whatever. Don't release features until they're sufficient stable.
This is all basic stuff for a software company, stuff that Apple seems to have forgotten under the leadership of that glorified accountant, Cook.
In practice it's a challenge because the OS bundles a lot of separate things into releases, namely Safari changes are tied to OS changes which are tied to Apple Pay features which are tied to so on and so on.
It would require a lot of feature flagging and extra complexity which may reduce complexity.
Another way is to start un-bundling releases and fundamentally re-thinking how the dependency graph is structured.