Mike Schmitz previews his Road to Macstock session on starting a YouTube channel in 90 minutes, emphasizing creativity, repetition, audience connection, and practical tools over perfection. Mike discusses handling harsh comments, finding personal value in publishing, and using AI thoughtfully as a creative partner. His goal is to help get anyone on YouTube that wants to be there. 

💾

Only a few hours after Apple’s WWDC keynote, members of the   MacPaw leadership team sat down for a conversation about Apple Intelligence, and Siri’s renewed promise. Topics touched on included privacy, developer access to user context, hybrid AI processing, Setapp’s role, and how AI is reshaping app creation, customer support, and software strategy. Participants included Oleksandr Kosovan, Founder and CEO?, Sergii Kryvoblotskyi, Director of AI and Research, Dmytro Melnyk, Chief Product Officer and Grant Belaire, Chief Marketing Officer.

💾

At NAB 2026, Chuck Joiner talks with Ryan Burke, Portfolio Director for RØDE about the new RodeLink 2 UHF wireless system, developed with Lectrosonics expertise. The discussion covers interference-resistant UHF performance, 32-bit float recording, timecode, adaptive power, battery life, and removable storage media.  Ryan also provided a look at the new RODECaster Studio AI audio editing app for podcasters. 

💾

On the show floor at NAB in Las Vegas, Jim Tierney of Digital Anarchy discusses ShotNotes, a Premiere Pro panel that keeps project notes, time codes, links, timers, and collaboration details inside the edit instead of scattered across documents or sticky notes. He also previews Beauty Box Video AI development and explains where generative AI can help video pros, where traditional AI still shines, and why AI is useful but not a magic bullet. 

💾

Jonathan Wells’s review was important, but it only scratches the surface of information in biology outside of the DNA.

Source

Anthropic will extend support for watermarking AI generations for older models as well.

A Anthropic anunciou nos últimos dias duas novidades bem interessantes para o Claude Code, sua plataforma agêntica de codificação com inteligência artificial (IA) generativa: as conversas entre diferentes sessões e o modo automático como padrão para alguns de seus planos.

Começando pela primeira novidade supracitada, ela permite que o Claude envie informações de uma sessão para outra num mesmo computador ou responda a sessões em outras máquinas — algo que pode ser bastante útil quando mais de uma sessão está trabalhando num mesmo projeto.

O recurso pode ser usado, por exemplo, quando há uma mudança que quebra o sistema como um todo e cuja resolução depende de algo executado em outra sessão — ou simplesmente quando alguma delas precisa saber de uma decisão de design ou de um resultado de testes.

Por ora, no entanto, apenas texto simples é suportado, de modo que nenhum arquivo ou o histórico da conversa é transferido entre as diferentes sessões. Uma sessão também não pode aprovar comandos originados de outras sozinha — sempre é requerida a autorização do usuário para tal.

New in Claude Code: your sessions can now message each other.

Instead of having to re-explain yourself in another session, you can now tell Claude to do it. It sends a summary (not your history or files), and the other session picks it up mid-task. pic.twitter.com/PtNsfXeQXP

— ClaudeDevs (@ClaudeDevs) August 7, 2026

O Claude pode decidir enviar uma mensagem por conta própria se julgar necessário, ou o usuário pode solicitar explicitamente que ele informe algo a outra sessão — inclusive, é possível definir se elas devem ser aceitas ou recusadas automaticamente ou se devem requerer aprovação.

Modo automático como padrão

Um dos recursos mais interessantes do Claude Code é o modo automático, que permite à plataforma usar uma espécie de “classificador de segurança” para decidir se prossegue ou não com determinada tarefa, sem precisar a todo instante solicitar a permissão do usuário.

Com o modo automático, que antes era opcional, o Claude pode trabalhar sozinho por períodos muito mais longos e sem qualquer interferência humana — o que permite que seus modelos realizem tarefas complexas durante horas e entreguem um trabalho mais completo ao fim da sessão.

Pesquisas feitas pela Anthropic indicaram que o modo automático também tende a deixar o desenvolvimento mais seguro, já que desenvolvedores costumam aprovar 97% dos pedidos de permissão por reflexo (sem revisão), e bloqueiam bem menos prompts perigosos que a ferramenta (acima).

