Should you buy the new MagicBand+ for your next Walt Disney World vacation?

Jul 27, 2022 in "MyMagic+"

Hands on with MagicBand+
Posted: Wednesday July 27, 2022 11:39am ET by WDWMAGIC Staff

MagicBand+ is now live at Walt Disney World, and with this guide we want to help you decide if MagicBand+ is right for you and your family.

With a starting price of $34.99 before any discounts, MagicBand+ takes all of the functionality of the previous MagicBand but adds some features that may be enough to tempt you into buying one.

Along with the usual MagicBand features like tap-to-enter at the park entrances, paying for purchases, unlocking hotel room doors, and linking Photopass photos, MagicBand+ adds interactions with various locations in the parks - made possible via haptic vibrations and lighting effects on the face of the band.

To power the extra functionality of the MagicBand+, the device uses a rechargeable battery that Disney says should be charged daily overnight. MagicBand+ is supplied with a 6-inch cable with a USB type A plug on one end and a propriety dock connector on the other.

The rechargeable battery brings some significant benefits to the useful service life of the device, but also brings with it some significant overhead that you will need to factor into your vacation.

Taking a family of four, each night, they will be charging four MagicBand+ devices, phones for the adults, and possibly watches. This brings the likely device charging count to eight for every single night of the vacation. It also means they will need 8 USB power supplies to do all of this charging. You can buy multi-port USB power supplies, but it still represents a logistical headache adding to an already complicated vacation experience.

The main benefit to MagicBand+ beyond the rechargeable battery is the interaction with locations in the parks. Currently, this consists of a Star Wars Bounty Hunty game in Galaxy's Edge, a game to discover the Fab 50 character statues, and synchronized lighting with Disney's nighttime shows.

We've tried out the games and found them to be fun additions, especially for younger guests. The Star Wars Bounty Hunter game is the most impressive, using the MagicBand+ lights and vibrations to guide you around Batuu to find virtual bounties to exchange the credits. Disney built some new sets to handle this game, which works well.

The Fab 50 interactions trigger audio from the statues, and the Play Disney app tracks your progress to discovering all 50.

Finally, the nighttime spectacular interaction brings some synchronized lighting to your wrist, working with the Beacon of Magic shows at all of the parks, Harmonious at EPCOT, and Disney Enchantment at Magic Kingdom. The LED light on the watch is relatively small, so don't expect something like the Glow with the Show ears, but younger guests may find it neat to see their own MagicBand join in the show.

If the MagicBand+ interactive features are worthwhile comes down to the individual guest. It is a great feature to have for those that place value in playing scavenger hunts and some extra distractions to a typical theme park day. Kids especially would likely enjoy the games. Others who visit the parks mainly for rides and shows or who are short on time will probably not make use of the interactive features.

MagicBand+ Pros

  • A rechargeable battery means the device has a long service life and can power new functionality, including lights and vibrations.
  • LED light and vibration give the MagicBand+ interactive feedback to power new experiences.
  • MagicBand+ features all of the functionality of previous MagicBands.

MagicBand+ Cons

  • LED lighting is difficult to see in sunlight and, in some cases, cannot be seen at all.
  • MagicBand+ battery needs to be charged daily overnight, which may be a hassle.
  • Battery life may not be very long if using a lot of interactive features. Disney says the band should last a day, but we have early reports of battery life being exhausted after 2 hours of heavy gameplay.
  • Out of the box, MagicBand+ is not fully charged.
  • More expensive than the regular MagicBand.
  • Not available in as many designs and styles (yet) as the original MagicBand.

Should you buy a MagicBand+?

In short, if you are planning on buying a MagicBand and are okay with nightly charging, go with a MagicBand+. It offers more functionality for around $15 more, and being the latest device, we should expect to see more capability added over time. The games are a fun extra, and should be a hit with kids.

If you just want a band to get you into the parks, pay for merchandise, enter your hotel room, and use Lightning Lanes, buy a regular MagicBand and save $15.

But our suggestion would be to skip the original MagicBand and MagicBand+ and use the excellent Disney MagicMobile service instead. It uses your phone or watch to deliver all of the capabilities of the basic MagicBand in a device that you already own, charge and carry with you.

