- _1tem parentSecurity conscious domain. We do automations on behalf of our clients and they don't want credentials stored. "Handling" 2FA automatically is completely unacceptable, it breaks the entire point of the 2FA security model. Besides, login sometimes involves out-of-band 2FA methods including phone number.
- What about hybrid automations or human-in-the-loop flows? We have automations where the human starts by logging in, then hands over to the agent. Some parts may even be Puppeteer automated. This also means the session may be long running, typically for months at a time and the agent needs to notify the human again if they get logged out. None of the existing browser automation platforms I have tried make this easy or cost effective, so we are currently trying to build our own. Would love to consider Simplex if this is solved.
- It's not clear to me what a "container" and "pairing" is in this context. What if my application is not dockerized? Can Claude Code execute tests by itself in the context of the container when not paired? This requires all the dependencies, database, etc. - do they all share the same database? Running full containerized applications with many versions of Postgres at the same time sounds very heavy for a dev laptop. But if you don't isolate the database across parallel agents that means you have to worry about database conflicts, which sounds nasty.
In general I'm not even sure if the extra cognitive overload of agent multiplexing would save me time in the long run. I think I still prefer to work on one task at a time for the sake of quality and thoroughness.
However the feature I was most looking forward to is a mobile integration to check the agent status while away from keyboard, from my phone.
- This is not just for LLM code. This is for any code that is written by anyone except yourself. A new engineer at Google, for example, cannot hit the ground running and make significant changes to the Google algorithm without months of "comprehension debt" to pay off.
However, code that is well-designed by humans tends to be easier to understand than LLM spaghetti.
- I, as an engineer, absolutely support keeping private APIs private in order to preserve the performance of products. This is a good policy decision and a good engineering decision. Allowing others to build products on top of private APIs creates false user expectations. The user doesn't know the difference between a public or private API, they just expect their devices to work properly. If you allow a private API to be abused, then third parties may create crappy products (such as fake AirPods) which will ruin the battery life and security of Apple devices. The user doesn't know who to blame, Apple or the third party. It is absolutely within Apple's rights to protect their private APIs from misuse in order to preserve security and performance of their products for all users. The user is free to choose a different brand if they want interoperability. I, as an Apple user, want security and performance, not interoperability. If I wanted interoperability I would choose Android. The EU has no right to force Apple to become crappier like Android.
- It’s about the fact that opening your API limits your own engineering capabilities. A device with an open API has a different security and performance profile.
So Apple has to sabotage their own devices performance and security to let other people use it. The EU has no business in this.
If Apple provided public APIs for their products their own mobile devices battery life and security would be worse due to crappy third party integrations. Apple achieves high performance experiences precisely because that is a ENGINEERING REQUIREMENT to build high quality products.
- If we want to see what the actual impact on Apple’s market share would be if they pulled out of the EU market, consider Russia as a case study. Since Apple pulled out of Russia in 2022, the market share of iOS devices has remained steady and even slightly increased. Russia is comparatively poor, Apple would lose nothing if they pulled out of the EU because consumers would simply travel to other countries to buy.
Here’s a comparison of iOS share in Russia (mobile OS) between August 2025 vs August 2021, using StatCounter data:
• August 2025: iOS ~ 31.97 %
• August 2021: In 2021, the iOS share in Russia was about 27.52 % (for mobile OS) per StatCounter’s data.
- Few die hards? We have an actual case study: Russia. Apple does not sell in Russia anymore but market share has increased.
Here’s a comparison of iOS share in Russia (mobile OS) between August 2025 vs August 2023, using StatCounter data: • August 2025: iOS ~ 31.97 % • August 2023: iOS ~ 27 % (approximately) — StatCounter’s historical data shows iOS had around 26-28 % share in Russia in mid-2023
So between August 2023 and August 2025, iOS’s share in Russia appears to have increased by about 4–6 percentage points (from ~27% → ~32%).
- > It's trivial to get the same performance.
It’s literally impossible to build realtime audio apps with ultra low latency on Android. People have been trying for decades. Not trivial at all.
Microsoft and Google and open source devs have tried to build something as good as a MacBook Pro for decades and failed. Because the extremely high performance and polished experience comes from the highly integrated hardware and software stack that only Apple has. Precisely because it is not interoperable. I as an engineer prefer to support fewer devices and make the experience with those few devices better rather than support lots of devices and integrations but crappily.
- Evidence: Open source devs and Google and Microsoft have been trying to build MacBook Pro laptop performance for decades and failed. The entire performance advantage of Apple products is due to their tightly controlled integration of the hardware and software stack.
Apple consumers have come to expect this level of quality from Apple products. It is unreasonable for the EU to demand interoperability with other products when the very thing that makes Apple products work well depends on tight integrations that are not interoperable.
- It’s not about ease of implementation. It’s impossible to build Apple Silicon level of quality in power to watt performance or realtime audio apps over public APIs. Just look at how open source devs failed to fix battery issues with Framework Laptops or build realtime audio over Android. You can’t get Apple quality performance over a public api.
- The unstable driver issue exactly why Apple should not make devices interoperable as the EU demands. If they comply with the EU demand and then the device performance is bad due to crappy third party integrations, consumers will blame Apple. If consumers can buy Apple devices everywhere except the EU they will blame the EU not Apple.
- There is simply no good way to make the API public while maintaining the performance and quality expectations that Apple consumers have. If the third party device doesn’t work people will blame Apple even though it’s not their fault. Just like how consumers blamed Microsoft for BSODs even though it wasn’t their fault.
Edit: the evidence for my claim - just look at how realtime audio apps with tight latency requirements can’t work on Android
- > don't install artificial barriers to differentiate your products
Some barriers are not artificial. I’m am an engineer and many of Apple’s engineering feats are only possible due to highly controlled interfaces. See for example audio applications that have very high performance requirements, such as low latency audio. It is literally impossible to build this on Android due to the interoperability layer being too slow. Many useful features on Apple devices take advantage of the highly tuned performance that can only happen on devices in the same ecosystem. Take for example Live Translation on AirPods. It’s very hard to get the same level of performance over a public API. Lots of Apple Silicon advantages in battery usage come about due to their deep integration with all parts of the hardware stack — that level of performance would be impossible over an interoperable stack. This is not about walled gardens, this is about building better performing devices with better experiences. It is much harder, near impossible, to build Apple-quality experiences over third party hardware.
I am completely against artificial walled gardens and artificial barriers but I believe many of Apple’s strict barriers are real engineering performance advantages.
- The entire premise of Apple is building highly tuned private APIs. It’s what makes things like Apple Silicon battery performance and power to watt ratio possible. This kind of super fine tuning is practically impossible over a public API boundary, or at least much more difficult task. Take Live Translation for example. It has very tight latency and performance requirements which would be hard to make work over a public API where you can’t control the other device. Many types of audio applications are literally impossible to build on non-Apple devices due to the latency requirements. There is an entire audio ecosystem that cannot exist on Android due to the realtime performance requirements.
- EU consumers will travel to other countries or buy through second hand markets, which is what happens in Russia now. Apple will lose little revenue. Apple can easily spin this as a win to shareholders showing how much competitive advantage was preserved by not having to build the EUs interoperability demands.
In the end the EU consumer gains nothing from all of this but loses their beloved Apple devices.