Apple’s new MacBook Pro with PROLED XDR display is the first Mac with a touchscreen, and Apple is pitching tapping, scrolling, and pinching to zoom as “a whole new way to interact with your work.” Windows laptops have supported these gestures since Windows 7 in 2009, while Apple executives spent the next decade and a half explaining why touch didn’t belong on a Mac, including John Ternus, who now runs the company.

Ternus defended the Mac’s touch-free design five years ago to the day. Now, he says, “You’ve gotta touch it to believe it.”

Really? I mean, I’ve been believing since 2012…

Apple’s touchscreen MacBook Pro ad explains touch like it’s 2007

Apple’s announcement on October 28, 2026 calls it “Touch for the first time on Mac,” and the launch video’s description tells you the display is so good that “you’ll want to reach out and touch it. And now, you can. Tap, swipe, scroll, and pinch to zoom directly on your screen.”

The product page is hilariously explaining each gesture as if we haven’t seen touchscreen laptops before. Scroll is “Move through content by sliding your finger across it.” Zoom is “Pinch to zoom in on photos, documents, web pages, and more.” The section is titled “Magic on tap.” There’s nothing magical here, Apple!

Apple also says the touch sensor is “built directly into the display panel” and “not layered on top of it,” which reduces latency. Samsung Display announced OLED laptop panels with touch sensors built into the panel in January 2023, and offered them to other laptop brands. Again, not a new technology.

That said, the display is excellent. The tandem OLED panel hits 2,000 nits peak brightness with a 10,000,000:1 contrast ratio, and the MacBook Pro got lighter and thinner while adding touch. It’s great, but what’s not is the way Apple tries to sell them.

Apple is using a marketing trick from decades ago

SPOILER ALERT: In the very first episode of Mad Men, Lucky Strike’s owners explain how their tobacco is grown, cured, and toasted. Don Draper stops them at “toasted,” because that’s the ad. Everyone else’s tobacco is poisonous, but Lucky Strike’s is toasted (as if that makes it less poisonous!)

The funny thing is that heating tobacco was common practice across cigarette makers. Advertisers call this a preemptive claim, where a brand talks about a common feature first, so it starts to look like its own. Claude Hopkins did it over a century ago, selling Schlitz beer in sterilized bottles that other breweries also used, and “It’s toasted” was a real Lucky Strike slogan from 1917.

Apologies for the mention of old Cigarette and Alcohol ads, but there’s a reason why those sold in millions, and Cupertino is planning the same.

Apple is doing this with touch. For a Mac user who hasn’t used a touchscreen laptop, it’s toasted.

Apple executives said touchscreen Macs were a bad idea for 16 years

Steve Jobs said in 2010 that “touch surfaces don’t want to be vertical,” and that “your arm wants to fall off.” Of course, Jobs couldn’t have been more wrong here.

Last week, as Apple prepared to launch the touchscreen MacBook Pro, ex-Windows boss Steven Sinofsky didn’t let the double standards slide, as he mocked the naysayers who suddenly changed stands.

When an analyst asked whether Apple would merge tablets and laptops like Microsoft was doing with Windows 8, Tim Cook said in April 2012, “You can converge a toaster and a refrigerator, but those aren’t going to be pleasing to the user.”

Apple’s software chief Craig Federighi told CNET in 2014 that the “Mac is sort of a sit-down experience,” and that Apple “experimented with all the technology, but we found it just wasn’t good.” In 2016, he said, “Grafting touch onto something that was fundamentally designed around a precise pointer really compromises the experience,” while Phil Schiller said about touch and pointer input, “You can’t optimize for both.”

By 2018, Federighi was calling touchscreen laptops “experiments,” and said “lifting your arm up to poke a screen is a pretty fatiguing thing to do.”

Then, in October 2021, Ternus, who was Apple’s senior vice president of hardware engineering, told The Wall Street Journal, “We make the world’s best touch computer on an iPad. It’s totally optimized for that. And the Mac is totally optimized for indirect input. We haven’t really felt a reason to change that.”

John Ternus now says touch on a Mac is “comfortable and handy”

When WIRED’s Steven Levy asked Ternus whether Apple was breaking its touchscreen taboo, his answer was, “Who knew?”

