Apple Maps Japan can’t catch a break. Traffic has been available since September 2019 but only got listed on the feature availability page last week, June 2020. Handa International Airport is currently listed for indoor maps but the data isn’t there. And so it goes for the Apple Maps 2.0 reboot. Here is a quick list of missing features along with some new feature requests.
There are several iOS 13 Apple Maps features that have not made it to Japan:
More accurate detail is welcome but I don’t think Apple can ever get the whole picture by themselves. Google Maps real genius is it’s deft ability to synthesize disparate data suppliers in a seamlessly whole service. Apple Maps biggest single failure, from day one to today, is it’s utter inability to synthesize various data suppliers into a solid service.
It’s a chunky clunky Japanese product, from eternally 3rd rate map data from IPC on down to Foursquare. Top Japanese map data supplier Zenrin is the logical choice especially since Google dropped them, but Apple doesn’t seem inclined to switch, nor could they intelligently integrate it.
Look Around It would be very nice to have this feature in Japan.
Junction View Navigating complicated elevated expressways in urban areas isn’t just in mainland China, it’s been a fact of Japanese urban driving since the 1960s’. Junction View like navigation has been standard in Japanese navigation systems for a long time, it should be standard in Apple Maps too.
Real-time transit Another no-brainer transit feature for Japan, but Japan is a low priority and the transit system is complex. There are plenty of transit data suppliers but given Apple Maps limited ability to integrate different transit data sets, I think it will be a long time before we see the addition of real-time transit in Japan, if ever.
There are small tweaks Apple could make to transit directions that would make them much more useful such as transfer station platform numbers and crowd conditions, features that Google and Yahoo Japan have offered for a long time.
Adaptive transit times: car and walk navigation is adaptive: if you take a different road the navigation route updates automatically. Transit directions need to be adaptive too.
Crowding information: Yahoo Japan offers crowd heat maps for locations, both Yahoo Japan and Google Japan maps offer rudimentary transit crowd information. In the COVID era crowd information for transit and locations is a must have feature.
Improved Apple Watch transit integration: Apple Watch turn by turn navigation integration with iPhone is excellent but transit integration is weak and passive. The current iOS 13/watchOS 6 version ‘sits on the wrist’ without alerts, haptic feedback or much interaction, and it’s brain dead after switching to another watch app.
Indoor/Underground Station Maps: Last but not least real indoor maps for vital station hubs covering Tokyo, Shinjuku, Ikebukuro, Osaka, Namba, etc.
Offline navigation: Apple Maps turn by turn won’t be completely reliable unless it navigates in expressway tunnels instead of dying.
Apple Pay Octopus launch day was a big success, so successful that Octopus apologized for their servers buckling under the demand. What’s next for Octopus, Google Pay? There are some possibilities but when it comes to Android there is the matter of the Secure Element (SE), where it resides and what transaction protocols are supported.
From the NFC hardware angle everything has been ready to go on all smartphone hardware for years, NFC A-B-F is required for NFC certification. The problem has been on the SE side, the black box where all the transaction magic happens. From Global Platform the SE certification organization:
A SE is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (for example cryptographic keys) in accordance with the rules and security requirements set by well-identified trusted authorities.
There are different form factors of SE: embedded and integrated SEs, SIM/UICC, smart microSD as well as smart cards. SEs exist in different form factors to address the requirements of different business implementations and market needs.
SE Wars and Google HCE ‘SE Pie in the Sky’ In the pre-Apple Pay mobile carrier hardware era, carriers used SE SIM or embedded Secure Elements (eSE) + SIM combos that chained customers to service contracts for the privilege of using mobile payments. This is the classic Osaifu-Keitai textbook maneuver pioneered by NTT Docomo: leave those pesky SIM Free whiners in the cold world of plastic cards and hard cash, or crippled digital wallets until they give up and buy an overpriced carrier SIM. This brain dead approach is one reason why Mobile FeliCa ended up being ridiculed as ‘galapagos technology’ even though everybody copied it with inferior crappy me-too products.
This carrier SE hostage situation, i.e. the Mobile Wallet SE Wars, led Apple and Google to follow different strategies to address the problem.
The Apple Pay Way Apple’s answer of course was Apple Pay. A unique in house strategy of putting a Global Platform certified Secure Element in their A Series/S Series chips then building it out from there. Most eSE go on the NFC controller, but doing it the Apple in-house way has advantages over a NFC chip vendor bundle: control of the eSE applets and ability to update them and the Apple eSE for new protocols in iOS updates. We saw this in action with the addition of FeliCa in 2016, PBOC in 2017 and MIFARE in 2018. We may even see the addition of Ultra Wideband (UWB) Touchless in iOS 14.
The Google Pay Way Google’s answer to the carrier owned SE problem was the more convoluted evolution from Google Wallet (2011) to Android Pay (2015) and finally Google Pay (2018). Google first salvo was Host Card Emulation (HCE): “NFC card emulation without a secure element” hosted on Google’s cloud. Later on Google attempted to do the same for FeliCa with HCE-F.
But then something happened that put an end to all this: Google decided to get into the hardware business. And now we have Google Pay and Google Pixel with it’s own embedded Secure Element (eSE). With Pixel, Google decided they didn’t want to be the Secure Element cloud provider for every Android OEM out there especially when the Chinese OEMS are all rolling their own eSE based digital wallet services anyway, completely ignoring HCE. Sure, HCE/HCE-F is still there in the Android developer documentation but it’s a dying vestigial relic of the SE wars.
But Google Pixel depends on vendor bundled eSE + NFC controllers and this makes global NFC support more complicated because Google doesn’t ‘own’ the eSE, at least not in the Apple sense of making their own all in one design. This is one reason why Pixel 3/4 only support FeliCa in Japanese models even though all worldwide models have the same NFC A-B-F hardware.
The end result of all this is the Android market is a very fragmented landscape, there are no global NFC Android smartphones: a device that supports EMV, FeliCa, MIFARE, PBOC out of the box in one globally available package.
Google Pay Octopus and the Android Global NFC Installed Base Back to our original question, can Google Pay Octopus happen? We already have Google Pay Suica right? Let’s assume that Octopus Cards Limited (OCL) has everything in place for it to happen. Here we run into the problem just described: there are’t any global NFC Android smartphones available globally. Samsung sells them in Japan and Hong Kong, Google only sells them in Japan along with Huawei, Oppo, Sharp, etc.
For OCL this means the potential Google Pay installed base that can support Hong Kong Octopus consists of Samsung Galaxy smartphones that are already using Smart Octopus in Samsung Pay; not exactly a mouth watering business opportunity worth the support expense. If Google Pixel 5 goes deep instead of cheap Hong Kong would have a potential Octopus non-Samsung Android device, but that’s only one new device not an installed base. I only see Google Pay Octopus happening if Google foots the entire support expense.
There is a way forward however for OCL: Garmin Pay Suica. The same Garmin APAC models that support Suica can also support Octopus, the recharge backend is entirely Google Pay. Garmin smartwatches work with any Android 5 and higher smartphone, a much larger installed base that bypasses the fragmented Android landscape. Garmin Pay Octopus would offer Android users a way in, who want to use Octopus on a mobile device but who don’t want to use Samsung or Apple devices.
The conclusion: forget Google Pay Octopus for the time being. Hong Kong is a golden opportunity for Gamin Pay Octopus….if Garmin can get Garmin Pay clearance from Hong Kong authorities and banks, and cut a deal with OCL. It’s certainly in Octopus’ best interest for OCL to help turn the negotiation wheels. It’s also in Google’s interest as Google Pay would supply the recharge backend as it does for Garmin Suica. Big hurdles all, but I hope it happens.
Good news for long suffering Hong Kong iPhone users: press invitations labeled ‘Redefining Mobile Payments’ that went out to local media outlets on May 28 signaled Octopus for Apple Pay would finally launch on June 2, which it did in tandem with Apple Maps Hong Kong Transit directions just before 1 am June 2 local Hong Kong time. The press event took place at 12:30 pm.
OCL teased everyone when it first announced Apple Pay Octopus as ‘coming soon’ in July 2019, then ‘as soon as possible’ in September, finally postponing it in December for ‘later in 2020’ without explanation. This despite endless beta test leaks that indicated everything was ready to roll and endless launch rumors that never panned out. The Apple Pay Octopus Wait for Godot was a very bumpy journey. A timeline:
September 2017: Apple releases global NFC iPhone 8/X and Apple Watch Series 3 setting the stage for Octopus support
December 2017: OCL launches Smart Octopus in Samsung Pay
Global NFC iPhone and Apple Watch Apple Pay Octopus is just like Apple Pay Suica with Express Transit. It can be used on iPhone 8 and later with iOS 13.5, and Apple Watch Series 3 and later with watchOS 6.2.5. Apple devices from anywhere can add and use Octopus thanks to Apple global NFC support but practical use is limited to having a Hong Kong issue Mastercard, Visa or UnionPay bank card already in Wallet.
iPhone 11 Pro/11/XR/XS have the A12/A13 Bionic exclusive Express Transit with power reserve feature that gives users an additional 5 hours of Express Transit use when iPhone is in low battery power reserve mode. A12/A13 Bionic powered transit card performance is also much improved over previous iPhone models because the Bionic Secure Element directly handles transactions that eliminate iOS overhead. If Octopus on iPhone X doesn’t work well, check this support post.
Apple Watch is the first time Octopus has landed on a smartwatch. As a long time Apple Pay Suica user I can tell you that it’s the Apple Watch killer app. Octopus users will really enjoy the experience on Apple Watch especially when hooked up with auto recharge/Automatic Add Value Service (AAVS).
Similarities with Suica Octopus is based on the same FeliCa technology that powers Suica, both cards are very similar in scope and use for fast transit and contactless payments of all kinds. According to Wikipedia over 33 million Octopus cards were in circulation as of 2018 used by 99 per cent of Hong Kong residents. The ubiquity of Octopus with Express Transit for transit and purchases will drive Apple Pay use in Hong Kong far more than regular credit/debit cards.
Apple Pay Octopus and Apple Pay Suica both have the same fast Express Transit performance that no other Express Transit cards can match with faster gate performance than the recently added Apple Pay China T-Union mainland transit cards.
New virtual Octopus cards can be created directly in Wallet just like Apple Pay Suica cards or added via the Octopus app (v6). Plastic Octopus cards can also be transferred to Wallet but cannot be used after transfer.
Some attached services are not supported. Be sure to check Important Notes to Customers before transferring a plastic Octopus. Another issue to be aware of is that the Octopus card number changes when transferred which can cause problems with some card ID# linked services.
Not Inbound Friendly OCL limits Apple Pay Octopus card creation and recharge to having Hong Kong issue Mastercard, UnionPay and Visa cards already added in Wallet. It’s clearly not geared for inbound visitors. This is a shame because Apple supports global NFC on all devices which Samsung and Android devices do not, a key difference.
In practice this means any iPhone 8 and later from anywhere can use Apple Pay Octopus but only when a Hong Kong issue bank payment card is already loaded in Wallet. Suica is very different in this regard: it can be created and recharged in Wallet with any Apple Pay loaded card no matter the brand or country of issue, all without service fees. It’s a very inbound friendly deal for Japan visitors with iPhone.
Unfortunately OCL was limited by restrictive Hong Kong bank agreements and didn’t offer any Apple Pay inbound friendly solutions at the press event. Hopefully they will expand inbound bank card support down the road as banks realize the value of enticing tourists to use Hong Kong transit.
Octopus was the first real transit platform (contactless transit and eMoney) that had a tremendous impact on the development of other transit card fare systems around the world such as Transport for London Oyster. However, OCL needs to aggressively expand Octopus services on other mobile digital wallets like Google Pay especially as MTR moves to add QR Code payment Open Loop support.
Apple Maps Transit Integration Hong Kong Apple Maps Transit directions launched in tandem with Apple Pay Octopus. It makes sense for Apple to offer both services as an integrated package as they did for the Apple Pay Suica. In Japan, Google Maps transit directions offer more detail and a better UI than Apple Maps Transit even though they use the same data suppliers. Your milage may vary but Google Maps transit directions for Hong Kong has been in place for some time and offers extras like crowding info. Another limitation shared with Apple Maps in Japan: no indoor station mapping.
Greater Bay Area Apple Pay Transit Compatibility Apple Pay Octopus is the last piece of the transit puzzle that delivers Express Transit convenience to Greater Bay Area iPhone/Apple Watch users who, up until iOS 13.4.1, were limited to China Union Pay (CUP) cards without Express Transit and plastic Octopus cards.
The recently released Apple Pay China T-Union transit cards are interoperable transit cards that work across the country, some 257 mainland cities, similar to what Japan has with Suica, ICOCA, PASMO. China T-Union uses the PBOC 2.0/3.0 protocol, the Chinese variant of EMV with the slowest NFC transaction speeds, they are limited to UnionPay issue credit/debit cards for recharge and cannot be used for purchases. Octopus uses the faster FeliCa protocol and offers an open Apple Pay recharge backend for Hong Kong issue cards.
The advantage for wide area travelers is that they can now add both Apple Pay Octopus and China T-Union cards in Wallet. Having 2 different Apple Pay transit cards in Wallet may not be exactly the same as the dual mode Sold Octopus•Lingnan Pass but it should be close. It will be interesting to hear what the Apple Pay Greater Bay Area transit experience is like using both services.
Why the long wait? There has been endless speculation regarding the reasons for the Apple Pay Octopus delay. Technically it could have launched on iOS 12 but was held back for an unbelievably long test period over 2 major iOS versions, running from December 2018 and iOS 12 all the way to May 2020 and iOS 13.5, the last major release before iOS 14.
Why? Personally I always felt the unexplained November 2019 Smart Octopus service outage was an ominous sign that OCL plans were under political pressure, though many will disagree. Other possible delay reasons include Apple Pay recharge card support and fee negotiations, and lining up Apple Map transit data. There’s no question that the go-slow OCL approach with constant tweaking of mobile and O! ePay services was not helped by the ever-deteriorating political situation.
The Apple Pay Octopus launch story was a long winding road with many ups and letdowns in the very difficult year of 2019. 2020 is also a very difficult year in a different way, though I hope it can still turn out to be a time of recovery.
I’d like to thank all the readers who shared Octopus tips and comments that let me report a complex, ever changing situation. I learned many things, the most important of which is that Hong Kong people are very kind and very smart. Wish you all a safe, healthy and happy transit wherever you go.
June 3 8:00 JST: Octopus issues apology, “Due to the overwhelming response to the launch of Octopus on iPhone and Apple Watch, some customers could not add their Octopus between 11:30 am and 12:19 pm on 2 June,” and compensating some Octopus users June 2 12:00 JST: Octopus Card Limited site updated for Apple Pay Octopus and a press release June 2 09:00 JST: Apple Pay Octopus page added to Hong Kong Apple site with instructions for creating, transferring and topping up Octopus cards in Apple Pay June 2 03:20 JST: Octopus App v6 update released June 2 01:50 JST: Apple Pay Octopus has launched, rollout expanding in stages June 2 00:46 JST: Apple Pay Transit directions for Hong Kong appearing in advance of the Apple Pay Octopus
Suica was the big thing that put Apple Pay front and center in Japan. It still does, everybody loves using Apple Pay Suica Express Transit for Face/Touch ID-free transit and store payment in our face mask era. The funny thing is that Apple is slowing removing Suica as the Apple Pay poster child. The process started with iOS 13.4 Apple Pay Wallet blurb text that removed the hot market brand ‘Suica’ name replacing it with the very pedestrian unmarketable ‘transit’.
Now we have another Suica removal from the iPhone SE spec page Apple Pay section. Other iPhone 11/Pro/XS model spec pages all have the Suica blurb. Why? I said it before and say it again: Suica has massive brand recognition in Japan and Apple Pay has leveraged the Suica brand at every opportunity. Apple would not swap Suica for generic wording lightly, not without a very good reason. That reason is more transit IC cards coming to Apple Pay. Mobile PASMO, please stand when your name is called.
A reader asked some very good questions regarding the Suica Transit Platform model and Open Loop:
1) Thinking about this recently – is there a non-techie argument for introducing Suica-type cards in the current day in places with preexisting open-loop infrastructure, wide debit card adoption (even kids), and little overcrowding at ticket gates due to lower volumes?
2) As a tech & transit nerd, I obviously love them, but what could be a convincing, economically sound pitch to a transit operator for creating/adopting an integrated transit&e-money system, given the significant expense and questionable added value?
3) Answers to possible q’s about EMV contactless: 1. 定期券 (commuter passes) & discounts can be tied to card no.; 2. solution for visitors: in-app/paper/multi-trip tickets (like in SG). Obv., Suica has superior privacy & speed, but where speed is not an issue, what’s the killer argument?
I tweeted a response but Twitter is a terrible vehicle for long form discussion. I have many posts on the subject scattered over 2 years, it might be convenient to summarize a few things here.
Any argument for building a Transit Platform or going all in with Open Loop transit comes down to transit company priorities for safe operation, better customer service and long term business goals. A few crucial points to consider.
Whose customer? A vital point that many people miss in the Open Loop debate is that transit users end up as the bank card customer, not the transit company customer. That might seem like an insignificant difference but ‘owning the customer’ is the whole game and key to growing any kind of business, in our era or any era. Which brings us to the next point because the best way to own the transit customer is…
Cards Cards are the delivery vehicle for all kinds of service goodies from transit, to points, rewards and all kinds of services. The beauty of a non-bank transit pre-paid card is its flexibility, it can be a simple ticket that customers buy with cash from a station kiosk, it can be linked to an online account with credit cards, extended transit services and beyond. Cards are convenient but not transformative however, until they land on a smartphone…
Digital Wallets The most powerful card incarnation is the digital wallet transit card with a flexible recharge backend, where any bank card can used, or even cash, and a flexible front-end that can be any flavor of NFC, UWB Touchless or even QR. I say it’s better for the transit operator to decide what payment technology works best for their needs and how to deliver better customer service with new payment technologies, not banks.
Value Capture Value Capture applies to rail and transit operators with the rights to develop the land around their stations, I include station retail development and operations. Owning a transit + payment card like Suica or Octopus combined with retail opens up a whole new levels of value creation and capture.
It’s also important to remember a few other dynamics, (1) Transit is the golden uptake path for contactless payments, (2) Contactless payments are most successful when a transit payment platform, like Suica, is matched with a mobile wallet platform, like Apple Pay. The key is building better services tied to transit cards that benefit customers and businesses of the entire transit region.
Other Details Regarding detail questions such as attaching commuter passes to EMV cards and special ticketing, I am no systems design expert but a few things come to mind. First of all we have not seen Open Loop commuter passes because the EMV spec doesn’t store anything locally and there are always security and performance issues to consider when everything is done in the cloud with soft-linked registration to system outside numbers.
The classic catch 22 here is that when the soft-linked number changes on one system, everything attached to it on the other system stops working. This is a constant weakness of the SmartEx and new JR East Shinkansen eTicket service. And what happens if the bank pulls a card mid-transit? These things happen. They are endless headaches when linking to any outside system, for this reason Open Loop sticks with the simple stuff while transit operators keep the more complex stuff in-house. In general the more complicated the fare configuration, the less likely it can be synced with an outside system or be hosted on Open Loop.
For low volume specialty ticketing QR Codes are the easiest step up from paper but they can be printed on ordinary paper for transit users without smartphones and needs to be there. This is why JR East is deploying QR code readers in some gates as they prepare to end mag strip ticketing.
NFC Contactless Passes might sound like a good idea but Apple Pay VAS and Google Pay Smart Tap were designed more for retail in mind, and the transit gate reader system would have to juggle a different protocol that isn’t EMV, FeliCa or MIFARE. It could be done, but judging from my experience of using Apple Pay VAS PONTA and dPOINT cards, QR Codes are faster and likely easier to implement.
In the long run there are no easy solutions. The risk of Open Loop is that it is sold as a general easy ‘fix all’ and mobile solution, which it’s not. This lulls transit operators into complacency instead of improving Closed Loop ticketing systems and extending them to the mobile digital wallets. The bigger and more complex the transit system, the less Open Loop can accomplish.