reporter

The Level Lock Pro is Level's latest smart lock, featuring Matter connectivity for Apple Home, multiple unlocking methods, door status, and the unassuming design that Level products are known for. I've tested and reviewed several great HomeKit-compatible smart locks, but Level Locks are my personal favorite because of the look. From both the inside and the outside, Level Locks look like a standard deadbolt and not like a smart lock. I had feature-rich smart locks from Aqara that I was using for about a year after a review, but I got tired of looking at the bulky boxes on my doors. A couple of months ago, I bought two standard Level Locks, and then later, Level sent me the Level Lock Pro. I don't think there's any smart lock solution that has a better aesthetic than the Level Lock, so if that's important to you, these are the locks to get. It comes in satin nickel and matte black, so it should match many standard doorknobs. The Level Lock Pro has an IP54 water and dust resistance rating, so it will hold up fine in the rain. Level Locks are not the cheapest locks on the market, and depending on what you're comparing against, there's a premium for design. The Level Lock Pro is $349, and the Level Lock is $249. Aqara locks range from $150 to $270, and Matter locks from Eufy, Yale, and Kwikset are in that same range. The Level Lock Pro replaces a standard deadbolt and strike plate on your door, so installation is a matter of pulling out the existing deadbolt and walking through the Level Lock Pro instructions to install the new lock. I am going to blame this on my crummy doors, but I have more trouble installing Level Locks than other smart locks. Level Locks have a wide, circular bolt that's not the shape of most deadbolts, and I haven't had a Level Lock setup where I didn't have to fuss with the fit of the lock in the door or the fit of the plate on the doorframe. I generally get things to work, but there's frustration involved. There are smart locks that can unlock your door with fingerprint sensors, palm recognition, facial scans, and codes, but the Level Lock Pro is simpler. You can use a key, one of the two included NFC key fobs, tap to unlock with your phone or watch, use the Home app or Level app, or ask Siri to unlock the door. The Level Lock Pro integrates with HomeKit using Matter, and it also supports Apple Home Key so you can store a key in the Wallet app on iPhone or Apple Watch. With Home Key, I can unlock my door without having to unlock my iPhone and with no need for Face ID. I just tap my phone or my watch on the lock, and it unlocks. ‌Siri‌ and the Home app work for unlocking too, and there's a Level app. I don't use the Level app, but it is available for locking and unlocking, assigning codes, setting up auto lock and auto unlock (which uses Bluetooth and unlocks when you're in range), adjusting sound, giving someone a door code, and enabling door status. Like the Level Lock, the Level app has an uncomplicated design, so it's easy to get to all of the features. Door status is a Level Lock Pro feature that lets you know if your door is open or closed, and it works when the door is unlocked. I have the Level Lock Pro on my garage door, and it's a door that's often not locked, so it's useful to get an alert when it's opened. I use the Home app and ‌Siri‌ to unlock my Level Locks, especially if I'm not home and need to let someone in. I also ask ‌Siri‌ to open the door as I approach, so a lot of the time, I'm not even using tap to unlock. The Home app sends a notification to my iPhone and Apple TV when a connected lock is locked or unlocked, and the Home app Activity log keeps track of when each door was locked or unlocked. Everyone that's invited to an Apple Home can access the lock, but you can also share access with the Level app. The Level app supports temporary entry, which is useful for a one-time event or a weekly cleaning. The Home app is also useful for automations, like locking up automatically when everyone leaves the home or unlocking the door at a certain time. I have an automation that locks all my locks at 10:00 p.m., just in case I forget to lock one of the doors. For remote access features, you need a Matter-over-Thread controller and a border router, which are requirements fulfilled by a HomePod or ‌Apple TV‌. You need one of those to add any Matter-enabled device to ‌HomeKit‌. The Level Lock Pro connects to Apple Home using Thread instead of Wi-Fi, but if you want Wi-Fi connectivity, there is an optional Level Connect Wi-Fi Bridge. I haven't needed it because ‌HomeKit‌ provides all of the same functionality. You can also add on a keypad if you want that option. Most smart locks have a battery in the box that goes on the door, but the Level Lock Pro's battery is in the deadbolt. It uses a CR2 Lithium battery, which fits inside the deadbolt once the cap is taken off. Changing the battery is a matter of opening the door, locking it, popping out the old battery, and adding in the new one. The Level app lets you know battery status, so you can keep tabs on when it's time to update the battery. Each battery lasts for about a year, and I haven't had to change mine yet. According to Level, the Level Lock Pro has an ANSI Grade 1 bump- and pick resistant cylinder, which isn't common for smart locks. That means it's resistant to lockpicking, it's harder to drill out, and lock bumping is harder. How to Buy The Level Lock Pro is available from the Level website or from Amazon.com for $349. Note: Level provided MacRumors with Level Lock Pro for the purpose of this review. No other compensation was received. Tag: Apple Home This article, "Level Lock Pro Review: An Apple Home Key Smart Lock That Doesn't Look Like One" first appeared on MacRumors.com Discuss this article in our forums View the full article

Apple's beautiful Passeig de Gràcia store in the heart of Barcelona reopened today, after being closed for around three months for renovations. According to the Spanish blog Applesfera, the store's large video wall has been replaced with a dedicated Apple Pickup station for online orders. The indoor trees and wood cube seats that surrounded the screen have also been removed. With these fixtures removed, the store's iconic glass staircase is more visible again. In addition, the store's terrazzo floor has received a brighter white finish. Apple Passeig de Gràcia's main floor after remodeling (via Applesfera) Apple Passeig de Gràcia first opened in 2012, and it is one of the company's flagship retail locations. The store is on one of the most popular avenues in Barcelona, inside a historic former bank building with a stunning stone facade.Tag: Apple Store This article, "Apple's Beautiful Barcelona Store Reopens With Pickup Station and More" first appeared on MacRumors.com Discuss this article in our forums View the full article

Apple plans to hold an Apple Watch Activity Challenge to celebrate Global Running Day on Wednesday, June 3. To complete the challenge, Apple Watch owners will be required to record a running workout of at least 5K on Global Running Day. On June 3, the world runs as one. This Global Running Day, record a running workout of at least 5K (3.1 mi) to earn this award. Use the Workout app or any app that records workouts to Health. As a reward, Apple Watch owners can unlock a dedicated award in the Fitness app, plus animated stickers that can be used in the Messages app. Apple has been celebrating Global Running Day since 2024, and it comes after the April 2026 Earth Day and International Dance Day Activity Challenges.Related Roundup: Apple Watch 11Tag: Activity ChallengeBuyer's Guide: Apple Watch (Caution) This article, "Earn a Running Day Apple Watch Activity Award on June 3" first appeared on MacRumors.com Discuss this article in our forums View the full article

Apple's iOS 26.6 update appears to add new wording around blocked contact limits, though it is unclear if the actual limits have changed. Code in the beta suggests users will get a warning if they exceed the maximum number of blocked contacts. "You've reached the maximum number of blocked contacts. To block additional callers, remove a blocked contact in Settings," reads the alert, which is titled "Blocked Contacts Limit Reached." Based on discussions on social media and Apple's Support Communities, some users have been unable to block additional contacts after hitting a 20,000 limit. Other people have mentioned running into issues after 8,000, and some have experienced issues with even fewer phone numbers blocked. Apple does not offer documentation on blocking limits. With limits in the thousands at least, it's unlikely most people have had blocking problems, though a person who is blocking spam callers regularly could eventually hit a cap. iOS 26.6 might make it clearer when a limit has been reached, and what to do about it. Removing older blocked contacts is the solution, which can be done by going to Settings > Apps > Phone > Blocked Contacts. There is no bulk unblocking tool, and the easiest way to remove a contact is to swipe left on each entry. Alternatively, you can select Edit, tap on the red minus button next to each contact, and choose the unblock option. iOS 26 added an Ask Reason for Calling option that sends calls from people who aren't in your Contacts directly to voicemail, which is an easier option for spam call management than blocking phone numbers. With the feature turned on, a caller can state their reason for calling and the person receiving the call can decide whether to pick up. Alternatively, all calls from unknown numbers can be silenced and sent to voicemail with no alert using the Silence option. Missed calls and voicemails from unknown callers can also be filtered into a separate Unknown Callers list in the Phone app. Some carriers also offer a separate spam detection option that can send calls from known spammers to the Spam list. Apple seeded the first beta of iOS 26.6 to developers today, and the software may soon be made available to public beta testers. A public release is likely several weeks away. So far, there are no other known features in iOS 26.6.Related Roundups: iOS 26, iPadOS 26Related Forum: iOS 26 This article, "iOS 26.6 Will Alert You When You've Maxed Out Blocked Contacts" first appeared on MacRumors.com Discuss this article in our forums View the full article

Apple today provided the first beta of an upcoming macOS Tahoe 26.6 update to developers for testing purposes, with the update coming two weeks after Apple launched ‌macOS Tahoe‌ 26.5. Developers can download the ‌macOS Tahoe‌ 26.6 update by opening up the System Settings app, selecting the General category, and then choosing Software Update. Beta Updates will need to be enabled, and a free developer account is required. With macOS 27 set to be unveiled in less than a month, Apple is likely focusing most of its attention on the new software. We are not expecting any major new features in ‌macOS Tahoe‌ 26.6. The beta is limited to developers right now, but a public beta is expected in the next week or two.Related Roundup: macOS TahoeRelated Forum: macOS Tahoe This article, "First macOS Tahoe 26.6 Beta Now Available for Developers" first appeared on MacRumors.com Discuss this article in our forums View the full article

Apple today seeded the first betas of upcoming iOS 26.6 and iPadOS 26.6 updates to developers for testing purposes, with the software coming two weeks after Apple released iOS 26.5 and iPadOS 26.5. Registered developers can download the betas from the Settings app on the iPhone or iPad by going to the General section and selecting Software Update. With the debut of iOS 27 approaching in early June, Apple is wrapping up work on iOS 26. We are not expecting any major new features in the iOS 26.6 update, and it will likely focus on bug fixes and performance improvements. Related Roundups: iOS 26, iPadOS 26Related Forum: iOS 26 This article, "Apple Seeds First iOS 26.6 and iPadOS 26.6 Betas to Developers" first appeared on MacRumors.com Discuss this article in our forums View the full article

Apple today provided developers with the first betas of upcoming watchOS 26.6, tvOS 26.6, and visionOS 26.6 betas for testing purposes. The software two weeks after Apple launched the 26.5 versions of each platform. The software updates are available through the Settings app on each device, and because these are developer betas, a free developer account is required. There's no word on what's in the software as of yet. watchOS, tvOS, and visionOS often get few features in each new beta, with updates primarily focusing on bug fixes and performance improvements. Apple will likely provide public beta testers with access to the tvOS 26.6 and watchOS 26.6 betas in a week or two, but visionOS 26.6 will remain limited to developers.Related Roundups: Apple TV, Apple Vision Pro, watchOS 26Buyer's Guide: Apple TV (Don't Buy), Vision Pro (Neutral)Related Forums: Apple TV and Home Theater, Apple Vision Pro, Apple Watch This article, "Apple Releases First watchOS 26.6, tvOS 26.6 and visionOS 26.6 Betas" first appeared on MacRumors.com Discuss this article in our forums View the full article