“The Mac is first and foremost an indirect input device, built around the trackpad and keyboard. But I think there’s times when it’s comfortable and handy to have touch,” Ternus said. He added that Apple “needed to get to a point where adding touch didn’t make the product lesser in any way.”

While on the new CEO, let’s not forget the old one’s new vision. Tim Cook tweeted: “We brought Touch to the Mac!” Sure, you have. It’s been here all along.

Marketing chief Greg Joswiak said, “There’s a generation of young creators and young people using our MacBook Pros that expect to touch.” Of course they do. They grew up on iPhones and iPads, and many of them on Windows laptops with touchscreens!

So, what changed, the technology or Apple’s priorities? According to Bloomberg, Apple hopes premium features will help it charge more, and the touch MacBook Pro starts at $2,899. Well, the technology matured in the past decade…

Microsoft sold this idea with Windows 8 and Surface years ago

Windows 8 built its whole interface around touch in 2012, and Microsoft followed it with the Surface Pro. At the Surface Pro 4 launch in October 2015, a CAD model of a toaster-fridge showed up in Panos Panay‘s demo, a dig at Cook’s comment.

Today, touch is so ordinary on Windows that Microsoft’s Surface Laptop Ultra announcement mentions its “PixelSense Ultra touchscreen” once, in passing. Add the flips, 2-in-1s and detachables from every major OEM, and Windows hardware is miles ahead in form factors.

As someone who once promised himself he’d buy a Surface Studio after watching its launch video, I’m sad Microsoft didn’t double down on hardware. And Apple is still ahead where Windows OEMs keep cutting corners, with six speakers with force-cancelling woofers and a 12MP Center Stage camera on the new MacBook Pro PROLED XDR.

Windows laptops had touch first, but that won’t stop Apple from making it look new. What Windows OEMs can do is fix their speakers and webcams (and build quality in general), because touch no longer sets them apart from a MacBook.

The post Tim Cook compared touchscreen Windows laptops to a toaster-fridge, now Apple is selling one for $2,899 appeared first on Windows Latest

Microsoft’s Azure cloud business brought in $33.2 billion in revenue in the September quarter, up 48% from a year earlier, blowing past the company’s own forecast and beating Wall Street’s expectations.

The growth suggests that Microsoft is selling cloud and AI computing about as fast as it can install it. Azure revenue rose $10.8 billion from a year earlier, driven by demand for services across the platform, Microsoft said in its quarterly filing. That came even as some new data center capacity arrived late.

For investors worried about Microsoft’s record capital spending, it’s a sign that the company’s massive AI and cloud infrastructure buildout is turning into sales. Microsoft’s shares rose nearly 4% in after-hours trading following the earnings report.

Overall, Microsoft reported revenue of $92.3 billion for the first quarter of its 2027 fiscal year, up 19% and above the $90.75 billion analysts expected, according to Yahoo Finance. Earnings were $4.89 per share excluding the impact of its OpenAI investment, compared with expectations of $4.72.

It’s the first time Microsoft has reported Azure’s quarterly revenue figure, not just its growth. The disclosure is part of a new financial structure that took effect this quarter, splitting the company into two segments: Agents and Infra, and Devices and Consumer.

• Agents and Infra (Azure, Microsoft 365, Dynamics, LinkedIn’s recruiting and sales tools, and server and productivity licensing): Revenue rose 25% to $76.8 billion, above Microsoft’s forecast of $75.15 billion to $75.75 billion. Operating income rose 24% to $40.6 billion.
• Devices and Consumer (Windows, Xbox, and search and advertising): Revenue fell 3% to $15.5 billion, above Microsoft’s forecast of $14.7 billion to $15.2 billion. Operating income rose 2% to $5.4 billion.

Capital spending came in below Microsoft’s forecast. The company spent $45.2 billion, including finance leases, short of the more than $50 billion it expected. Some data center capacity that third parties were supposed to deliver in the quarter was delayed, the company said.

Developing story, more to come.