Com isso, esse modo agora passará a ser o modo padrão do Claude Code nos planos Pro, Max e Team — a partir de 14 de agosto. Como consequência dessa mudança, a Anthropic também deixará de cobrar dos usuários desses planos pelo custo computacional desse classificador.

The App Store is evolving at a breakneck pace not seen since its earliest days. We saw the first glimmers of what was to come early in 2025, but it wasn’t until late last year that the tsunami of apps developed with the help of AI agents really took hold.

Since then, veteran developers are releasing new apps and updating existing ones faster than ever, and new developers are releasing their first apps in droves. Today, supply is dramatically up, demand is flat, and quality is seemingly simultaneously up and down, depending on where you look.

How these forces play out long-term is anyone’s guess, but it’s worth examining because, just as Federico’s link to Bryan Irace’s post about agentic coding tools foreshadowed the rise of tools like Codex and Claude Code, today’s trends are sparks that have the potential to become tomorrow’s App Store wildfires or simply fizzle out.

Utility apps are on the front lines of this change. The TechCrunch story I linked in April picked up on this trend:

Another interesting tidbit from Appfigures is that the Utilities app category moved up the top five chart.

If anything, the trend has accelerated in the months since.

It’s not surprising at all that utility apps have taken off. They’ve been a staple of new developers since long before agents came along. That’s because many are UI wrappers around command line tools. That isn’t a knock against the developers of those apps; most users don’t want to open Terminal to convert a video or audio file to another format using ffmpeg, for example. By building a great UI around command line tools, developers have made them far easier to use.

However, the relative simplicity and narrow scope of many utility apps have made them a natural fit for AI agents, too. That’s why the App Store (and my inbox) is deluged with Mac menu bar and single-screen iPhone and iPad utility apps.

On the one hand, the abundance of utilities has been great for users. More choice means you’re more likely to find the app that perfectly fits your needs.

On the other hand, though, I don’t think what’s happening in the category is sustainable and expect to see it dramatically shift again in the coming months. As we’ve seen from reporting by The New York Times, app supply is outstripping demand by orders of magnitude, which will drive down prices. That alone is likely to cause the utility app market to shrink. But there’s more to it than that.

Remember, the demand shifts that The New York Times reported, based on Sensor Tower numbers, are for the entire App Store, where download numbers have grown 2-3% this year and last. I expect utility downloads to actually shrink in the coming months – again, because of agents. Utilities, especially simple ones, are exactly the sorts of apps that are becoming trivially easy for power users – the very users these utilities are made for – to create themselves. From frontier labs‘ model improvements to a growing number of app-building tools from those same labs and third parties, it’s never been easier to build a web or native app yourself.

And although I agree with people, like Nilay Patel, who say the notion that everyone will build their own software is overblown, the utility market is different. Your average person is not downloading apps to adjust the frame rate and file format of a video or downloading YouTube videos to watch later. But those are exactly the sort of things that people who are using agents are doing with them, whether they’re having an agent do those things directly via a command line tool in an app like Codex or Claude Code or building an app to do the same thing. That’s going to put even more pressure on the category.

That said, I think there will always be a cohort of users who would rather pay for an app than build it themselves, so I’m not predicting the demise of utilities in general – just the end of today’s frothy market. I also think there remains a place for simple utilities that solve hard problems with clever solutions. Not every utility is a UI wrapper for a terminal command. Plenty of apps feature original solutions or thoughtful and unconventional remixes of disparate tools.

Utilities aren’t going away, but just like other App Store deluges, the trend will recede. It’s just that this time, it’s likely to flip faster than usual.

A Meta lançou hoje o Muse Code, seu primeiro agente de programação — o qual rivalizará com soluções como o Claude Code (da Anthropic) e o Codex (da OpenAI).

A nova ferramenta, assim como os assistentes supracitados, facilita a criação de aplicativos em uma única interface, permitindo gerenciar conjuntos de agentes digitais impulsionados por IA que auxiliam no processo de desenvolvimento de software.