Android manufacturers are planning to adopt Apple's split launch strategy, releasing high-end and standard models in separate windows rather than simultaneously, according to the leaker known as "Digital Chat Station." The leaker made the claim in a new post on Weibo this week, saying the "Android camp may repeat this style of play" with Pro series and standard models launching separately in a move to "comprehensively go head-to-head" with Apple. The leaker described it as a move to "fully benchmark" Apple, suggesting the motivation is competitive rather than logistical. The same post reiterated earlier predictions about Apple's plans. Starting this year, Apple is widely expected to break from its long-standing September release cycle by splitting the iPhone 18 lineup across two windows: the iPhone 18 Pro, ‌iPhone 18 Pro‌ Max, and the first foldable iPhone are expected to launch in fall 2026, while the standard ‌iPhone 18‌, iPhone 18e, and a second-generation iPhone Air are expected in spring 2027. Digital Chat Station attributed the delay partly to supply pressure on memory and 2nm chip production, which is an explanation consistent with Nikkei Asia's corroborating report in January, which also cited a deliberate commercial motive to maximize revenue from premium models before cheaper alternatives arrive. Supply chain analyst Ming-Chi Kuo and The Information have also supported the rumor of the split launch. Kuo framed the strategy as a way to prevent "diluted marketing efforts" as Apple's lineup expands to six devices and to address the "marketing gap" created by Chinese Android brands that typically launch their flagships in the first half of the year, a window Apple has historically ceded entirely to Android. If Android brands do adopt the same release plan, it would mark a noticeable departure from current practice. Samsung, Apple's most direct competitor, launches its Galaxy S flagship family, standard, Plus, and Ultra, simultaneously each February or March, then launches foldables in a separate mid-year event in July. All tiers of the S series ship together and there is no equivalent of deliberately holding the base model back. Xiaomi regularly launches flagship models in China several months before a global rollout, and its Ultra-tier models often arrive weeks or months after standard and Pro variants within the same generation. Oppo and Vivo similarly stagger Ultra devices relative to their base flagships, but in each case the split is led by entry level models debuting first, followed by high-end devices. Should Android manufacturers adopt Apple's new plan, it would largely represent an inversion of the current approach, with premium models leading and standard devices following months later.Tags: Android, Digital Chat Station This article, "Android Brands May Copy Apple's New Split iPhone Launch Strategy" first appeared on MacRumors.com Discuss this article in our forums View the full article

For many years now, it has been rumored that the Apple Watch will eventually gain non-invasive blood sugar monitoring capabilities, which would enable millions of people with diabetes to track their blood glucose levels without needing to prick their skin with a needle or wear a dedicated continuous glucose monitor. According to Bloomberg's Mark Gurman, Apple recently shifted oversight of the project from its platform architecture chief Tim Millet to Zongjian Chen, a senior engineer overseeing advanced technologies within the company. He framed this change as positive news for the project, which has apparently been in development for more than 15 years. "Some view the transition as a sign the work may finally be progressing to a point where Chen, known as someone who delivers, can ramp up development of the technology into an eventual consumer-grade offering," he said. In 2023, Gurman reported that Apple's system would rely on a laser that would emit light under the skin to determine a person's blood glucose level. "The system uses lasers to emit specific wavelengths of light into an area below the skin where there is interstitial fluid — substances that leak out of capillaries — that can be absorbed by glucose," he said. "The light is then reflected back to the sensor in a way that indicates the concentration of glucose." An algorithm would ultimately determine a person's blood glucose level, and the feature could also alert users to potential signs of prediabetes. While the project has new leadership, the Apple Watch is still unlikely to gain non-invasive blood sugar monitoring for several more years, if ever. But if Apple eventually achieves this moonshot, the Apple Watch would provide diabetic people with a more comfortable and convenient solution for keeping track of their blood sugar.Related Roundup: Apple Watch 11Tags: Bloomberg, Mark GurmanBuyer's Guide: Apple Watch (Caution) This article, "Apple Watch for Diabetes: The Latest on Apple's Plans for Non-Invasive Blood Sugar Monitoring" first appeared on MacRumors.com Discuss this article in our forums View the full article

The Pro iPhone models are unlikely to return to titanium in the near future due to the heat dissipation demands of local AI, according to a known Weibo leaker. The claim comes from the leaker known as "Fixed Focus Digital," and pushes back on an earlier report from "Instant Digital," who suggested Apple was weighing up the use of liquid metal or an improved titanium alloy as a longer-term replacement for aluminum iPhone frames. Fixed Focus Digital argues that aluminum's thermal properties make it the only practical choice for now, given the processing requirements of AI features. The leaker adds that this is not an Apple-specific issue, noting that Android and Huawei HarmonyOS devices also prioritize aluminum for the same reason. Instant Digital's earlier report argued that Apple's switch from titanium to aluminum for the iPhone 17 Pro was a compromise solution while it continued to develop longer-term alternatives. The leaker claimed Apple was exploring both liquid metal and revised titanium alloys for future Pro models, with both materials reportedly already earmarked for the upcoming foldable iPhone. Apple switched away from titanium following overheating complaints on the iPhone 15 Pro and iPhone 16 Pro models, although the iPhone Air continues to use it. Fixed Focus Digital's assessment suggests aluminum is more deeply entrenched in Apple's plans than Instant Digital's framing implied, at least for the foreseeable future. The iPhone 18 Pro is expected to retain the same aluminum unibody design as the iPhone 17 Pro models, meaning any material change is unlikely before 2027 at the earliest.Tag: Fixed Focus Digital This article, "Leaker Pushes Back on Rumors of Pro iPhone's Return to Titanium" first appeared on MacRumors.com Discuss this article in our forums View the full article

While the iPhone 18 Pro and iPhone 18 Pro Max are not launching until September, there are already plenty of rumors about the devices. It was initially reported that the iPhone 18 Pro models would have fully under-screen Face ID, with only a front camera visible in the top-left corner of the screen. However, the latest rumors indicate that only one Face ID component will be moved under the screen on the devices, which will result in merely a smaller Dynamic Island. Below, we have recapped 10 features rumored for the iPhone 18 Pro models, as of May 2026:Dark Cherry: The special color for the iPhone 18 Pro models will reportedly be Dark Cherry, alongside Light Blue, Dark Gray, and Silver. The existing Cosmic Orange and Deep Blue colors are expected to be discontinued. Smaller Dynamic Island: It has been rumored that Face ID's flood illuminator will be moved under the screen on the iPhone 18 Pro models, paving the way for a smaller Dynamic Island on the devices. LTPO+ Displays: The next Pro models are expected to have the same overall design as the iPhone 17 Pro models, including 6.3-inch and 6.9-inch display sizes and a "plateau" housing three rear cameras. However, the displays will reportedly use so-called LTPO+ display technology, which should contribute to longer battery life. Variable Aperture: The main 48-megapixel Fusion camera on both iPhone 18 Pro models is rumored to have a variable aperture, which would allow users to control the amount of light that passes through the camera's lens and reaches the sensor. This would provide greater control over depth of field. However, given that iPhones have smaller image sensors due to smartphone size constraints, it is unclear exactly how meaningful this improvement would be. A20 Pro Chip: Apple's next-generation A20 Pro chip is expected to use TSMC's first-generation 2nm process, whereas the A19 Pro chip is 3nm. With a 2nm architecture and a new packaging design, the A20 Pro chip should deliver solid year-over-year performance and power efficiency gains. C2 Modem: Apple's custom C1 cellular modem for 5G and LTE debuted in the iPhone 16e last year, and that was followed by a C1X chip in the iPhone Air. Apple says the C1X modem is up to twice as fast as the C1 modem, and the most power-efficient modem in an iPhone ever. The improvements should continue with Apple's third-generation C2 modem in the iPhone 18 Pro models. 5G via Satellite: With the C2 modem, the iPhone 18 Pro models will reportedly support 5G via satellite for web browsing without Wi-Fi or cellular connectivity. N2 Chip: Most of the iPhone 17 models and the iPhone Air are equipped with an Apple-designed N1 chip that enables Wi-Fi 7, Bluetooth 6, and Thread. Apple says the N1 chip also improves the overall performance and reliability of features like Personal Hotspot and AirDrop. iPhone 18 Pro models are expected to have Apple's next-generation N2 chip, but it is not yet known what improvements would come with this upgrade. Simplified Camera Control: Apple is expected to simplify the Camera Control button on the iPhone 18 Pro models, by removing touch sensitivity and haptic feedback. The redesigned button will only have pressure sensitivity. Redesigned Rear Ceramic Shield: The rear Ceramic Shield area for MagSafe is rumored to feature a more frosted and seamless appearance on the iPhone 18 Pro models compared to the current two-tone design.Apple is expected to release the iPhone 18 Pro, iPhone 18 Pro Max, and a foldable iPhone in September, followed by a standard iPhone 18 model, a lower-end iPhone 18e, and a second-generation iPhone Air early next year.Related Roundup: iPhone 18 Pro This article, "iPhone 18 Pro Launching Later This Year With These 10 New Features" first appeared on MacRumors.com Discuss this article in our forums View the full article

Amazon today has introduced a new record low price on the 512GB 13-inch M5 MacBook Air, available for $899.99, down from $1,099.00. This deal is available in all colors and as of writing only Amazon has the discount. Note: MacRumors is an affiliate partner with Amazon. When you click a link and make a purchase, we may receive a small payment, which helps us keep the site running. This new price is about $50 cheaper when compared to past sales. Amazon also has $149 off the 1TB models of the 13-inch M5 MacBook Air, which match all-time low prices on these devices. Delivery dates vary depending on the color selected, but most will arrive before the end of the month. $199 OFF13-inch M5 MacBook Air (512GB) for $899.99 If you're on the hunt for more discounts, be sure to visit our Apple Deals roundup where we recap the best Apple-related bargains of the past week. Deals Newsletter Interested in hearing more about the best deals you can find in 2026? Sign up for our Deals Newsletter and we'll keep you updated so you don't miss the biggest deals of the season! Related Roundup: Apple Deals This article, "Apple's M5 MacBook Air Hits New Low Price of $899.99" first appeared on MacRumors.com Discuss this article in our forums View the full article