Bobcat 1.0, the Critter Stack’s new tool for executable specifications (automated tests that are human readable for easier review) was released just yesterday. As I wrote about in the release post yesterday, Bobcat is the “spiritual” successor to a mostly forgotten OSS project of mine called Storyteller that was itself trying to be a better version of FitNesse which was trying to solve the same problems of making human readable but executable specifications that has mostly been popularized by Gherkin tools like Cucumber.

I’ve admittedly just lifted this from the documentation website, but here’s an introduction to authoring a specification with Bobcat:

What you will build: one business rule, specified three ways in plain C# against a plain .NET class, with no Critter Stack and nothing hosted. You start from an xUnit test you could have written yesterday, make it a specification without touching its body, give it a vocabulary so the next test reads the same way, and then write the data-heavy cases as tables. By the end you have seen what the run prints for a pass, a wrong value, a wrong row and a thrown exception.

Bobcat specifications are code. There is no second file and no binding layer between the specification and the test that executes it: the test is the specification. It keeps running on its own runner, in your IDE’s test explorer, and Bobcat renders it as readable steps with a verdict per step.

That is a deliberate compromise. A Gherkin or FitNesse tool theoretically lets a non-technical domain expert author a specification directly, in a file of their own; a projected test is C#, so authoring stays with the developers and the domain expert reviews the rendered specification instead.

There is a little bit of an exemption though for being able to express table centric tests through Markdown tables directly embedded inside of C# (we’ll try to add F# later, but for right now, we’re using C# specific features). The folks who did use Storyteller effectively usually mention the effectiveness of Storyteller’s support for table driven testing for data intensive tests, the “set verification” feature, and the ability to express decision tree tests in Storyteller and now Bobcat with declarative markdown tables.

I should point out that the source generator with Bobcat can (hopefully) validate the Markdown table text at compile time to help eliminate those pesky binding problems that were so nasty with Gherkin or FitNesse.

The project setup is Getting Started: the three packages, the runner adapter, and global.json. This page assumes that and starts at the first test. Every sample on it is compiled and run in Bobcat’s own repository, in src/Bobcat.Xunit.Samples, and every output block is what that run printed.

The rule

A bank account that may not be overdrawn:

public record Transaction(string Kind, decimal Amount);
public class Account
{
    public decimal Balance { get; private set; }
    public List<Transaction> Transactions { get; } = new();
    public void Deposit(decimal amount)
    {
        Balance += amount;
        Transactions.Add(new Transaction("Deposit", amount));
    }
    public bool TryWithdraw(decimal amount)
    {
        if (amount > Balance) return false;
        Balance -= amount;
        Transactions.Add(new Transaction("Withdrawal", amount));
        return true;
    }
}

Step 1: a test you already have, as a specification

Here is the test as most teams would write it, with Shouldly:

[Fact]
public void a_withdrawal_larger_than_the_balance_is_refused_as_most_teams_write_it()
{
    var account = new Account();
    account.Deposit(100);
    var accepted = account.TryWithdraw(200);
    accepted.ShouldBeFalse();
    account.Balance.ShouldBe(100);
}

Make it a specification without changing a line of its logic. Mark the class [BobcatFeature("Withdrawals")], and say what each part of the body does in a comment that opens with Given, When or Then:

[Fact]
public void a_withdrawal_larger_than_the_balance_is_refused_narrated()
{
    // Given an account with a balance of 100
    var account = new Account();
    account.Deposit(100);
    // When 200 is withdrawn
    var accepted = account.TryWithdraw(200);
    // Then the withdrawal is refused and the balance is still 100
    accepted.ShouldBeFalse();
    account.Balance.ShouldBe(100);
}

On xUnit, [BobcatFeature] is all it takes: the Bobcat.Xunit package opens a scenario around every test in the class and closes it with the verdict xUnit reported. On TUnit, NUnit and MSTest, put [BobcatScenario] beside it. (The sample project references Bobcat by project rather than by package, so it states [BobcatScenario] itself.) Run dotnet test in a terminal and the run prints the specification it produced:

Feature: Withdrawals
═════════════════════
  a withdrawal larger than the balance is refused narrated OK
  ────────────────────────────────────────────────────────────
    · Given an account with a balance of 100 — declared
    · When  200 is withdrawn — declared
    ✓ Then  the withdrawal is refused and the balance is still 100 (3ms)
      ✓ Then  accepted should be false (1ms)
      ✓ And   account.Balance should be 100 (2ms)