Releasing Muse Code in beta today. It's a terminal coding agent that takes on complete software engineering tasks across large repos: planning changes, writing code, validating the results. Powered by Muse Spark 1.2, a coding-focused model update. pic.twitter.com/xqavk41w6v

— Mark Zuckerberg (@finkd) August 5, 2026

Ainda que disponível inicialmente em beta, o Muse Code pode ser usado para realizar uma ampla variedade de tarefas, planejando alterações, escrevendo código e validando os resultados. Desenvolvedores podem utilizá-lo por meio de uma modalidade de pagamento conforme o uso (pay-as-you-go).

Ao contrário do Codex e do Claude Code, atualmente não existe um aplicativo dedicado para o Muse Code. Desse modo, ele pode ser instalado no macOS e no Linux a partir de um comando de uma única linha:

curl -fsSL https://dev.meta.ai/install.sh | bash

Ele também opera em conjunto com o mais novo modelo de IA da empresa, o Muse Spark 1.2 — o qual foi desenvolvido e treinado juntamente com o novo agente de programação, o que melhora o desempenho geral.

O Muse Spark 1.2 é uma atualização do Muse Spark 1.1, lançado no mês passado, trazendo melhorias na geração de código, depuração de cenários complexos, compreensão da base de código e fluxos de trabalho de ponta a ponta para desenvolvedores. O novo modelo também amplia significativamente o poder computacional de treinamento para tarefas de programação.

O Muse Spark 1.2 apresenta recursos de programação aprimorados em comparação com sua versão anterior. Aumentamos significativamente a capacidade computacional de treinamento em tarefas de programação, ao mesmo tempo que expandimos a diversidade de ambientes de treinamento, proporcionando melhorias na geração de código, depuração complexa e fluxos de trabalho de desenvolvimento de ponta a ponta.

O modelo foi treinado com o Muse Code para otimizar o desempenho quando utilizados em conjunto, com foco em tarefas como geração de repositórios completos, projetos de grande porte e pesquisa automatizada.

O Muse Spark 1.2 já está disponível no Muse Code e na Meta Model API.

Além de compartilhar uma página da web usando um link normal, o navegador Mozilla Firefox também permite enviar um endereço da web de outra forma.

Mais precisamente, trata-se da geração de um código QR (QR code) — que pode, posteriormente, ser lido a partir de qualquer câmera ou compartilhado em uma postagem, por exemplo.

Veja como fazer isso no seu Mac! 👨‍💻

1. Com o Firefox aberto no seu computador, siga um dos seguintes procedimentos:
   • Clique com o botão direito em cima da aba;
   • Vá até “Arquivo”, na barra de menus;

2. Selecione “Compartilhar” e “Gerar código QR…”.

3. Clique em “Salvar” para fazer o download do código ou em “Copiar” para que ele seja copiado para a área de transferência.

iPad is a great option for students, writers, artists and many more. But not developers. It’s time to change that.

(via Cult of Mac - Your source for the latest Apple news, rumors, analysis, reviews, how-tos and deals.)

Claude Code’s Mac desktop app has added Apple simulator support, and although it’s billed as “iOS Simulator Support,” it actually works with any iOS, iPadOS, visionOS, or watchOS simulator you have installed.

The process of setting up a simulator is simple. A new button with an iPhone icon appears when you open an existing project. Click it and a new iPhone simulator pane opens to the right by default. However, clicking on the name of the simulator reveals a list of every available simulator. You can also run multiple simulators at once, but that immediately made my aging M1 Max Mac Studio start to chug a little.

Once you have the simulators that you want open, simply ask Claude Code to run and test your app, and it gets to work, building the app, installing it in the simulator, opening it, and poking around. I loaded up a simple word game I’ve been playing with, and after a few minutes, Claude Code found a UI bug while controlling the simulator. I asked it to fix the issue, which it did, then tested and committed. My testing has been limited, but so far it looks like a simple, effective loop.

It’s also worth noting that Claude Code is running the simulator directly inside the Claude app. This is not computer use, meaning windows aren’t going to be opening and getting in your way as you work on something else. All in all, the addition of the simulator, like the inclusion of an in-app sandboxed browser a couple of weeks ago, is a great update to Claude Code.