Earlier this year I mass-migrated my blog to Astro using Claude Code. 146 posts. 6,024 images. Canonical URLs, JSON-LD markup, sitemap generation, the whole stack. I’d spent hours writing a skills file to teach the agent about my blog’s architecture, how deployment worked, what not to touch. And it worked. Claude Code rewrote components, fixed trailing-slash mismatches across hundreds of pages, added BreadcrumbList structured data to hundreds of routes. Lighthouse scores hit 97 on performance. The blog looked better than it ever had. The problem was that I had stopped understanding my own codebase. Not completely. I could still read the files. But somewhere around the third round of “fix the error that the last fix introduced,” I caught myself copy-pasting stack traces back into Claude and trusting whatever came back. The agent would make a change, something else would break, I’d ask the agent to fix that too, and a few cycles later the blog worked again. I couldn’t have told you what was actually in the PostCSS config or why the GA4 integration was wired up the way it was. It worked. It looked great. My confidence in what was underneath had quietly evaporated. That feeling (it works, thank god, let’s not touch it) is the feeling of having given an autonomous agent real access to your codebase. Every developer using these tools knows it. Nobody writes about it in vendor blog posts. And it’s what made me understand, on a level deeper than reading documentation, why Docker had to build Sandboxes. Because here’s what I hadn’t thought about: while Claude Code was rewriting my Astro components and fixing image CLS across hundreds of files, every npm install it ran happened on my laptop. Same for every file it modified and every package it pulled. My user privileges, no boundary in sight. If the agent had decided to modify a Git hook or rewrite a CI workflow, I would not have noticed. I wasn’t reviewing individual file changes at that point. I was reviewing outcomes. And reviewing outcomes while skipping changes is not a security model. It’s a prayer. Docker Sandboxes exists to close that gap. The container model and why it doesn’t stretch here Containers were never the wrong abstraction. They were the right abstraction for a world where you knew what was inside them. For twelve years that world held: you wrote the code, you reviewed it, you put it in a Dockerfile, and the container gave it a clean room to run in. Shared kernel was fine because the threat model was bugs in your own software, not surprises from a tenant you’d just invited in. AI coding agents don’t fit. They aren’t bugs in your software because they aren’t your software. They’re a new kind of tenant, one that’s autonomous and privileged in ways that would make any security engineer nervous. The agent installs packages you didn’t pick and runs commands you didn’t script. It makes network calls you’d never have predicted, to endpoints you didn’t know were in your dependency tree. The trust profile is code being written right now, by something that won’t pause to ask permission. Containers were built for a different kind of code. This isn’t hypothetical. On March 19, 2026, attackers force-pushed 76 of the 77 version tags in aquasecurity/trivy-action and published a malicious Trivy v0.69.4 binary to GitHub Releases. The exposure window was about 12 hours. The compromised code scraped CI runner memory for secrets, cloud credentials, SSH keys, and Kubernetes tokens, exfiltrating them to a typosquatted domain. Every pipeline that referenced trivy-action by version tag during that window ran code nobody on the receiving end had reviewed. What gets me about Trivy: the weaponized tool was a vulnerability scanner. The thing organizations deployed to find malicious code became the malicious code. The maintainers didn’t write the bad binary; a compromised CI workflow with too much access and not enough containment did. Substitute “compromised CI workflow” with “AI agent in permissive mode” and you have the same threat model, running all day on every developer machine. Containers were the right answer to “I trust this code, I want to run it cleanly.” They were never going to be the right answer to “I don’t fully trust this code, and I want to give it real work to do anyway.” That’s the gap microVMs fill. What Docker built, and why each piece is there First choice: don’t patch containers. There’s a long tradition in our industry of making a familiar abstraction handle a new problem by adding flags to it. Privileged mode, capability dropping, seccomp profiles, gVisor in front of runc. All of those have their place. None of them solved the specific issue that an autonomous agent needs its own Docker daemon. Docker-in-Docker either compromises the isolation (privileged mode, host socket mounting) or creates a nested complexity that becomes its own attack surface. The Docker docs are blunt about this. Containers, they say, share the host kernel and “can’t safely isolate something that needs its own Docker daemon.” Once you accept that, you end up at a VM. Not a heavyweight one (booting Ubuntu Server for every coding session would be absurd) but a microVM: light enough to start in seconds, with just enough kernel to run the agent’s containers. Docker Sandboxes uses a custom VMM, not Firecracker. If you’ve read the Firecracker spec and you’re thinking “boots in 125ms with under 5MB of overhead,” those are Firecracker’s numbers, not Docker’s. Different microVM implementations have different cost profiles. Platform specifics: Hypervisor.framework on macOS, Windows Hypervisor Platform on Windows, KVM on Linux. Caption: The Sandbox architecture. Each microVM runs its own kernel and its own Docker Engine. Credentials never cross the VM boundary. Inside each microVM, the sandbox runs a complete Docker Engine. When the agent runs docker build, that command goes to a private daemon that doesn’t know your host containers exist. When it pulls an image, the image lives inside the sandbox VM. When you delete the sandbox, the entire image cache goes with it. Multiple sandboxes don’t share layers. Wasteful. Worth it. The first time I looked inside a running sandbox, the agent was running as root with sudo and full Docker Engine access inside the VM. My reflex was that this had to be wrong. You don’t give root to untrusted code. But the design is right: the isolation model doesn’t constrain what the agent does inside the boundary. It constrains where the consequences land. Inside the VM, the agent can do whatever it wants. Outside? Nothing. Trying to lock the agent down with capability dropping inside the VM would be solving the wrong problem. The agent legitimately needs to install packages and run docker build. What it doesn’t need is for any of that to touch your laptop. Caption: From the host, sandboxes don’t show up in docker ps because they aren’t containers; sbx ls is how you see them. The network layer is where it gets interesting, because it doubles as the credential boundary. Outbound HTTP/HTTPS traffic routes through a proxy on the host, accessible from inside the VM at host.docker.internal:3128. UDP and ICMP are blocked at the network layer and can’t be allowed by policy. Non-HTTP TCP (like SSH) needs explicit IP+port rules. DNS resolution goes through the proxy. If a request can’t go through the proxy, it doesn’t leave. The proxy terminates TLS, inspects the host header, applies your policy, and re-encrypts with its own certificate authority that the sandbox trusts. Man-in-the-middle by design. Docker uses that exact framing in the documentation. MITM is what makes credential injection work. Agents need API keys: for the AI provider, for registries, sometimes for cloud accounts. Naive answer is to pass those credentials in as environment variables, where they sit inside the VM and follow it everywhere. Docker instead keeps credentials on the host, in your OS keychain, and has the proxy inject them into outbound requests transparently. The agent sees requests that just work, and the VM never had the secrets to begin with. The docs don’t hedge on this: credential values are never stored inside the VM. A compromised sandbox can’t exfiltrate your API keys because your API keys were never in there. Docker tells you what won’t work Sandboxes documentation has a quality that’s rare in security architecture docs: it tells you what the system doesn’t protect against. Most of these documents are written to make a product look strong. Docker’s docs surface the limits. Two of them matter. The first one is about the network policy. At first sbx login, you pick one of three default policies. Open allows everything except blocked CIDR ranges (private networks, link-local addresses, cloud metadata endpoints). Balanced denies by default but pre-allows common dev domains. Locked Down denies everything until you explicitly allow. Locked Down is the strictest option, the deny-by-default mode you’d want if you were paranoid. But even with Locked Down and a curated allowlist, the proxy filters by domain, not by content. Here’s the exact language from the docs: allowing broad domains like github.com permits access to any content on that domain, “and agents could use these as channels for data exfiltration.” Security vendors don’t usually say this about their own products. If github.com is on your allowlist (and it almost certainly is, because the agent needs to clone repos), the proxy knows the request is going to github.com. It does not know whether the agent is reading documentation, cloning a repository, or creating a public gist with the contents of your .env file. All three look identical at the domain level. Same goes for every allowlist entry that includes user-generated content: Discord webhooks, Notion pages. “The domain is allowed” doesn’t mean “only safe content lives there.” Caption: Under a deny policy, non-allowlisted domains are blocked. Allowlisted domains succeed, including domains that host arbitrary user-generated content. Docs also acknowledge domain fronting as an inherent limitation of HTTPS proxying. Proxy sees which domain a request claims to be going to; it cannot always prevent the request from being routed elsewhere through that allowed CDN. The microVM boundary is the primary isolation. Network proxy is a useful additional control, especially for blocking accidental access to internal networks. It is not a hermetic seal, and Docker doesn’t claim it is. “The agent is on a deny policy” is not the same thing as “the agent cannot send data anywhere.” The workspace is always shared Network policy is the smaller honest limit. Workspace sharing is the bigger one. The microVM boundary is strong everywhere except for one path that crosses it on purpose: the workspace directory. The whole point of running an agent in a Sandbox is for the agent to do real work in your real codebase. Docker shares the workspace between the host and the sandbox at the same absolute path. When the agent edits a file inside the sandbox, the file changes on your host. When you pull a new commit on your host, the agent sees it. This is the design. It’s exactly what you want from a developer tool. It’s also a covert channel that the agent has legitimate write access to. Docker security documentation spells out what “the same files” includes, and this is what matters: files that execute implicitly during normal development. Git hooks. CI configurations. IDE task definitions. Makefile targets. package.json scripts. Pre-commit configs. Anything that runs when you do something that feels like just “using your tools.” Simplest version of the attack: an agent inside the sandbox writes a malicious post-commit hook to .git/hooks/post-commit. Git hooks don’t appear in git diff. They live in .git/, which most developers never open. Next time you commit on your host, the hook runs on your host with your user privileges. Sandbox boundary doesn’t matter, because the boundary ended at the workspace, and the workspace was always shared. Which brought me back to my own Astro migration, uncomfortably. I’d let Claude Code rewrite hundreds of files across my blog. I’d reviewed the outcomes (Lighthouse scores, visual appearance, build success) but I had not audited every file it touched. Had not checked .git/hooks/. I’d never opened that directory in my life. Had not read every package.json script before running npm install. I’d been doing exactly the thing the documentation warns about: treating the agent’s output as reviewed code when it was unreviewed code that I was about to execute on my machine. It would be easy to read this as “Sandboxes are broken.” That’s not what I mean. The microVM does exactly what microVMs are supposed to do: it contains the consequences of arbitrary code execution behind a hardware boundary. What it cannot do is make the workspace contents safe, because the workspace contents are how the agent does its job. The agent has to be able to write files. You have to be able to read them. Shared region is necessary, and the shared region is where the threat model gets interesting. Mitigation isn’t more isolation. The microVM is doing its job. Mitigation is discipline: treat the workspace contents the way you’d treat a pull request from a contributor you don’t know yet. Diff .git/hooks/ after agent sessions. Read package.json scripts before running npm install. Use the --branch flag, which creates a Git worktree so the agent works in an isolated branch you can review before merging. None of this is exotic. It’s just the practice of not treating autonomous-agent output as trusted code. Because it isn’t. I’m spending this much space on it because it’s the part most people get wrong. Hypervisor boundary makes you feel safe, but you aren’t. Not completely. Both things have to be true at once for the product to work, and the Docker team built it that way on purpose. Good security architectures document their gaps and make sure the user knows what they’re signing up for. What it actually costs Hypervisor isolation isn’t free, and you can’t pretend otherwise. I tested this against my own production codebase, the same Astro blog I mentioned at the top, because synthetic benchmarks for sandboxed agent workloads don’t tell you much. You want to know what it feels like to do real work. Caption: The same docker build --no-cache against the same Astro codebase. Host: 1:44.62. Sandbox microVM: 1:28.58. The isolation boundary is invisible to the workload. On this run, the sandbox actually finished faster. I ran docker build --no-cache against the same Dockerfile and the same codebase, once on the host and once inside the sandbox. Host finished in 1:44.62. Sandbox finished in 1:28.58, actually faster, within noise across runs. The Docker Engine inside the sandbox is running on its own kernel with its own block device, completely isolated from the host, and the build doesn’t care. The microVM adds essentially zero overhead to the actual build. One real-world caveat from running this on Apple Silicon: a Rust dependency in my Astro pipeline ships jemalloc that assumes 4K page sizes, which fails on sandbox VMs (16K pages). The build itself completed correctly. All 354 pages rendered, dist generated, but a teardown step exited non-zero. The fix was a one-line guard in the Dockerfile that checks for valid build output before exiting. Took 30 minutes to track down. Worth knowing about before you ship sandbox-aware Dockerfiles on Apple Silicon, because the symptom looks like a build failure when the build actually succeeded. Verdict: for session-based agent work (a few hours on a project), the overhead disappears. For high-frequency sandbox creation (dozens per minute for short tasks), cold-start cost adds up. For the workload Sandboxes is designed for, which is giving an agent a real environment for a real session, the trade is sound. Matching isolation to trust Most discussions of containers versus VMs treat it as a binary, and that’s the wrong frame. The frame I’ve found useful, both for my own work and in conversations with engineering leaders who ask “do we really need microVMs for this?”, is a spectrum. Caption: The Trust Spectrum. Match isolation strength to the trust profile of the workload. On one end you have code you wrote yourself. Your team reviewed it, your CI tested it, your production runs it. A standard container is the right answer. Kernel is shared, daemon is shared, and none of that matters because the workload is known. One step removed from that are CI/CD pipelines running your team’s code plus dependencies from registries you mostly trust. Mostly known, but the inputs are more variable. You add seccomp profiles, drop capabilities, write network policies. Further along, supervised AI agents: tools that suggest code while a developer reviews each step. Human in the loop, so hardened containers with strict policies still work. At the far end are autonomous AI agents. Nobody reviewing each command. Agents making decisions on your behalf, each one potentially different from the last. The trust profile isn’t “I trust this code” because there’s no fixed code to trust. It’s “I’m letting something operate on my system without supervision, and I want the failure mode to be ‘contained to a disposable VM’ rather than ‘on my laptop.'” That’s the workload that needs a microVM. This is not a declaration that containers are obsolete. It’s the opposite. Containers are the right answer for everything on the left side of that spectrum, which is most of what runs in production today. MicroVMs extend the spectrum to the right, where containers were never going to be the right tool. The four isolation layers in Sandboxes (hypervisor, network, Docker Engine, credential proxy) are additive. They wrap containers in additional protection rather than replacing them. Inside every Sandbox is a microVM that runs containers. Containers haven’t gone anywhere, they’ve moved one level deeper in the trust stack. “MicroVMs for AI agents, containers for everything else” is too crude. “Match the isolation to the trust profile of the workload” is the one that holds up. Why everyone is converging here Docker isn’t the only company that arrived at this answer, and the convergence tells you something. Firecracker powers AWS Lambda and Fly.io’s microVM platform. gVisor intercepts syscalls in a user-space kernel. Kata Containers provides VM isolation behind a container-compatible interface. Modal runs serverless agent workloads on gVisor. E2B offers Firecracker-based sandboxes as a managed cloud service. Northflank ships Kata-based isolation for production AI workloads. All adopted at the same time, for the same reasons. Architecture everywhere looks the same: containers on the inside (because that’s how developers think), VM on the outside (because that’s where the boundary needs to be). Docker Sandboxes is the local-first version. Most alternatives are cloud services where you pay per execution and your code runs on someone else’s machines. Docker put the same architecture on the developer’s laptop. CLI supports eight agents natively (Claude Code, Codex, Copilot, Gemini CLI, Kiro, OpenCode, Docker Agent, and Droid), plus a Shell mode for custom tooling. A standalone sbx CLI runs without Docker Desktop, so the architecture isn’t locked to a commercial product. MicroVM layer has an HTTP API that the open-source community has already started building on. That’s a runtime. And Docker is positioning it to become the standard way to run autonomous coding agents, the way docker run became the standard way to run microservices ten years ago. One more thing. Hardened Images and sandboxes address different layers of the same problem: Hardened Images for the supply chain (where binaries come from), sandboxes for runtime isolation (what those binaries can touch). Both exist because the assumption that “code from a trusted publisher is safe” stopped being reliable. Looking back, looking forward I’ve watched the industry rebuild its trust model three times in twenty years. Bare metal to virtual machines, because we needed to put multiple workloads on the same hardware safely. Virtual machines to containers, because we needed faster startup, lower overhead, and a packaging model that matched how developers actually ship code. Now, containers to a different kind of virtual machine, because the workload changed and the kernel namespace stopped being enough. Not because containers were wrong, but because the new tenant needs more, and more looks like a hypervisor again. Each of these transitions felt obvious in hindsight and contested at the time. I remember the arguments about whether containers were really secure enough for multi-tenant workloads. (They mostly weren’t, which is why we ended up with namespaced clusters and per-tenant VMs and gVisor and now microVMs for agents.) I expect the microVM argument to follow the same arc: contested for about a year, obvious within three. My Astro migration taught me what it feels like to work alongside an autonomous agent that has real access to your system. More productive than doing it by hand, and more unsettling than I expected, once I realized how much I’d stopped tracking. Sandboxes don’t make the agent trustworthy. It just makes sure that when the agent does something you didn’t expect, the damage stays inside a box you can throw away. Workspace still requires your attention. Your skepticism. That combination (strong boundaries where you can enforce them, disciplined review where you can’t) is the model for working with autonomous code, and it’s probably going to stay that way for a while. If you’ve been holding back on running AI coding agents because of permission prompts, accidental file changes, or just a feeling that something about the whole arrangement isn’t quite safe: that feeling was correct. Containers were the wrong fit for the workload. Sandboxes is the right one. Try it on a project you actually care about. That’s the only test that matters. Get started with Docker Sandboxes → View the full article