The declared is honest. A marker comment declares a step; nothing observed the Given or the When, so they have no duration and no verdict of their own. The Then is different only because the sample project opts into projecting Shouldly assertions as steps, so the two calls under the comment rendered beneath it with their own verdicts. Without that opt-in the Then would read declared as well, and when a Shouldly assertion threw, the scenario would be red with the exception and nothing narrower: no expected and actual pair, and the second assertion never reached. That is the limit of this style, and also its whole appeal. Opting an existing suite in costs one attribute per class and some comments (Marker comments, Projecting the assertions you already wrote).

Keep the comments, add the helpers

The two styles compose. A comment gives a test its narrative, and a decorated helper called underneath it renders nested under that sentence, with its own timing and verdict (They are different steps, and they nest). Most suites end up with both.

Step 2: a vocabulary

The second withdrawal spec should read like the first, and the tenth like the second. Move the mechanics into step helpers on a class of their own: methods decorated with [Given], [When] or [Then], carrying a sentence whose {placeholders} are filled from the arguments of those names:

private readonly Account _account = new();
private bool _accepted;
[Given("an account with a balance of {balance}")]
internal void AnAccountWithABalanceOf(decimal balance) => _account.Deposit(balance);
[When("{amount} is withdrawn")]
internal void IsWithdrawn(decimal amount) => _accepted = _account.TryWithdraw(amount);
[Then("the withdrawal is {outcome}")]
internal void TheWithdrawalIs(string outcome)
    => SpecAssert.Check("outcome", _accepted ? "accepted" : "refused", outcome);
[Then("the balance is {balance}")]
internal void TheBalanceIs(decimal balance) => SpecAssert.Check("balance", _account.Balance, balance);

The specification is now four calls:

[Fact]
public void a_withdrawal_larger_than_the_balance_is_refused()
{
    _steps.AnAccountWithABalanceOf(100);
    _steps.IsWithdrawn(200);
    _steps.TheWithdrawalIs("refused");
    _steps.TheBalanceIs(100);
}

Every call to a decorated helper is a recorded step: Bobcat’s source generator intercepts the call at build time, so there is no reflection and no registration. Two details carry weight:

• The helpers are internal, not private. The generated interceptor is an extension method, which cannot reach a private member. That one keyword is the whole adoption cost on an existing helper class (BOBCAT039).
• SpecAssert.Check records instead of throwing. It writes an expected/actual cell onto the step in progress and returns, so the specification keeps going and reports every disagreement it has. The adapter fails the test once, at the end, with all of them (Checks that gather instead of throwing).

Now write a specification whose expectations are wrong. A withdrawal of 30 from 100 is accepted and leaves 70, and this spec says otherwise, twice:

[Fact]
public void a_withdrawal_within_the_balance_is_refused()
{
    _steps.AnAccountWithABalanceOf(100);
    _steps.IsWithdrawn(30);
    _steps.TheWithdrawalIs("refused");
    _steps.TheBalanceIs(100);
}

  a withdrawal within the balance is refused FAILED
  ────────────────────────────────────────────────────
    ✓ Given an account with a balance of 100
    ✓ When  30 is withdrawn
    ✗ Then  the withdrawal is expected 'refused', got 'accepted' (1ms)
    ✗ And   the balance is expected '100', got '70' (1ms)
  Failed with Rights: 2, Wrongs: 2, Errors: 0

Both wrongs are there. A cell named for the placeholder it belongs to renders in the sentence, where the value sits, and the test runner’s own failure message says the same thing:

failed Bobcat.Xunit.Samples.Specs.WithdrawalSpecs.a_withdrawal_within_the_balance_is_refused (38ms)
  Xunit.MicrosoftTestingPlatform.XunitException: Bobcat.Engine.SpecAssertionException : 2 specification steps failed:
    Then the withdrawal is refused => outcome: expected 'refused', got 'accepted'
    And the balance is 100 => balance: expected '100', got '70'

A helper that throws is different. An exception is an error, not a wrong, and it stops the scenario: the step is marked !, the exception is printed once at the bottom, and every step after it renders as ○ … — not run with its placeholders unfilled, because its arguments were never evaluated (Report everything, then stop).