SpamSieve 3.3.1 is an update of my Mac e-mail spam filter that improves the filtering accuracy and includes various optimizations, fixes, and updates for macOS 27. Some interesting engineering issues were:

• I’m still supporting macOS 10.13, but the app can now build with the macOS 12 deployment target in preparation for Xcode 27. The way Swift handles calling deprecated APIs remains annoying. You need workarounds like protocols to suppress a warning in a particular region of code. Often, I am updating to a newer API, but I want to continue using the old one on earlier versions of macOS. Right now I am heavily testing on macOS 26, so I would like to only deploy the new code there. Sometimes the initial versions of APIs are buggy, and I don’t want to have to retest every feature on every version. But Swift doesn’t like me to gate the calls to macOS 26 and later if the new API was actually introduced in, say, macOS 11.

• The most risky update was probably switching to the Swift API for Scanner. This is tricky because the current scan position changes from being based on UTF-16 indexes to String.Index. And in some cases my code was intentionally scanning into the middle of a combining character. I was really glad to have extensive tests here.

• Recent versions of Tahoe introduced a Core Data bug that broke save recovery (when invalid Unicode can’t be written to the database and we have to fix it up first). When the error comes in, SpamSieve looks under the NSDetailedErrorsKey key, but the value of this key is "NSDetailedErrorsKey" while the actual error info is under the key "NSDetailedErrors".

• Database corruption combined with a Core Data bug and two Swift behaviors were causing crashes. The root problem, I think, is that in this situation Core Data neglects to set the error pointer for -[NSManagedObjectContext countForFetchRequest:error:]. Normally, Swift would detect this and throw a generic nilError. However, this method signals errors by returning NSNotFound instead of nil. It’s annotated as swift_error(nonnull_error), which I think means that Swift doesn’t even look at the return value, only the (unset) error. So my code was receiving NSNotFound on the non-error path, treating it as a real count, and doing some math with it, which (by default in Swift) leads to a crash if there’s overflow. Now my code checks for NSNotFound and uses Int.addingReportingOverflow().

• I reimplemented Core Data batch fetching because of two problems with the fetchBatchSize option. First, it logs spurious errors when fetching from multiple stores at once. Second, it leads to high memory use. It will load objects in batches, but it never releases the earlier batches. You can manually refault objects that you no longer need, but it will still hold onto the full object shells, which can add up. My implementation only holds onto IDs, and it can fetch the IDs using a different context than the objects to push more work to background threads.

• I’m now using String.makeContiguousUTF8() in various places to avoid slow iteration of bridged strings.

• There was a regression where some menu code could crash on macOS 10.13. -[NSMenu setItemArray:] is only available on macOS 10.14 and later, whereas the getter is always available. With old Objective-C, the two methods could be annotated with separate availabilities. The Objective-C property syntax doesn’t allow this, so there’s no way for the compiler to flag calls where the setter is missing.

• The AppleScript support works much better with large data sets. The key, I think, is to never return an array to Cocoa for a scripting property/element. First, if you give it a lazy array it will sometimes try to access all the elements even if it only needs a few. And, second, AppleScript will run out of memory if the array is too large. By using indexed accessors, you can maintain laziness and only convert one object to a descriptor at a time. By caching a batch-fetching collection, you can limit the number of fetches and respond quickly when AppleScript requests individual objects.

Previously:

• Xcode 27 Announced
• SpamSieve 3.3
• Swift Proposal: Precise Control Flags Over Compiler Warnings
• Swift at 10

Apple (xip, downloads):

Xcode 26.6 includes Swift 6.3 and SDKs for iOS 26.5, iPadOS 26.5, tvOS 26.5, macOS 26.5, and visionOS 26.5. Xcode 26.6 supports on-device debugging in iOS 15 and later, tvOS 15 and later, watchOS 8 and later, and visionOS. Xcode 26.6 requires a Mac running macOS Tahoe 26.2 or later.

[…]

Google Gemini is now available in the coding assistant.

Xcode adds support for the Agent Client protocol.

[…]