Apple's first foldable iPhone is running into mass production yield problems at the pre-assembly stage, the leaker known as "Fixed Focus Digital" claims. In a post today on Weibo, Fixed Focus Digital said Apple's troubles are not related to hinge reliability, as was previously reported, but rather due to surface-mount technology (SMT) during pre-assembly, with production yields failing to ramp up. The leaker framed the situation as somewhat concerning, stopping short of suggesting the fall launch is at risk. The update arrives days after a separate leaker known as "Instant Digital" reported that the device's hinge was consistently failing to meet Apple's quality control standards under conditions of prolonged, high-frequency opening and closing. Instant Digital described that issue as one that "must be resolved with absolute perfection," though a follow-up post suggested the hinge difficulties were unlikely to affect the expected release window. DigiTimes reported in April that production was already running roughly one to two months behind schedule, while still maintaining that a fall 2026 launch remained on track, with mass production planned to begin in July. Fixed Focus Digital reported in April that price negotiations with Apple's assembly partner were a potentially disruptive factor. Whatever the precise nature of the problems, the picture that has emerged across multiple supply chain sources in recent weeks is one of unusual production difficulties. That said, a fall launch does not appear to be at risk; Bloomberg's Mark Gurman reported in April that the foldable iPhone remains on track for a September debut alongside the iPhone 18 Pro models, and that Apple is aiming to put it on sale at roughly the same time or slightly later. Gurman noted at the time, however, that "the release is six months away and production has yet to ramp up" and "the timing isn't final." The foldable iPhone is expected to feature a 7.8-inch inner display and a 5.5-inch cover display, the A20 chip and C2 modem, a Touch ID power button instead of Face ID, and two rear cameras, with pricing rumored at around $2,000.Tags: Fixed Focus Digital, Foldable iPhone This article, "Foldable iPhone Reportedly Facing Mass Production Issues" first appeared on MacRumors.com Discuss this article in our forums View the full article