Step 3: the boundary as a decision table

The interesting cases of the overdraft rule are the ones at the edge: exactly the balance, a penny over. Four specs of four lines each would say less than one table. A helper that takes a StepTable receives the whole table from the call site, and TableRunner.Run calls a row method once per row:

[Then("withdrawals are decided as")]
internal Task WithdrawalsAreDecidedAs(StepTable table) => TableRunner.Run(this, nameof(decide), table);
private string decide(decimal balance, decimal amount)
{
    var account = new Account();
    account.Deposit(balance);
    return account.TryWithdraw(amount) ? "accepted" : "refused";
}

The balance and amount columns bind to the parameters of those names. The returned value is compared against the one column no parameter names, outcome, so the table is a decision table with a verdict per row:

[Fact]
public Task the_overdraft_boundary() => _steps.WithdrawalsAreDecidedAs("""
    | balance | amount | outcome  |
    | 100     | 99.99  | accepted |
    | 100     | 100    | accepted |
    | 100     | 100.01 | refused  |
    """);

The table is pipe-delimited text, read by an implicit conversion to StepTable. A markdown table pastes in unchanged, alignment row and all, so the table in the pull request and the table in the test are the same text. Give one row the wrong answer and the grid says which:

[Fact]
public Task the_overdraft_boundary_with_a_wrong_row() => _steps.WithdrawalsAreDecidedAs("""
    | balance | amount | outcome  |
    | 100     | 99.99  | accepted |
    | 100     | 100    | refused  |
    | 100     | 100.01 | refused  |
    """);

  the overdraft boundary with a wrong row FAILED
  ─────────────────────────────────────────────────
    ✗ Then  withdrawals are decided as (4ms)
╭───┬─────────┬────────┬────────────────────────────────────┬─────────╮
│ # │ balance │ amount │ outcome                            │ Verdict │
├───┼─────────┼────────┼────────────────────────────────────┼─────────┤
│ 1 │ 100     │ 99.99  │ accepted                           │   OK    │
│ 2 │ 100     │ 100    │ expected 'refused', got 'accepted' │  FAIL   │
│ 3 │ 100     │ 100.01 │ refused                            │   OK    │
╰───┴─────────┴────────┴────────────────────────────────────┴─────────╯
  Failed with Rights: 2, Wrongs: 1, Errors: 0

A row that throws is that row’s failure and the remaining rows still run. out parameters are output columns too, so one row method can judge several results (Decision tables).

Step 4: the history as a set verification

The account’s transaction list is a collection, and a collection claim is a set verification: the expected rows are a table, the system’s rows are matched against them, and every row gets its own verdict.

[Then("the transactions are")]
internal void TheTransactionsAre(StepTable expected)
    => SetVerificationComparer.Verify(_account.Transactions, expected, ordered: true);

[Fact]
public void the_history_records_what_happened()
{
    _steps.AnAccountWithABalanceOf(100);
    _steps.IsWithdrawn(30);
    _steps.IsWithdrawn(200);
    _steps.TheTransactionsAre("""
        | Kind       | Amount |
        | Deposit    | 100    |
        | Withdrawal | 30     |
        """);
}

The refused withdrawal must leave no trace, and the table says so by not listing it. Now a specification that forgets a withdrawal that did happen:

[Fact]
public void the_history_the_specification_did_not_expect()
{
    _steps.AnAccountWithABalanceOf(100);
    _steps.IsWithdrawn(30);
    _steps.TheTransactionsAre("""
        | Kind    | Amount |
        | Deposit | 100    |
        """);
}

  the history the specification did not expect FAILED
  ──────────────────────────────────────────────────────
    ✓ Given an account with a balance of 100
    ✓ When  30 is withdrawn
    ✗ Then  the transactions are (4ms)
╭───┬────────────┬────────┬─────────╮
│ # │ Kind       │ Amount │ Verdict │
├───┼────────────┼────────┼─────────┤
│ 1 │ Deposit    │ 100    │   OK    │
│ 2 │ Withdrawal │ 30     │  EXTRA  │
╰───┴────────────┴────────┴─────────╯
  Failed with Rights: 4, Wrongs: 1, Errors: 0