You can learn more about the MagicBand+ in our FAQ, and stay tuned for more coverage of Disney's new wearable.

Discuss on the Forums

Get Walt Disney World News Delivered to Your Inbox

View all comments →

flynnibus11 days ago

No - you're assuming they duplicated all this information into this 'magic band database' - there is no reason for such things. What you are really thinking about is there is some new master database of all things about a customer... that notion is independent of magic bands as a identity token. That is more about the modernization of their single platform.. and you don't really know how much was consolidated vs what simply stays within a particular realm and is simply SHARED to other realms for consolidated views. Your issues about 'much longer delays' are solved with caching systems. Disney has millions of customers... but there are only so many thousands on property at any point in time. For instance for ride terminals, caching 75k ticket records after their first use to speed up queries is pretty trivial to avoid dealing with blocking in a live database. Disney wouldn't consolidate everything into a single data model... instead you ensure many different platforms can interwork and share using common identifiers. So I don't mix a transactional history of everytime you scanned into a ride into the data store as your hotel reservation. Instead I ensure both systems use a common reference that can link your ride scan data to the same logical person who is holding a reservation. So when an application wants to see everything that logical person did.. that application can interact with those different systems and get data from multiple sources, but associated with the commonly shared identity. Don't confuse Disney having a consolidated VIEW of a customer to mean the data is necessarily consolidated itself.

flynnibus11 days ago

And that's where you are still wrong... 'that the magic bands access...' is non-sense. They don't access anything. They are a token that presents itself.. and the various systems you interact with then use that piece of data to cross reference an identity and entitlements for whatever is relevant for that application (a door system, a gate, etc). Applications would be querying a magic band platform to resolve band identifiers to other logical units. Applications like POS systems, keycard systems, entertainment platforms, etc. We don't know how much of the applications they consolidated into a single one.. vs ensuring separate systems being able to SHARE with each other.. but it's not really significant to this discussion. Statements like "It also has the unlock codes for the rooms they are authorized for" and "as well as the admissions media attached to that user" show a fundamental lack of comprehension of how such architectures work. Think of it as the band just being a temporary # given to you. The magic band system would be responsible for linking that temporary # to a logic customer entity. Each application would have it's own repository of what is relevant about your customer entity #. Like, you are allowed to open door 2355... while another platform may link that same customer # to a reservation... while another platform may link that customer # to a ticket entitlement. The point is... the systems all have a way to all link to the same logical 'customer' now.. where prior to Next Gen, everything was silos and it was much harder to cross reference things. The magic bands are just a way to present an identifier that can be trusted.. and provide a means to map that identifier to a logical identity that is used commonly through the NextGen experience. That mapping layer can have scaling and stale data challenges... where it's being tasked to cope with data that is basically worthless now because its accounting for data that will never be used. It's like cleaning out your attic after years... It's also possible that the newer generation bands have additional validation or other features that are holding systems back by having to support both a new and old model.. so deprecating the legacy use cases can improve functionality, security, and reduce complexity/cost to keep moving things forward. For a system of this size.. it's probably a mix of both.

AEfx11 days ago