Introduction In my two decades of working with engineering teams, I have seen brilliant engineers struggle not because they lacked technical skill, but because they lacked a cohesive framework. We often talk about tools—Kubernetes, Jenkins, Terraform—as if they are the silver bullet for DevOps success. However, installing a tool is simple. Changing how an organization thinks, communicates, and delivers value is the real challenge. Many organizations fail at DevOps because they view it as a project or a software installation. It is not. It is a fundamental shift in how IT organizations operate. This is where the CALMS framework becomes critical. Whether you are a student just entering the field or an IT manager tasked with transforming your department, understanding CALMS is the difference between implementing DevOps and actually living it. If you are looking to master these principles, resources like DevOpsSchool provide structured learning paths that go beyond the theory and into real-world application. Understanding the CALMS framework allows you to diagnose why your pipelines are stalling, why silos exist between your development and operations teams, and how to start moving toward a more mature, reliable, and collaborative engineering culture. Let us break down exactly what this means and how you can apply it today. What Is the CALMS Framework? The CALMS framework is a mental model used to assess and improve an organization’s DevOps maturity. It was coined by Jez Humble, one of the authors of the seminal book The DevOps Handbook. In simple terms, CALMS is a diagnostic tool. If you look at your organization and feel that things are slow, error-prone, or disconnected, you can hold your current process up against the five pillars of CALMS to see exactly where the breakdown is occurring. It shifts the focus away from “which tools are we using” toward “how are we working.” It originated from the realization that DevOps is not a product you can buy; it is a philosophy. By assessing your organization against these five pillars, you can map out a transformation journey that is sustainable and scalable. What Does CALMS Stand For? The acronym CALMS stands for Culture, Automation, Lean, Measurement, and Sharing. Each component represents a critical dimension of a high-performing DevOps team. LetterMeaningPurposeReal-World ExampleCCultureCreates a shared mindsetBlameless post-mortems after an outageAAutomationReduces manual toilUsing CI/CD pipelines to deploy codeLLeanMinimizes wasteBreaking large features into small releasesMMeasurementTracks progressMonitoring error rates and deployment speedSSharingBreaks down silosInternal wiki for tribal knowledge Why the CALMS Framework Matters in DevOps Without a framework like CALMS, DevOps initiatives become random acts of automation. You might have a great CI/CD pipeline, but if your culture is one of fear and blame, developers will still be afraid to deploy frequently. CALMS matters because it addresses the systemic nature of software delivery. It ensures that you are not just optimizing one part of the pipeline while ignoring the others. It promotes a holistic view of the software development lifecycle, ensuring that engineering, operations, and business goals are aligned. C = Culture Explained Simply Culture is the most important, and often the hardest, part of the CALMS framework. It is the “software” that runs on the “hardware” of your team. Breaking Silos In traditional IT, developers wrote code and threw it over the wall to operations. The operations team, responsible for stability, would then be incentivized to block changes. Culture in CALMS is about breaking that wall. It promotes shared ownership: “You build it, you run it.” Shared Accountability When a system fails, a healthy culture does not look for a person to punish. Instead, it looks for the process that allowed the failure to happen. This is the hallmark of a high-trust, high-performance engineering environment. A = Automation Explained Simply Automation is the engine of DevOps. However, automation for the sake of automation is a trap. You should only automate processes that are stable and repeatable. Reducing Toil Manual, repetitive tasks are a drain on engineering morale and a source of human error. Automation allows you to shift your engineers’ focus from “keeping the lights on” to “building new features.” Essential Tools CI/CD: Jenkins, GitHub Actions, GitLab CI. Infrastructure as Code (IaC): Terraform, Ansible. Orchestration: Kubernetes, OpenShift. Workflow Example: Instead of manually configuring a server, use Terraform to provision the environment. This ensures the infrastructure is consistent, version-controlled, and reproducible. L = Lean Explained Simply Lean comes from the manufacturing world, specifically Toyota’s Production System. In DevOps, Lean is about optimizing the flow of value from the developer’s laptop to the customer’s screen. Removing Waste Waste in software development includes waiting for approvals, context switching, and large, infrequent releases that cause merge conflicts. Lean encourages smaller, more frequent batches. If you deploy ten small changes a day, a bug is easier to isolate than if you deploy one massive change once a month. Faster Feedback By shortening the time between a code commit and the user seeing the result, you get faster feedback. This allows you to pivot quickly if the feature is not working as intended. M = Measurement Explained Simply You cannot improve what you do not measure. Measurement in CALMS is about visibility and data-driven decision-making. Key Metrics Deployment Frequency: How often do you ship code? Lead Time for Changes: How long does it take from commit to production? Mean Time to Recovery (MTTR): How fast can you fix a system when it breaks? Measurement keeps the team honest. It helps you move away from gut feelings and toward objective reality. When you have a dashboard showing your metrics, the conversation shifts from “I think we are doing well” to “Our deployment frequency has increased by 20 percent this month.” S = Sharing Explained Simply Sharing is the glue that holds the framework together. It involves the free flow of information across the organization. Knowledge Management If only one person knows how a critical system works, you have a single point of failure. Sharing involves creating a culture of documentation, regular brown-bag sessions, and cross-team rotations. Collaboration Sharing is not just about writing documentation; it is about cross-functional collaboration. When developers, operations, and security teams work in the same Slack channels or shared project management boards, they share the context, the constraints, and the success. Real-World Example of CALMS in Action Imagine an e-commerce company struggling with slow deployments and frequent outages. They decide to adopt the CALMS framework: Culture: Management shifts from individual performance metrics to team-based goals. They implement blameless post-mortems. Automation: They implement a CI/CD pipeline. Every code commit automatically triggers tests and deploys to a staging environment. Lean: The team stops doing bi-monthly “big bang” releases. They move to daily releases of small, incremental features. Measurement: They set up a dashboard to track deployment frequency and incident rates. Sharing: The team starts a “knowledge share” session every Friday to discuss technical challenges and successful fixes. Within six months, the team is deploying daily, outages are resolved faster, and the engineers are happier. CALMS Framework vs Traditional IT Practices Traditional ITCALMS FrameworkSiloed teams (Dev vs. Ops)Cross-functional collaborationManual, error-prone processesHigh levels of automationLarge, infrequent releasesSmall, continuous releasesFear of failure/Blame cultureLearning from failure/Psychological safetyReactive monitoringProactive, data-driven observability Benefits of the CALMS Framework Better Team Collaboration: Reduces friction and finger-pointing between departments. Faster Releases: Automation and Lean principles accelerate the path to production. Higher Reliability: Measurement and automation lead to more stable systems. Reduced Downtime: Faster recovery times thanks to better visibility and automated rollback capabilities. Improved Customer Experience: Users get new features and fixes faster. Common Challenges While Implementing CALMS Resistance to Change: People are naturally comfortable with the status quo. Start small and demonstrate quick wins. Lack of Automation Knowledge: Teams may not know where to start. Invest in training and upskilling. Poor Communication: Silos are hard to break. Start with cross-team meetings or shared project boards. Weak Measurement Systems: You cannot measure what you do not track. Start with one simple metric, like deployment frequency. How Beginners Can Apply CALMS Principles If you are new to the field, start here: Step 1: Learn Collaboration: Offer to sit in on a meeting with another team. Learn their language. Step 2: Practice Automation: Automate a single, annoying manual task. Write a script to back up a file or verify a system state. Step 3: Understand Lean Thinking: Look for “waiting” time in your own work. What is blocking you? Step 4: Learn Monitoring Basics: Install a simple monitoring tool on your personal projects. Look at the graphs. Step 5: Practice Knowledge Sharing: Write down how you solved a specific technical problem and share it with your peer group. Role of CALMS in Modern Cloud-Native Engineering In the age of Kubernetes and microservices, CALMS is more important than ever. Cloud-native systems are inherently complex. Without Culture, teams will not communicate the complexity. Without Automation, you cannot manage hundreds of containers. Without Lean, you will drown in configuration debt. Without Measurement, you will not know which service is causing the latency. And without Sharing, the complexity of the microservices architecture will be impossible to maintain. Role of DevSecOps in the CALMS Framework DevSecOps is the natural extension of CALMS. It integrates security into every step: Culture: Security becomes everyone’s responsibility, not just the “security team’s” problem. Automation: Automated security scanning is built into the CI/CD pipeline. Lean: Security checks are performed early and often, not as a gate at the end. Measurement: Security vulnerabilities are tracked just like bugs. Sharing: Security knowledge is shared across development and operations teams. Common Beginner Mistakes Focusing Only on Tools: Buying expensive software without fixing the process is a waste of money. Ignoring Collaboration: You can automate everything, but if you don’t talk to each other, you will automate the wrong things. Weak Monitoring Knowledge: Guessing at what is wrong during an outage is a recipe for disaster. Avoiding Documentation: “The code is the documentation” is a myth. Write down how things work. Best Practices for Applying the CALMS Framework Encourage Collaboration: Create environments where people feel safe to suggest changes. Automate Repetitive Work: If you do it more than twice, automate it. Measure Everything Important: Focus on metrics that impact the customer and the team’s efficiency. Share Learning Regularly: Celebrate failures as learning opportunities. Continuously Improve Workflows: Never settle for “good enough.” Small, daily improvements compound over time. Industries Benefiting from the CALMS Framework Banking & Finance: Benefits from improved reliability, auditability, and regulatory compliance through automation and measurement. Healthcare: Leverages CALMS for faster, safer delivery of critical patient-care applications and secure data management. E-Commerce: Uses the framework to handle high traffic spikes and deploy updates rapidly without downtime. SaaS Platforms: Relies on CALMS to maintain uptime and innovate faster than competitors. Telecom: Uses automation and Lean principles to manage massive, complex network infrastructures. Enterprise IT: Adopts CALMS to modernize legacy systems and break down rigid internal silos. Career Opportunities for Professionals Understanding CALMS Organizations are actively seeking professionals who understand the why behind DevOps, not just the how. DevOps Engineer: Focuses on the “Automation” and “Measurement” aspects. Cloud Engineer: Leverages CALMS to build scalable, automated cloud infrastructures. SRE (Site Reliability Engineer): Deeply involved in “Measurement” (reliability) and “Sharing” (post-mortems). Platform Engineer: Builds internal tools that enable other teams, effectively “Sharing” infrastructure capabilities. DevSecOps Engineer: Integrates security into the CALMS framework. Industry demand for these roles is surging because companies know that a tool-only approach to DevOps is a losing strategy. Certifications & Learning Paths To implement CALMS effectively, you need hands-on skills. The learning ecosystem at DevOpsSchool is designed to bridge the gap between theoretical knowledge and practical execution. CertificationBest ForSkill LevelFocus AreaDevOps FoundationBeginnersEntryCulture & PrinciplesCI/CD Pipeline EngineerIntermediateIntermediateAutomationCloud-Native ArchitectAdvancedExpertAutomation & ArchitectureSRE ProfessionalAdvancedExpertMeasurement & Reliability Future of the CALMS Framework The CALMS framework is evolving. We are seeing: AI-Assisted Automation: AI is helping us write code, optimize configurations, and even predict outages. Platform Engineering: A shift toward treating internal developer platforms as products (perfectly aligned with the Sharing principle). DevSecOps Maturity: Security is becoming truly “invisible” in the pipeline. GitOps Adoption: Using Git as the single source of truth for infrastructure, which is a perfect intersection of Culture, Automation, and Sharing. FAQs 1. What is the CALMS Framework? It is a mental model that helps teams assess and improve their DevOps maturity by focusing on Culture, Automation, Lean, Measurement, and Sharing. 2. What does CALMS stand for? Culture, Automation, Lean, Measurement, and Sharing. 3. Why is CALMS important in DevOps? It moves the focus from tools to the human and process elements of DevOps, ensuring that transformation efforts are holistic and sustainable. 4. Is automation mandatory in CALMS? Automation is essential for speed and reliability, but it is just one of the five pillars. It must be balanced with culture and measurement. 5. What is Lean in CALMS? Lean is about eliminating waste and optimizing the flow of work to deliver value to the customer faster. 6. Why is measurement important? Measurement provides the data needed to make informed decisions and proves that your improvements are actually working. 7. Can beginners learn CALMS? Absolutely. It is a mindset that can be applied at any stage of your career, from intern to architect. 8. Is CALMS useful in DevSecOps? Yes, it is fundamental to DevSecOps, as it emphasizes the culture of shared security and automated compliance. 9. How do I start with Culture? Start by fostering psychological safety. Encourage teams to discuss failures openly without fear of retribution. 10. What is the role of Sharing? Sharing ensures that information, best practices, and lessons learned are distributed across the organization, preventing knowledge silos. 11. Is CALMS a replacement for Agile? No, it is complementary. Agile focuses on how work is planned and managed, while CALMS focuses on how it is delivered and operated. 12. How often should we measure? Measurement should be continuous. Use automated dashboards to get real-time insights into your performance metrics. 13. Does CALMS apply to small startups? Yes. Even a two-person team can benefit from Lean principles and a culture of shared ownership. 14. What if management resists CALMS? Show them the data. Start small, get a win, measure the improvement, and present the results to leadership. 15. Can I use CALMS in a non-tech team? The principles of collaboration, removing waste, and measuring success are applicable to almost any business function, from marketing to HR. Final Thoughts The CALMS framework is not just another corporate acronym. It is a reality check for the modern engineering team. In my experience, the biggest bottleneck in DevOps is never the code; it is the friction between people and the lack of clarity in our processes. If you focus on Culture, you will create a team that wants to innovate. If you embrace Automation, you will free up time for that innovation. If you apply Lean, you will deliver value faster. If you leverage Measurement, you will know exactly how you are performing. And if you practice Sharing, you will build an organization that learns and grows together. Do not try to force all five pillars at once. DevOps is a journey of continuous improvement. Start by looking at your team’s current friction points and pick one CALMS pillar to focus on this month. You will be surprised at how quickly small, intentional changes can transform your delivery capability. View the full article

Ferrari today unveiled the Luce, its first fully electric car designed with help from Apple's former design chief Jony Ive. "Designed with Sir Jony Ive and Marc Newson at the creative collective LoveFrom, a singular design language unites the exterior, interior, and interface with clarity and refined simplicity throughout," said Ferrari. The exterior of the car has a "smooth, continuous, and uninterrupted" design, with a "shell-like form" and "floating front and rear aerodynamic wings." The interior has "precision-engineered mechanical buttons, dials, toggles, and switches" combined with "multifunctional digital displays." The three-spoke steering wheel is machined from 100% recycled aluminum. The four-door, five-seat Luce is powered by four electric motors providing up to 1,035 horsepower, and it is equipped with a high‑capacity 122 kWh battery. Ferrari says the car can accelerate from 0-100 km/h (0-62 mph) in just 2.5 seconds. A dedicated app offers climate controls and charging settings, and it displays the car's status. Luce pricing starts at €550,000 ($640,000) in Europe, with production set to begin in late 2026. The car will launch in the U.S. in the second quarter of 2027. Tags: Ferrari, Jony Ive, LoveFrom This article, "Ferrari Reveals $640,000 EV Co-Designed by Jony Ive" first appeared on MacRumors.com Discuss this article in our forums View the full article