EXTRA is a row the system produced that the specification does not describe. MISSING is a row the specification describes that the system never produced, shown with the values it expected. FAIL is a matched row with a wrong cell, and ORDER is a row in the wrong place when order was part of the claim. Name keyColumns: to say which columns identify a row, and leave ordered: out when order is not the claim (Set verification).

Step 5: one specification per example

A decision table judges many rows inside one specification, with one verdict. When each example is something a person may want to run, see fail or track on its own, make each row its own specification instead. [BobcatTheory] is xUnit’s [Theory] plus the scenario bracket, and [BobcatExamples] writes its rows as the same table:

[BobcatTheory]
[BobcatExamples("""
    | balance | amount | outcome  |
    | 100     | 100    | accepted |
    | 100     | 100.01 | refused  |
    """)]
public void a_withdrawal_is_decided(decimal balance, decimal amount, string outcome)
{
    _steps.AnAccountWithABalanceOf(balance);
    _steps.IsWithdrawn(amount);
    _steps.TheWithdrawalIs(outcome);
}

Each row runs as its own test with its own identity and its own rendered steps:

  a withdrawal is decided (balance: 100, amount: 100, outcome: accepted) OK
  ────────────────────────────────────────────────────────────
    ✓ Given an account with a balance of 100
    ✓ When  100 is withdrawn
    ✓ Then  the withdrawal is accepted (1ms)

Columns bind to parameters by name, and because the table is a constant, the build checks it: a column naming no parameter or a cell the parameter’s type cannot read is a compile error rather than a surprise at run time (A theory’s examples as a table).

Reading and running

• The run prints its specifications when a terminal is attached and nothing is listening on the monitor wire. BOBCAT_SPEC_CONSOLE=1 prints anyway, into CI’s captured output; BOBCAT_SPEC_CONSOLE_FILE=spec.txt writes the report to a file instead (Reading the specification the run produced).
• bobcat run renders the specification tree in the terminal, and bobcat preview shows every specification without executing anything, because the steps are known at build time (The bobcat tool).
• Your IDE’s test explorer shows each specification as the ordinary test it is, so you run and debug it there (Integrating Bobcat with Your IDE).

Three things to know before you start

• xUnit v3, TUnit, NUnit or MSTest (3.10+). xUnit v2 has no adapter and is not waiting for one. Its BeforeAfterTestAttribute cannot hand over a test result, which is the seam the adapter needs (xUnit v2 is not supported).
• Use the shipped runner adapter, Bobcat.Xunit, Bobcat.TUnit, Bobcat.NUnit or Bobcat.MSTest. Marten’s hand-rolled one never set the verdict, so every scenario it published was a clean pass, red tests included (What you have to add).
• Declared is not executed. A marker comment describes what the test does; it does not make the test do it. The two can drift, and a comment can never carry a cell. When a step is worth a verdict of its own, it is worth a helper (Declared is not executed).

Microsoft just posted the first quarter of its 2027 fiscal financial results. The software maker made $92.3 billion in revenue and a net income of $33.6 billion during Q1. Revenue is up 19 percent, and net income has increased by 32 percent.

It's a new financial year for Microsoft, so the company is changing up how it reports its finances by splitting its businesses into two segments for the first time. Gone are the previous segments: Productivity and Business Processes, Intelligent Cloud, and More Personal Computing. It's now just Agents and Infra, and Devices and Consumer.

Agents and Infra, which includes businesses like Azure, Microsoft …

Read the full story at The Verge.

With an OLED display and touchscreen capabilities, it's no surprise that the new MacBook Pro Apple announced today is more expensive than the MBP announced earlier this year. But upgrading the base models that start at $2,899 for the 14-inch, and $3,399 for the 16-inch, with every premium hardware option that Apple offers pushes those prices to an eye-watering $14,249 and $14,549, respectively.

Both of those premium configurations include the M5 Max chip with an 18-core CPU and 40-core GPU, $150 worth of nano-texture glass, 128GB of memory that adds an extra $2,000, and 16TB of storage which is the real budget breaker here thanks to the ong …

Read the full story at The Verge.