Apple Invites Polls: Android Guests Vote, But Tally Glitches

Apple Invites now lets a host attach a poll to an event, asking guests to settle on a date, time, or venue before any detail locks in. Hosting that poll still runs through the same iCloud+ subscription and Apple ID that Invites has required for hosting generally since the app launched, so nothing about that part of the setup has changed.

The narrower question is what happens on the guest's side. Testing for this piece found that an Android phone with no Apple ID signed in anywhere on the device could open an invite, see the poll, and submit a vote. What didn't hold up cleanly was the next step: the host's iPhone view didn't clearly reflect that vote afterward, and that gap, not basic access, is the part worth treating as unresolved.

Three separate permissions get flattened into one conversation whenever people talk about Invites polls: who can build an event with a poll attached, who can open the invite link at all, and whose vote actually counts once submitted. The first is easy to confirm. The last one is where this week's test came up short.

What hosting a poll requires

Building an event with a poll attached still requires an iCloud+ subscription tied to the host's Apple ID. That requirement predates the poll feature and applies to Invites hosting broadly, not something added specifically for polls.

The poll option showed up when building an event on an iPhone, on an iPad, and through Invites opened in a desktop browser, each checked this week with an active iCloud+ subscription signed in. No minimum iOS or Invites app version turned up tied to the poll option, so there's no specific build number to check a device against before assuming it should be there.

If the poll option doesn't appear when building an event, two things are worth checking before assuming something's broken: whether iCloud+ is active and billing correctly on the hosting Apple ID, and whether Invites has a pending update sitting in the App Store. Those are starting points based on this week's testing, not confirmed causes, and a staged or regional rollout can't be ruled out or in from a single test pass.

What this week's test showed, and what it didn't

The setup: one iPhone signed into iCloud with an active Apple ID and iCloud+ subscription created an event and attached a poll with two date options. A separate Android phone, with no Apple ID signed in anywhere on it, opened the same invite link in Chrome.

The Android guest could open the invite, see the poll, and submit a vote. That answers the basic access question for that one device-and-browser combination, on this specific test run.

What it didn't answer: whether the vote landed correctly on the host's end. After the Android vote went in, the iPhone host view was refreshed and the invite reopened, and the displayed vote count didn't change in a way that clearly matched the submission. That could be a sync delay, a display quirk, or something else; one test run isn't enough to isolate which.

A handful of other questions went untested this round and remain open: whether a guest's vote is visible to other guests or stays anonymous, whether there's a cap on the number of poll options, and whether the same result holds on other Android versions, other browsers, or a desktop guest instead of a mobile one. One successful vote submission on one device confirms a non-Apple guest can reach the poll. It doesn't confirm the vote counts once it's cast, and it says nothing about devices or browsers outside the one combination tested.

Invites has let guests RSVP through a shared web link without an Apple ID for some time, which is a separate, older behavior tied to accepting or declining an invite rather than voting on a poll. That history doesn't automatically carry over to poll voting, which is exactly why it needed its own test rather than an assumption.

What a poll changes, and what's not confirmed

A poll's basic mechanic is observable directly in the app: a host sets up a question with selectable options, and guests register a preference against it, whether that's two possible times, a few candidate dates, or a shortlist of venues.

Picking a poll winner didn't visibly update the event's listed date, time, or location in this week's test configuration, though a single pass doesn't rule out different behavior in other setups. Hosts who need the displayed event details to match the poll outcome should plan on editing those fields themselves rather than assuming the app updates them automatically.

Notification behavior after an edit stayed unresolved too. Whether guests get a fresh alert when a host changes event details after a poll closes, or whether the change only shows up the next time someone opens the invite, wasn't something this round of testing could pin down. Editing or reopening a poll once it's sent is equally untested here, so there's no basis yet for assuming it's possible or that it isn't. Apple's public Invites materials don't spell out an answer either way, which leaves it an open question rather than a confirmed limitation.

Before trusting a poll with a real plan

The practical issue isn't whether a non-Apple guest can reach a poll. This week's test suggests they can, at least on one Android phone in Chrome. The issue is confirming the vote actually registers where the host can see it, which is exactly the step that didn't check out cleanly here.

Anyone planning to send a poll to a mixed guest list is better off testing that one link first: send it to a single non-Apple guest, have them vote, then check whether the host's tally reflects it. If the count doesn't update as expected, falling back to a group text or a separate polling app remains the safer way to gather votes, with the final decision entered into Invites by hand once it's settled.