Introduction In the current landscape of software engineering, the pressure to deliver high-quality code at an unprecedented speed is constant. As systems grow more complex, the distance between writing code and running it in production has created significant friction. Traditionally, development teams focused on feature velocity while operations teams prioritized stability, creating isolated silos that often led to bottlenecks, finger-pointing, and delayed releases. To bridge this gap, organizations are adopting a culture of shared responsibility. This is where DevOps team collaboration becomes the cornerstone of successful modern engineering. By aligning goals, automating repetitive tasks, and fostering transparent communication, teams can transform their delivery process from a disjointed struggle into a cohesive, high-velocity engine. Whether you are looking to refine your current workflows or are just starting your journey, resources at DevOpsSchool provide essential insights into mastering these practices. Effective collaboration is not just about tools; it is about how people work together to solve technical challenges. In this guide, we will explore the tangible ways DevOps fosters teamwork and why this approach is essential for any modern technology organization. What Is DevOps Team Collaboration? At its core, DevOps team collaboration is the practice of breaking down the artificial barriers between different technical groups. It is the transition from a “throw it over the wall” mentality to a culture of collective ownership. When a team embraces this, developers, operations personnel, security experts, and QA engineers stop functioning as separate entities. Instead, they operate as a unified, cross-functional unit. Collaboration in DevOps is built on three pillars: Shared Ownership: Every member of the team is responsible for the health of the application, from the first line of code to the final deployment. Constant Feedback: Information flows freely between teams, ensuring that issues are caught early and addressed collectively. Unified Goals: The focus shifts from individual metrics (like “code committed”) to team outcomes (like “system uptime” and “user satisfaction”). For a beginner, think of it as moving from playing an individual sport to being part of a well-oiled relay team. Everyone knows their role, but the goal is to get the baton across the finish line safely and efficiently. Why Collaboration Matters in Modern Software Delivery Software delivery is no longer just about writing code; it is about managing an ecosystem. Without strong collaboration, even the most talented engineers can struggle to overcome the friction of manual handoffs and conflicting priorities. Key benefits include: Faster Issue Resolution: When developers have visibility into production monitoring and operations teams understand the application architecture, troubleshooting becomes a team effort rather than a frantic scavenger hunt. Improved Deployment Reliability: Collaboration ensures that the environment in which code is written is the same as where it is deployed, reducing “it works on my machine” syndromes. Reduced Operational Friction: By communicating early about changes, teams avoid the stress of midnight deployments and the chaos of unexpected system outages. Traditional Team Silos Before DevOps Before the widespread adoption of DevOps, the standard operational model was defined by “silos.” In this environment, development teams were incentivized to release new features as quickly as possible. Conversely, operations teams were incentivized to keep the system stable and were often punished for any downtime. Typical Pain Points: The Blame Culture: When an incident occurred in production, the immediate reaction was to determine which team was at fault. Manual Handoffs: Developers would finish their work and submit a ticket to the operations team to deploy it. This created a queue and often led to misconfigurations. Delayed Feedback: If a security flaw or a performance issue was discovered in production, it took weeks or months for that information to travel back to the development team. This separation hindered progress and turned the software development lifecycle (SDLC) into a stop-and-go process. How DevOps Breaks Team Silos DevOps actively dismantling these walls by restructuring how teams interact. It replaces manual, gate-kept processes with transparent, automated workflows. Strategic Changes Include: Shared Responsibilities: Operations teams now assist in the design phase, while developers are encouraged to understand the production infrastructure. Unified Communication: By using shared platforms, everyone has visibility into the current state of the application and the pipeline. Transparency: Every change, deployment, and incident is logged in a system accessible to all, removing the mystery of “what happened.” Role of Automation in Team Collaboration Automation is the engine that drives DevOps collaboration. It removes the human element from repetitive, error-prone tasks, freeing up engineers to focus on higher-level problem solving. Core Automation Areas: CI/CD Pipelines: Tools like Jenkins, GitHub Actions, and GitLab CI/CD ensure that code is tested, built, and deployed consistently. This means no one is wondering if the current deployment package is “the right one.” Infrastructure Automation: With tools like Terraform, teams define their environment as code. This allows everyone to see exactly how the infrastructure is configured, eliminating manual configuration drift. Automated Testing: By running unit and integration tests automatically, teams get immediate feedback on whether their code is ready for the next stage, fostering a culture of high quality. CI/CD Pipelines and Collaborative Workflows A CI/CD pipeline acts as the central meeting point for different teams. It is a shared “source of truth.” When a developer pushes code to a shared repository, the pipeline triggers a series of automated steps. Collaborative Workflow Example: Code Commit: Developer writes code. Automated Build: The CI tool compiles the code. Automated Test: The pipeline runs unit tests. If they fail, the developer is notified instantly. Security Scan: Automated tools check for vulnerabilities. Deployment: The code is deployed to a staging environment where QA can verify it. This pipeline provides a visual status that everyone on the team can monitor, ensuring transparency at every step. Shared Monitoring and Observability In a collaborative DevOps environment, monitoring is not just for the operations team. Using tools like Prometheus, Grafana, the ELK Stack, or Datadog, teams gain shared operational visibility. When an alert fires, the entire team sees the same data. This eliminates the need for one team to “translate” the problem for another. They can look at the same dashboards to understand the performance of the system, making root-cause analysis faster and more accurate. DevSecOps and Collaborative Security Practices Security should never be an afterthought. DevSecOps integrates security into the very beginning of the development process. Instead of having a security team run a manual audit at the end of the project, automated security checks are embedded directly into the CI/CD pipeline. By treating security as a shared responsibility, developers become more aware of secure coding practices, and security teams become partners in the development lifecycle rather than roadblocks. Infrastructure as Code and Team Collaboration Infrastructure as Code (IaC) is one of the most powerful tools for collaboration. Tools like Terraform, Ansible, and CloudFormation allow infrastructure to be treated exactly like application code. Because it is version-controlled, any team member can propose changes via a Pull Request. This allows for peer reviews of infrastructure changes, ensuring that everyone is aware of the modifications and that best practices are maintained. Kubernetes and Cloud-Native Collaboration Kubernetes has become the standard for managing containerized applications, and it inherently encourages collaboration through its declarative nature. With Kubernetes, developers and operations teams agree on a manifest file that describes the desired state of the application. The cluster automatically works to maintain that state. This creates a shared language between those writing the code and those maintaining the infrastructure. Agile and DevOps Collaboration Agile and DevOps are natural partners. While Agile focuses on how teams plan and organize work, DevOps focuses on how that work is delivered and operated. Integrating them involves: Sprint Collaboration: Operations teams participate in sprint planning to ensure that operational requirements are accounted for from the start. Continuous Feedback Loops: Retrospectives become a space to discuss not just project progress, but also improvements to the deployment pipeline and operational stability. Real-World Example of Collaborative DevOps Workflow Imagine an e-commerce platform updating its checkout service: Planning: Development and Operations discuss the impact of the new feature on system resources. Development: Developers commit code using a feature branch. Automation: The CI/CD pipeline runs unit tests, integration tests, and security scans automatically. Review: QA and Security engineers review the test reports directly in the shared repository. Deployment: Using IaC, the environment is provisioned, and the update is deployed to a staging environment. Monitoring: Once in production, all teams monitor key metrics via a shared Grafana dashboard. Optimization: Based on real-time feedback, the teams meet to discuss further performance improvements. Benefits of DevOps Team Collaboration Increased Productivity: Automation reduces the time spent on manual toil. Faster Time-to-Market: Efficient workflows mean features reach customers sooner. Higher Quality: Automated testing ensures that errors are caught early. Improved Employee Satisfaction: Teams feel more empowered and less burdened by manual, repetitive tasks. Common Collaboration Challenges in DevOps ChallengeSolutionResistance to ChangeFocus on small wins and demonstrate value through data.Tool ComplexityAdopt tools that integrate well and provide clear documentation.Lack of CommunicationImplement daily stand-ups and transparent, shared dashboards.Skill GapsInvest in training and promote a culture of shared learning. Best Practices for Improving DevOps Team Collaboration Cultivate a “No-Blame” Post-Mortem Culture: Focus on learning from failures rather than assigning blame. Standardize Tooling: Use a common set of tools that everyone can access and understand. Prioritize Documentation: Keep infrastructure and process documentation up to date. Foster Cross-Training: Encourage team members to learn skills outside their primary domain. DevOps Collaboration vs Traditional IT Collaboration FeatureTraditional IT TeamsDevOps CollaborationCommunicationSiloed and ticket-basedOpen and continuousDeployment OwnershipOperations onlyShared responsibilityAutomationMinimal or fragmentedHigh and integratedMonitoringReactive and limitedProactive and observableFeedback CyclesSlow and infrequentFast and continuousSecurity InvolvementEnd-of-cycle auditIntegrated throughoutScalabilityManual and slowAutomated and dynamic Popular Tools Supporting DevOps Collaboration ToolPurposeTeam UsageDifficultyGit/GitHubVersion ControlAll teamsEasyJenkins/GitLabCI/CDDevelopers/OpsModerateSlack/TeamsCommunicationAll teamsEasyPrometheusMonitoringOperations/DevModerateTerraformIaCOps/PlatformHighSonarQubeSecurityDev/SecurityModerate Industries Benefiting from DevOps Team Collaboration Banking & Finance: Benefits from high compliance and security standards through automated audits. Healthcare: Benefits from high availability and reliable data management. E-Commerce: Benefits from rapid release cycles to match market trends. SaaS Platforms: Benefits from continuous delivery and rapid scaling. Career Opportunities Related to DevOps Collaboration The rise of DevOps has created a high demand for professionals who understand both technical automation and collaborative culture. Key roles include: DevOps Engineer: Focuses on bridging development and operations through automation. Platform Engineer: Builds the internal tools that make collaboration easy for other developers. SRE (Site Reliability Engineer): Applies software engineering principles to infrastructure and operations. DevSecOps Engineer: Specializes in securing the entire software delivery pipeline. Certifications & Learning Paths CertificationBest ForSkill LevelFocus AreaCKA (Kubernetes)Cloud EngineersIntermediateContainer OrchestrationAWS/Azure CertsCloud ArchitectsBeginner/IntCloud InfrastructureDevOps ProfessionalAll Team MembersAdvancedEnd-to-End DevOps To build these skills effectively, look for structured guidance through the DevOpsSchool ecosystem, which offers practical training paths for these technologies. Common Beginner Mistakes Tool Obsession: Focusing on learning specific tools before understanding the collaborative philosophy. Ignoring Fundamentals: Skipping Linux, networking, or scripting basics. Avoiding Team Interaction: Working in isolation, which is the antithesis of DevOps. Poor Monitoring: Building great pipelines but failing to observe what happens after deployment. Future of DevOps Collaboration The future of collaboration lies in AI-assisted operations and Platform Engineering. As systems become more autonomous, the role of the human engineer is shifting toward designing better collaborative systems and managing automated intelligence. GitOps—managing infrastructure through version control—will continue to deepen the collaboration between developers and operators. FAQs What is DevOps team collaboration? It is a practice of breaking down silos to ensure development, operations, and other teams work together with shared responsibility. Why is collaboration important in DevOps? It leads to faster deployments, fewer errors, and a more stable environment. How does DevOps improve communication? By providing shared tools, transparent processes, and frequent feedback loops. What role does automation play in collaboration? It removes manual handoffs and provides a shared, consistent workflow for everyone. Is DevSecOps part of collaboration? Yes, it integrates security into the team’s shared responsibilities. Why is monitoring important for teams? It provides a shared view of system health, allowing for faster incident resolution. Which tools improve DevOps collaboration? Version control systems, CI/CD platforms, and shared dashboards. Is DevOps a good career path? Yes, it is highly in demand and offers significant growth potential for those who master both technical and soft skills. How do I start collaborating? Begin by understanding your team’s current bottlenecks and suggesting small, automated solutions. Do I need to be a developer? No, DevOps is about cross-functional skills, making it suitable for both developers and operations engineers. How does Infrastructure as Code help? It allows infrastructure changes to be reviewed and managed by the whole team. What is a “no-blame” culture? It is a environment where focus is on fixing systemic issues rather than blaming individuals. Can small teams use DevOps? Yes, the principles of automation and shared responsibility are scalable to teams of any size. How do I learn more? Explore DevOpsSchool for resources and training paths. Is DevOps a destination? No, it is a journey of continuous improvement and learning. Final Thoughts DevOps is ultimately about people. While the tools—the pipelines, the monitoring dashboards, and the cloud infrastructure—are impressive, they are only as effective as the culture that supports them. As an engineering mentor, I have seen many organizations fail not because their technology was lacking, but because their teams remained isolated. The real power of DevOps lies in the shift toward collective ownership and open communication. It is about understanding that when we share the responsibility for our software, we inevitably build better, more resilient systems. Focus on continuous learning, embrace automation, and always prioritize the health of the entire delivery lifecycle over individual tasks. Success in the modern era requires a commitment to being a team player as much as being a skilled engineer. View the full article

