A deep dive into the arguments offered by Apple and others to defend a lack of browser engine choice on iOS. Instead of raising the security floor, Apple has set a cap whilst breeding a monoculture that ensures all iOS browsers are vulnerable to identical attacks, no matter whose icon is on the home screen.
Here's a tiny sketch to help illuminate how web platform development _works_.
Mobile OSes and their most successful apps have drained browser choice of meaning for more than a decade. This has lead to confusion for users and loss of control over data. Web developers, meanwhile, face higher costs and reduced ability to escape walled gardens. It's time for the charade to end.
All the tutorials I found for Git Worktrees assumed detailed knowledge of Git internals. In case you, like me, never dug that deep here's a quick end-to-end shell transcript to get worktrees set up locally for an existing GitHub project.
Apple's iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store. This is a bold assertion, and proving it requires examining the record from multiple directions.
What if I told you that, at least for fully modern work, you don't need special-purpose state management tools and that you can -- to coin a phrase -- 'use the platform' instead? Turns out you can.
A lot has changed since 2017 we I last estimated a global baseline for total page resource limits of 120-170KiB. Thanks to progress in networks and browsers (but not devices), the new baseline is much more generous: ~100KiB of HTML/CSS/fonts and ~300-350KiB of JS. But the devil's in the footnotes, and modern web development practices push the median page well above these guidelines.