I may very well be incorrect about the door opening procedure (I haven't paid on property prices since these things came out), but I never said any data was physically stored on the Magic Bands themselves. The point was, we are talking about a database that the Magic Bands access, which has a subset of the data the overall reservations system has. That's where glitches have happened in the past - the updates made to the reservation system by Guest Services, etc., copying the new data over to the database they directly access.

AEfx11 days ago

On the band itself, no - it's just a numerical code. But that code accesses a database specifically for those Magic Bands, containing the info that Magic Bands are meant (or were meant, depending on the data, i.e. birthdays and such) to be able to quickly access. They aren't hitting the reservations system directly every time they access data. Or there would be much longer delays between scanning and accessing the data they need immediately, and it would be millions more hits against the reservation system daily that would bog it down . I believe you will find that's why occasionally Guest Services has had issues syncing them up when updates are made to the reservations database - especially at the beginning. Because updated data wasn't always transferring from the reservations database to the Magic Band database.

HauntedPirate12 days ago

Valid point. I don't even think you'd have to go as high as 95% inactive to make a pretty solid case to pull the trigger on retiring the unused devices. I still don't trust Disney IT to do the job correctly, without impact. 😁 I'm still not buying a MagicBand. Or a DisneyBand. The fact that they fooled so many people into shelling out money for them in the first place should be a case study.

flynnibus12 days ago

There are other designs.. like tiered data stores. Plus the ability to basically partition records until they are needed. There is a ton you can do here.. But occam razor here... if you know you have 95% of the devices that will never be used again, it's just more efficient to retire them and deal with the exceptions than it is to keep building more support for them at expense.

flynnibus12 days ago

You clearly don't know how this stuff actually works... The bands are nothing but ID numbers, radios and the ability to do validation/encoding. They are essentially nothing more than a really big number assigned to you, with radio I/O attached so it can interact with NFC and RF devices. The far end is doing everything... Which is why your magicband can open your room without ever visiting the desk...

Brian12 days ago

That is correct. The bands have nothing "on them" except for a unique identifier which is used by the various touchpoints to query databases as to what the wearer has access to. When it comes to hotel doors, when the guest's assigned room is ready, the lock receives the identifiers of all the guest's bands and cards which are permitted to access the room. The more bands one has active on their profile, the more likely it is that one or more will fail encoding to the lock, which is one of the reasons why MB 1s are being mass deactivated. Other touchpoints, like LL and park entry, receive the unique identifier upon tap, query the databases to see if the proper entitlement(s) to enter are present, and return the approval/denial based on what the database says. If someone were to "hack" a physical MagicBand and read its data, all they would find is a long string of characters that is useless to them without access to the databases themselves.

CaptainAmerica12 days ago

Maybe I'm missing something then because weren't they adamant that no personally identifiable information whatsoever would be stored on the band? In your room key example, I think it works in reverse of what you described. It's not the band knowing how to unlock the door, it's the door knowing which bands are allowed to unlock it.

AEfx12 days ago

Oh, I'd be willing to bet there is a lot more there, especially if they actually had the intention of doing what they originally said they would do with them that never came to fruition. Example, you were supposed to be able to walk up to a NextGen Mickey, and he would know your name, and if it was your birthday, etc. In designing for something like this, it would have made much more sense to carry that data over to the MagicBand database itself, instead of having it hit the reservations system constantly to access that data. Both in terms of speed and database load on the reservations system. It also has the unlock codes for the rooms they are authorized for, as well as the admissions media attached to that user - or you'd be waiting with a delay like swiping a credit card transaction every time you used it, instead of the nearly instantaneous way they work now. It may not sound like a big difference, but when opening your room door or using it to enter a park, a second or two versus even 7-10 seconds really adds up (both for the user and overall operational efficiency). I'm pretty sure we would find that instead of just a simple link to your Disney profile, there is quite a bit of data copied over to the MagicBand database, which might be redundant at first blush, but operationally makes the whole system (and what it was intended to do) much more efficient.

HauntedPirate13 days ago

Personally, I think there should be a way for user's to permanently remove a MB from their inventory, with a pop-up window warning users and all that (I wouldn't trust Disney IT to do any sort of work around a mass MB disable without a debacle ensuing). I'm sure I have a dozen old AP cards and MBs that I could remove (I don't buy MagicBands, for the record) to help out the database size. ;)

Cariad13 days ago

I loved how it synched with the Water Show at California Adventure, even when I was strolling along Pixar Pier and not watching the show.

Cariad13 days ago

I'm glad I'm not the only one who has made a garland with them. I got a rechargable one on my last trip, I'm planning on using it for as long as it lets me.

mikejs7813 days ago

Pure tech speculation here - and sorry for those who aren't up on database design - but a common pattern for very large tables is to partition the table on specific fields, so part of the table is stored in one file and part in another. If, let's say, the table was partitioned on magic Band status, moving a large number of bands to inactive would significantly shrink that partition and could significantly improve performance, without having to physically delete the records. That being said, I don't see any reason Disney should invest in more storage to support a set of magic bands that are 99% unused and are over a decade old. If I were Disney I would announce the sunsetting of MB1 on a specific date. At that point, all those magic bands would be purged and unable to be reactivated without calling Disney support. Users who still have and want to use an MB1 could go to a page to click a button that keeps it active. That lets them clear out 99% of that data.