Reports and rumors suggest the next MacBook Pro that Apple will release might not be a ‌MacBook Pro‌ at all. It could actually be something altogether new and more exciting – a "MacBook Ultra" – positioned above the Pro as Apple's top-tier laptop, suggesting that the current M5 Pro and M5 Max models will remain on sale when it launches. The MacBook would be just the latest Apple product to carry the Ultra name, which already spans the Apple Watch Ultra and CarPlay Ultra (not forgetting Apple's top-end Ultra-designated silicon chips). This is likely to bring a markedly higher price point for the new machines. It fits into a broader trend at Apple, where the company is seeking to offer more models at more price points, such as the new MacBook Neo at an unprecedented $599 price point. Below, we've listed the features we are expecting in the MacBook Ultra, which is likely to go on sale either later this year or in early 2027. As things stand, the latter time frame is now looking more likely, owing to the global memory chip shortage. OLED Display Bloomberg's Mark Gurman and analyst Ming-Chi Kuo say Apple is readying OLED technology for these models, and industry reports corroborate their claims. Samsung Display is said to be making the panels, and the supplier has invested heavily in an 8.6-generation OLED production line in South Korea. The line recently reached a key milestone for mass production. The MacBook Pro will utilize hybrid OLED technology, similar to that used in Apple's latest iPad Pro. This display technology combines a glass substrate with thin-film encapsulation, offering improved brightness, contrast, and power efficiency compared to current MacBook Pro models, which use LCD displays with mini-LED backlighting. Touch Screen The new ‌MacBook Pro‌ is expected to become the first Mac to support touch input directly on the display. It's a notable shift from Apple's longstanding position against bringing touchscreen functionality to the Mac. Apple previously experimented with touch controls through the OLED Touch Bar on earlier ‌MacBook Pro‌ models, but the feature was ultimately discontinued following a lukewarm reception. Rather than positioning the ‌MacBook Pro‌ as a touch-centric device like the ‌iPad‌, Apple is reportedly planning to let users move seamlessly between touch and traditional trackpad or mouse input across the system. This will require updates to macOS to make it more touch friendly, and users will reportedly be able to tap or click on-screen elements, and controls will change based on input method. If a user taps on a menu bar item, for example, it will display a larger set of controls optimized for touch. Thinner Design Gurman has reported that Apple is working to make the OLED MacBook Pro significantly thinner, as part of the company's plan to create "the thinnest and lightest products in their categories across the whole tech industry." (Think the latest iPad Pro and iPad Air – two of the thinnest devices the company has ever made.) Indeed, the reporter has said there's a good chance that the next MacBook Pro model will represent a "true overhaul" for the laptop, thanks to the combination of the OLED display and thinner design. Notably, the MacBook Pro got thicker and heavier with its most recent redesign in 2021. A major highlight was the reintroduction of several ports that were removed in previous iterations in favor of chassis thinness. How Apple will make its redesigned MacBook Pro thinner without removing the functionality it reintroduced fairly recently is the big question. Dynamic Island Apple's highly anticipated OLED MacBook Pro could ditch the current notch for a display cutout potentially similar to the iPhone's Dynamic Island, according to Bloomberg. Such a move would mirror Apple's iPhone evolution, since the iPhone's notch became the current Dynamic Island starting with the iPhone 14 Pro models in 2022. As with the iPhone‌, the Mac ‌Dynamic Island‌ will be interactive and it will contextually expand based on the app or Mac feature in use. The change should address long-standing user complaints about the notch, which physically ingresses into the macOS menu bar. M6 Processor Architecture The redesigned MacBook Pro models are expected to boast M6 Pro and M6 Max chips, which could adopt a completely new packaging based on TSMC's 2nm process that allows components such as the CPU, GPUs, DRAM, and Neural Engine to be more tightly integrated. Terms like "3nm" and "2nm" describe generations of chip manufacturing technology, each with its own set of design rules and architecture. As these numbers decrease, they generally indicate smaller transistor sizes. Smaller transistors allow more to be packed onto a single chip, typically resulting in increased processing speed and improved power efficiency. Based on where the industry's headed, Apple is likely to heavily market the processors as optimized for AI workflows. This article, "MacBook Ultra: 5 Features That Could Justify the Name" first appeared on MacRumors.com Discuss this article in our forums View the full article

After weeks of speculation, BTS have officially confirmed the Australian leg of their colossal BTS WORLD TOUR ‘ARIRANG’ – marking the group’s long-awaited return Down Under for their first headline tour together in years. And yep, they’re going BIG big. BTS (방탄소년단) – ‘Yet To Come (The Most Beautiful Moment)’ The global K-pop icons will hit Melbourne’s Marvel Stadium for back-to-back nights on February 12 and 13 before heading to Sydney’s Accor Stadium for two more massive shows on February 20 and 21. Honestly? Australian ARMYs may need to start emotionally preparing now. The Australian dates form part of what’s already shaping up to be the biggest K-pop tour of all time – and the biggest tour of BTS’ entire career – with the ARIRANG run spanning 34 regions and a staggering 85 shows worldwide. Demand has already been completely absurd. According to promoters, the tour’s North American, UK and European dates have already sold 2.4 million tickets across 41 stadium shows, with multiple extra dates added due to overwhelming demand during presales. And if BTS’ previous Australian visits are anything to go by, securing tickets here is probably going to feel less like buying concert tickets and more like entering psychological warfare. The tour itself also sounds wildly ambitious, with the production featuring a fully immersive 360-degree in-the-round stage setup designed to place fans at the centre of the experience while expanding stadium capacity. Which honestly feels fitting for a group whose live shows have long operated on a scale most artists can barely comprehend. The ARIRANG tour marks BTS’ first full headline run together since their record-shattering PERMISSION TO DANCE ON STAGE shows, with the group already breaking milestones across the current run – including becoming the first K-pop act to headline multiple major US stadiums. And now Australia’s finally getting its turn. Suss the details down below. BTS – Australian Tour Dates 2027 Friday February 12 – Marvel Stadium, Melbourne, VIC Saturday February 13 – Marvel Stadium, Melbourne, VIC Friday February 20 – Accor Stadium, Sydney, NSW Saturday February 21 – Accor Stadium, Sydney, NSW Tickets for the Australia dates will be available starting Tuesday, June 2 via ARMY MEMBERSHIP PRESALE. Remaining tickets will be available via general onsale beginning Thursday, June 4 at 10am AEST in Melbourne and 1pm AEST in Sydney, at btsworldtourofficial.com Further Reading BTS Arirang Tour Setlist BTS Confirm Australian Shows on Record-Breaking World Tour A Big K-Pop Festival Is Officially Coming to Australia in 2026 The post BTS Confirm Long-Awaited Return To Australia With Four Stadium Shows appeared first on Music Feeds. View the full article

The Oddworld is officially reopening. Fresh off a monster couple of years touring with the likes of Poppy and Thornhill, Melbourne chaos merchants Ocean Grove have today announced their Oddworld Underground Australian Tour for August 2026 and the lineup is an absolute nu-metal kid fever dream. Ocean Grove – ‘SOWHAT1999’ Joining them on the run are returning New Orleans heavy hitters Cane Hill, making their long-awaited first Australian appearance in nearly a decade, alongside Western Sydney pit-starters Deficit and Adelaide nu-gaze risers Blinder. It’s a lineup that feels scientifically engineered to make venues smell like sweat and Monster Energy. Kicking off in Perth on August 13, the tour will hit Adelaide, Melbourne, Sydney, Newcastle and Brisbane, with Ocean Grove once again bringing their gloriously unhinged “Oddworld Music” universe back to Aussie stages. And at this point, the band really do exist in a lane entirely their own. Ever since detonating onto the scene with 2017’s The Rhapsody Tapes, Ocean Grove have spent the better part of a decade mutating nu metal, hardcore, alternative rock and pure internet-era weirdness into something that somehow feels both nostalgic and completely alien at the same time.. Their most recent album ODDWORLD only pushed things further, while recent tours across the UK, Europe and Australia – including support runs with Poppy and Thornhill – have cemented the band as one of Australia’s most inventive heavy exports. And following their recent APRA Award win for RAINDROP, it feels like Ocean Grove are hitting another major level right now. Meanwhile, Cane Hill’s inclusion on the bill marks a pretty huge moment for longtime heavy fans too. The Louisiana outfit haven’t toured Australia since 2016, when they first visited supporting Bullet For My Valentine, and have spent the years since diving deeper into their bleak, genre-warping blend of metalcore, grunge and alternative heaviness. Add in Deficit’s increasingly feral live reputation and Blinder’s dreamy-yet-crushing shoegaze textures, and this genuinely feels like one of the coolest heavy lineups announced locally in a hot minute. Suss the details down below. Ocean Grove – Oddworld Underground Australian Tour 2026 Supported by Cane Hill (USA), Deficit and Blinder THURSDAY 13 AUGUST – AMPLIFIER BAR, PERTH 18+ ** FRIDAY 14 AUGUST – THE GOV, ADELAIDE LIC AA SATURDAY 15 AUGUST – 170 RUSSELL, MELBOURNE 18+ THURSDAY 20 AUGUST – FACTORY THEATRE, SYDNEY LIC AA FRIDAY 21 AUGUST – HAMILTON STATION HOTEL, NEWCASTLE 18+ SATURDAY 22 AUGUST – PRINCESS THEATRE, BRISBANE LIC AA ** Deficit & blinder not appearing General tickets on sale: Friday 29 May @ 11am local time via destroyalllines.com Further Reading Melbourne’s Beloved Stay Gold Is Closing This June Hellbound II Lineup: Parkway Drive, Thy Art Is Murder + MORE Ocean Grove Announce New Album ‘ODDWORLD’ The post Ocean Grove Announce Massive ‘Oddworld Underground’ Australian Tour appeared first on Music Feeds. View the full article