Launch Time similar-app goals have been refined for improved accuracy, establishing new baselines.

Previously:

• Xcode 27 Announced
• Xcode 26.5

Apple:

You manage all the devices that appear in Xcode as run destinations using Device Hub.

Run your app on simulated devices in Device Hub to quickly evaluate new features and fix bugs, and to see how your interface works on devices that you don’t have physical access to. Run your app on physical devices to test features or services that have hardware dependencies or investigating performance issues. For more information, see Running your app on simulated or physical devices.

Fatbobman:

Device Hub is undoubtedly a major surprise. It integrates simulators, physical device management, system state testing, and dynamic size adjustment into a new workflow. Its impact on day-to-day development experience may be more direct than that of many individual APIs. That said, iPhone apps now also support dynamic size adjustment, which will bring new challenges for developers, especially in terms of data and state organization. Adapting to different sizes is not something that can be solved merely by relying on dynamic layout containers. In many scenarios, large and small sizes correspond to very different navigation logic.

Collin Allen (Mastodon):

Xcode 27 introduced, among other new features, a new Device Hub app for developers that takes the place of the Simulator app. Where Simulator relied on separate windows for each device, Device Hub brings them all together into a single window where each simulated device is the detail view from a source list of devices on the left. It’s a more organized approach, made necessary by the wide variety of platforms Apple and Apple platform app developers have to build and test against.

[…]

In releases prior to Xcode 27, you could resolve this by importing the root public certificate into the simulated OS. On iOS, this could be done by dragging and dropping the .cer file onto the Simulator device window. Nothing would appear to happen, but you could then navigate to Settings, General, About, Certificate Trust Settings and mark the certificate as trusted.

[…]

In Xcode 27 with Device Hub, this process is much more uniform. […] While this new process does require you to wrap certificates in an Apple Configurator profile, this is much more consistent with how Apple’s device management system works, as it relies on signed profiles with policies, not loose .cer files. And now, just by adding the .mobileconfig to the Profiles section of the device inspector, the embedded certificate is automatically marked as trusted, greatly speeding up installation on new virtual devices.

Steve Troughton-Smith:

I get what Apple is trying to do with the Device Hub, but it’s nowhere near as usable and as useful as the iOS Simulator (in this seed)

Adam Overholtzer:

Device Hub is missing the “pixel accurate” and “point accurate” zoom options and that’s not acceptable.

Steve Troughton-Smith:

Maybe someday the Simulator/Device Hub might even be able to output screenshots in the same orientation as the emulated device 😛

Steve Troughton-Smith:

Thanks to the remote control / screen sharing features of Device Hub, I can remotely navigate to Settings and start a software update on all my iOS27 devices without having to go collect them around the house 👌

Steve Troughton-Smith:

For all of Apple’s nonsense about adding iPhone Mirroring to the EU, the new Device Hub (iOS Simulator) lets you remote-control your physical iOS devices just fine. I don’t think the DMA has an opt-out for developer tools 😛

Steve Troughton-Smith:

It’s such a shame for now that Xcode 27’s Device Hub doesn’t support remote screen sharing with iOSes earlier than 27. I wish the screen sharing functionality was part of the developer disk image, and backported to iOS 26 and even iOS 18. Having a physical device plugged in somewhere is so much faster than booting a Simulator.

Previously:

• WWDC 2026 Links
• Xcode 27 Announced
• No Apple Intelligence or iPhone Mirroring in EU at Launch

Update (2026-06-26): Léo Natan:

Xcode 27’s “Device Hub” is a broken shitshow, but most importantly, it lacks the Debug menu, where you could toggle slow animations and simulate memory warnings. Apple works tirelessly to destroy any good tool they used to have.

He has a thread of issues. Hopefully these will be addressed before it’s out of beta.

Update (2026-07-01): Craig Hockenberry:

The Device Hub sometimes doesn’t kill CoreSimulator processes when you quit the app (not sure if this is a bug or intentional). Given that each device uses several hundred processes, the memory/processing impact is significant.

You’ll probably want to keep an eye on how many you have running: use right-click on the simulator in the list to “Shut Down” as necessary.