Apple is set to unveil iOS 27 next month ahead of a September release. The update is expected to include a dedicated Siri app, expanded Apple Intelligence capabilities in apps like Wallet, Safari, and Shortcuts, an upgraded keyboard with improved autocorrect, the ability to use Apple Maps via satellite connection, and more. In his Power On newsletter today, Bloomberg's Mark Gurman revealed four additional iOS 27 changes related to AirPods, Genmoji, AirPlay, and Siri. Here are his latest iOS 27 expectations:A revamped AirPods setting menu that is better organized Improved quality for Genmoji and Image Playground creations The ability to set AirPlay alternatives such as Google Cast as default — possibly EU only A new Siri interface with a dark color scheme, similar to Apple's WWDC 2026 graphicsApple's WWDC 2026 keynote begins on Monday, June 8 at 10 a.m. Pacific Time, so we should learn more about these features in a few weeks.Related Roundups: AirPods 4, iOS 27, WWDC 2026Tags: AirPlay, Bloomberg, Genmoji, Mark GurmanBuyer's Guide: AirPods (Caution)Related Forums: AirPods, Apple, Inc and Tech Industry This article, "New iOS 27 Rumors Include Revamped AirPods Settings Menu and More" first appeared on MacRumors.com Discuss this article in our forums View the full article

Apple will unveil watchOS 27 during its WWDC 2026 keynote on Monday, June 8, and a handful of new features have been rumored already. The first developer beta of watchOS 27 should be available immediately following the keynote, and a public beta typically follows in July. The update should be released to all users with a compatible Apple Watch model in September. Below, we recap watchOS 27 rumors so far. Improved Heart Rate Tracking In his Power On newsletter today, Bloomberg's Mark Gurman said watchOS 27 will include improvements to heart rate tracking, but he did not elaborate. New Modular Watch Face watchOS 27 will add new watch faces, including a variant of the "Modular Ultra" watch face that is currently exclusive to the Apple Watch Ultra, according to Gurman. New Apple Intelligence Features On watchOS 26, the following Apple Intelligence features are available on an Apple Watch when it is paired with an iPhone 15 Pro or newer: Workout Buddy Live Translation in Messages Notification SummariesWhen it announced the dates for WWDC 2026, Apple promised to unveil "AI advancements" across its platforms, and it can be reasonably assumed that watchOS 27 will include some additional Apple Intelligence features powered by the iPhone. New Satellite Features Apple Watch Ultra 3 has built-in satellite connectivity, enabling Emergency SOS, Find My, and Messages via satellite without any reliance on an iPhone. iOS 27 will reportedly include up to five new satellite features, and the following two would likely extend to watchOS 27:Apple Maps via satellite Photos support for Messages via satelliteAmazon last month announced plans to acquire Globalstar, the satellite company that powers Apple's satellite features on the iPhone 14 and newer and the Apple Watch Ultra 3. In turn, Amazon announced that it has signed an agreement with Apple to provide satellite connectivity for current and future iPhone and Apple Watch features. Stability Focus Apple is largely focused on "stability, performance, and smaller refinements" for watchOS 27, rather than on major new features and capabilities, according to Gurman. This suggests that the update could include many bug fixes.Related Roundups: Apple Watch 11, watchOS 26Tags: Bloomberg, Mark GurmanBuyer's Guide: Apple Watch (Caution)Related Forum: Apple Watch This article, "watchOS 27 Will Add These New Features to Your Apple Watch" first appeared on MacRumors.com Discuss this article in our forums View the full article

Anker's Prime 3-in-1 Wireless Charging Station is still available for $104.99 on Amazon this weekend, down from $149.99. This is one of Anker's newest accessories, and Amazon's sale today is a match of the all-time low price. Note: MacRumors is an affiliate partner with some of these vendors. When you click a link and make a purchase, we may receive a small payment, which helps us keep the site running. The Prime 3-in-1 Wireless Charging Station features Qi2.2 support, which lets a compatible MagSafe ‌iPhone‌ charge at up to 25W. It's the same speed as Apple's ‌MagSafe‌ charger, and it is 10W faster than the standard Qi2 ‌MagSafe‌ chargers. You can also simultaneously charge an Apple Watch and AirPods with the device. $45 OFFAnker Prime 3-in-1 Wireless Charging Station for $104.99 There are plenty of other Anker discounts happening on Amazon this week, including Anker's Prime 14-in-1 Docking Station for $339.98, down from $399.99. Below you'll find a list of the best Anker discounts on Amazon this week, also including wall chargers, portable chargers, and more. $60 OFFAnker Prime 14-in-1 Docking Station for $339.98 Wall Chargers Nano USB-C Wall Charger - $29.99, down from $39.99 140W 4-Port GaN USB-C Charger - $79.99, down from $99.99 160W 3-Port Compact Charger - $105.99, down from $149.99 Wireless Chargers 3-in-1 MagSafe-Compatible UFO Charger - $69.99, down from $89.99 3-in-1 MagSafe-Compatible Foldable Charging Station - $85.99, down from $109.99 3-in-1 MagSafe-Compatible Charging Cube - $89.99, down from $129.99 3-in-1 Prime Wireless Charging Station - $104.99, down from $149.99 Prime MagSafe-Compatible 3-in-1 Charging Station - $159.99, down from $229.99 Portable Chargers MagGo Power Bank 10,000 mAh - $63.99, down from $79.99 SOLIX C300 Power Station with Lantern - $169.99, down from $249.00 Prime Power Bank 26,250 mAh - $171.48, down from $229.99 SOLIX C1000 Gen 2 Portable Power Station - $499.99, down from $799.00 SOLIX C2000 Gen 2 Portable Power Station - $799.99, down from $1,499.00 If you're on the hunt for more discounts, be sure to visit our Apple Deals roundup where we recap the best Apple-related bargains of the past week. Deals Newsletter Interested in hearing more about the best deals you can find in 2026? Sign up for our Deals Newsletter and we'll keep you updated so you don't miss the biggest deals of the season! Related Roundup: Apple Deals This article, "Anker 3-in-1 Prime Wireless Charging Station Drops to $104.99 on Amazon" first appeared on MacRumors.com Discuss this article in our forums View the full article

Apple is readying the subdomain genai.apple.com, according to MacRumors contributor Aaron Perris, but it does not yet lead to a live web page. This comes a few weeks ahead of Apple's annual developers conference WWDC, where the company has promised to announce "AI advancements" across its software platforms. Apple's website already has an Apple Intelligence page, so it is unclear what the company's plans are for genai.apple.com at this time. Apple's next major software releases like iOS 27, iPadOS 27, and macOS 27 are expected to include many new Apple Intelligence features, including a more personalized version of Siri with on-screen awareness. Similar to other chatbots like ChatGPT, a dedicated Siri app will reportedly allow users to have back-and-forth conversations. Apple Intelligence will power a wide range of new accessibility features, such as automatic captions for videos recorded with an iPhone. In addition, Voice Control is gaining support for natural language, allowing users to say things like "tap the guide about best restaurants" in Apple Maps or "tap the purple folder" in the Files app. Apple Intelligence will make it easier for users to create shortcuts in the Shortcuts app, and it will power a new "Create a Pass" option in the Wallet app. Safari will be able to automatically name tab groups, and Visual Intelligence will be able to scan food nutrition labels and add information from a business card or paperwork to the Contacts app. Apple's WWDC 2026 keynote begins on Monday, June 8 at 10 a.m. Pacific Time.Related Roundup: WWDC 2026Tag: Apple IntelligenceRelated Forum: Apple, Inc and Tech Industry This article, "Apple Preparing New 'Gen AI' Website Ahead of WWDC" first appeared on MacRumors.com Discuss this article in our forums View the full article

After more than two decades of heartbreak anthems, arena singalongs and emotionally devastating pub playlists, The Script are officially heading back Down Under. The Irish hitmakers have today announced their Man In The Arena Tour for March 2027, returning for three massive east coast arena shows in what marks their TWELFTH Australian headline run with Frontier Touring (which honestly feels kind of insane when you stop and think about it). The Script – ‘Man in the Arena’ Kicking off at Brisbane Entertainment Centre on March 23, the tour will then head through Melbourne’s Rod Laver Arena before wrapping up at Sydney’s Qudos Bank Arena later that week. And if you’ve ever accidentally screamed the lyrics to Breakeven at 1am in an Uber after a breakup, there’s a very high chance you already know these shows are going to be huge. The announcement arrives alongside the release of the band’s soaring new single Man In The Arena, the first taste of their upcoming album The User’s Guide To Being Human, due out August 14. Classic Script mega-chorus? Yep. Emotionally charged Danny O’Donoghue vocals? Absolutely. A giant “prove the haters wrong” energy running through the whole thing? Yep. According to frontman Danny O’Donoghue, the song reflects the idea that stepping into the spotlight – and risking failure publicly – is braver than standing safely on the sidelines criticising others. Which honestly feels pretty fitting for a band who’ve spent the last twenty years becoming one of modern pop-rock’s most enduring global success stories. We’re talking six UK #1 albums, eight #1 albums in Ireland, over 14 billion streams, more than 4.5 million tickets sold worldwide and enough emotionally ruinous radio hits to permanently alter the chemistry of millennials everywhere. The upcoming album also marks another important chapter for the band following 2024’s Satellites, which saw O’Donoghue processing the devastating loss of longtime bandmate Mark Sheehan, who passed away in 2023. Following that album cycle and global arena run, O’Donoghue says he found himself creatively re-energised almost immediately – jumping straight back into writing with collaborators behind some of the band’s biggest ever songs, including Hall Of Fame, Breakeven and The Man Who Can’t Be Moved. And judging by Man In The Arena, they’re very much swinging for the rafters again. “We can’t wait to take our worldwide tour back to Australia again,” O’Donoghue shared. “We have such a long-standing friendship with our fans and Frontier Touring, it feels like home away from home. Get ready for another banging show!” Tou can pre-order the album HERE, or suss their tour dates down below. The Script – Australian Tour 2027 Tuesday March 23 – Brisbane Entertainment Centre, Brisbane, QLD Thursday March 25 – Rod Laver Arena, Melbourne, VIC Saturday March 27 – Qudos Bank Arena, Sydney, NSW FRONTIER MEMBER PRESALE ​via frontiertouring.com/thescript ​Runs 45.5 hours from: Wednesday 27 May (11am local) ​ ​or until presale allocation exhausted TICKETS ON SALE ​Begins: Friday 29 May (9:30am local time ALL SHOWS LIC. ALL AGES Further Reading The Script Guitarist Mark Sheehan Has Died, Aged 46 Post Malone Is Bringing His ‘BIG ASS World Tour’ To Australia Coldplay Fall Just Shy of 50% Reduction in Tour Emissions The post The Script Are Returning To Australia For Massive 2027 Arena Tour appeared first on Music Feeds. View the full article